Tag Archives: Quality Assurance

Be An Eternal Student

No, I’m not talking about spending your entire life jumping from one major to another so you don’t have to graduate. When I say, “Be an eternal student.”, I am advising you to keep learning throughout your life both actively and passively. Don’t let opportunities pass you by. Just because you don’t need to know something right now doesn’t mean that it won’t come in handy later.

One question I get from many people is how I know all of the things I do. I tell them that I just pick it up as I go. Growing up, I was surrounded by mechanics, electricians, carpenters, and other tradesmen. If they needed help, or were helping me, I paid attention and picked up some tricks from them that help me around the house today. With my career, it’s been a bit different. Until recently, I didn’t have a lot of computer people around to talk to so I had spend a lot of time tinkering on my own and doing research. I learned a lot of ways not to do things; I learned some bad habits; and I gained some excellent insight into how our magical toys work from the ground up.

Aside from the hands-on/trial and error approach, I have also invested a significant amount of time reading, watching videos, and taking courses on various topics. Usually I try to focus on things I am either actively working on or expect to in the near future, but sometimes I throw in something brand new or just plain fun to keep me excited about learning. Recently I did this by taking all of the courses in the Docker Path on Pluralsight.com. While I started the courses for fun, I quickly found that what I was learning could be implemented in my current projects, which was an added bonus since I get to practice what I learned and improve my working environment.

It has been experiences like that and some unpleasant bills, replacing things I didn’t know how to fix, that helped me realize the importance of not growing stale or letting my aptitude for learning atrophy because I already know how to do my job. I was also lucky to have grown up around other perpetual students who gave me a solid understanding of how to acquire knowledge. I have found that the keys to learning are very simple:

  1. Find something you are curious about or need to learn.
  2. Gather resources that cover the topic.
    1. Talk to people who already do or know what you need.
    2. Read books and articles about the topic.
    3. Watch videos about it.
    4. Look for someone teaching a course that you can sign up for.
    5. Experiment on your own.
  3. Do something with what you have learned.
    1. Complete a project using what you learned.
    2. Share what you learned with someone else.
  4. Appreciate yourself for learning something.
  5. Repeat.

If that sounds easy, that’s because it is most of the time. I use this approach in my daily life for everything from plumbing to performance testing applications. Granted I will never be a master plumber (it just isn’t my calling) but I also don’t need to call one when I need to unclog a drain or replace a faucet. When it comes to computers and software, there is always something new to learn regardless of your level of mastery. This is part of the reason it is important to be an eternal student. If being armed with new tools and ideas isn’t enough to fuel your desire to learn, remember that once you stop growing you begin to become stale and obsolete. Don’t let your potential sit idle. Take the time and spend the effort to find out exactly what you are capable of. You might even find out that you can do anything you set your mind to.


I have never let my schooling interfere with my education – Mark Twain

Advertisements

Limbering Up QA: Adapting to an Agile Process

In the days of Waterfall, testers were seen as the guardians of quality and the protectors of user experience. They were the last line of defense to prevent a flawed product from being released. This meant that QA needed to have all of the requirements provided to them so they could prepare their tests for when the product was finally complete and they could begin their process. Sure, the deadlines were usually tight because the release couldn’t be moved and development ran long, but that was just part of thrill. QA were sometimes viewed as an obstacle rather than an aid, but they remained strong and provided their sworn services for client and company.

All of this changed with the dawning of Agile.

The once-powerful QA is now faced with shorter deadlines, stories instead of specifications, and seemingly incomplete features being submitted for test. Worse yet, the developers are encouraged to develop unit tests that automate a chunk of what the tester once handled.  How can we possibly work like this? It’s utter madness.

It may seem like madness and chaos, but there is also method and rhythm to be found in the new processes. The first step is to stop fighting the current and dive off the waterfall instead. After taking the plunge, testers can learn to navigate the flow of sprints and iterations. Granted, this is often easier said than done, but any habit can be kicked and new ones formed. It just requires time, effort, and a willingness to change.

Unfortunately, two out of three of those things are often not in the testers’ inventory, time and willingness to change. I’m sure that a number of those reading this might be offended by that statement, but bear with me. I know that no-one will argue with the time part, but everyone trips on the willingness to change. It’s natural for people to find a comfort zone and settle in. It’s also natural to be startled and scared by change. In my experience, testers are often leery of Agile because it seems to value speed over quality, but this couldn’t be farther from the truth. Agile places emphasis on quality but it is done by building it in rather than straining out errors after development.

This change in both thought and method is the key to producing software quickly without compromising quality. The catch is that it requires developers and testers to step out of their silos and work closely together. They should also include product owners and other stakeholders in their discussions to keep everyone aligned.

The idea is to inject the knowledge of QA from the beginning rather than waiting until everything is done. While this may sound like a pitch for TDD or BDD, that is only a piece of the picture. Sometimes, it is already too late for feature to maintain quality once it gets to development. This case is most often found with legacy modifications or a stakeholder pet project that seems “simple enough” but hasn’t been fully evaluated for ripples or pitfalls. This isn’t because someone missed  something. It is a result of their standard thought processes.

  • Developers tend to think in terms of “how can I make this work?”. They are focused on solving the puzzles.
  • Product owners focus on the value of the feature to clients. Most POs leave the technical concepts to the dev team.
  • Stakeholders are usually focused on how the feature will improve their positions or increase the company’s profits

When testers are left out of the planning stages, teams sacrifice an opportunity to reduce bugs and head off troubled projects before they are sent to development. A tester’s mindset generally includes looking at contingencies, interactions, and risks within a system. Even if the person doesn’t know the  system, asking the right question during planning can shine a light on a major issue that may have been glossed over, such as “Have we considered how the new shipping system handles an order including both physical and downloadable content?”.

After planning, QA should be helping to translate business process knowledge from the POs into paths through the software and tests for the new feature. A common method of doing this is by writing Given-When-Then (or similar concept) scenarios. These scenarios will then form a basis for both automated and manual tests used to confirm the functionality during development and prior to release.

In short, testers should make an effort to be involved throughout the project cycle rather than sweeping up at the end. By doing this they can help set the stage for successful projects and avoid the stress of being the roadblock or bearer of bad news just before release. While this is a major change, it is one worth embracing.

An Overview of the Selenium Suite

First Things First

For those unfamiliar with Selenium, it is a suite of open-source browser automation tools consisting of three main products: Selenium IDE, Selenium Server, and Selenium WebDriver. Selenium IDE is a Firefox plugin that can be used to record and playback tests. Selenium Server is a java application that is used to control browsers on remote machines and/or to create what is called a Selenium Grid. The final component of the suite is Selenium WebDriver, which is a browser automation API designed to create tests or perform other required tasks. Each of the suite components serves a specific purpose in a web tester’s toolbox although all of them may not be needed within an organization.

Continue reading An Overview of the Selenium Suite

What is Test Automation?

Since this is the first post for my blog, it seems appropriate to start by defining test automation and then adding some scope to rein it in. In the broadest of termstest automation is the process of consistently obtaining and verifying results with minimum (or no) human interactionThis means that the tests could be physical or virtual. An example of a physical test for a manufacturing environment would be a sorting machine that checks for over-sized or misshapen parts. In the virtual realm, automated tests come in numerous forms and functions such as unit, integration, regression, and performance. My personal experience lies predominantly with software so my posts will most frequently deal with that aspect of automation.

Continue reading What is Test Automation?