Klemsy - Fotolia

Manage Learn to apply best practices and optimize your operations.

5 SMART goals for a QA analyst

QA testers can earn respect and gain influence with peers through SMART goals. Take ownership of the software you work on, look up to good product managers and achieve these five goals.

Skilled quality assurance analysts exhibit an inexhaustible curiosity that drives their work. Software testing is one of the few professions where people get paid to find out how something is supposed to work, then immediately try to break it -- and get praised for their efforts when they do.

To get ahead in this somewhat wacky profession, testers must get serious about setting goals. Cultivate a passion for understanding how things work; that's a smart goal for QA analysts from the very start of their careers.

Every QA analyst should spend some time learning more about how and why things work, especially things that have nothing to do with computers and software. Ever wonder how mechanical cash registers kept a running tally of the day's sales? How were telephones connected via a patch panel matrix called a switchboard? These are great questions for testers to ponder and research. With that background, it becomes obvious how computers and the software that instructs them improved upon sales tracking, or how communication circuits can be established without human intervention.

Curiosity is one thing, but advancement on a career path is another. So, what are some specific, measurable, achievable, realistic (or relevant) and time-bound (SMART) goals for a QA analyst? Here are five individual goals a tester can target to stand out.

1. Get indoctrinated in business process mapping

This SMART objective is easier said than done, but it's well worth the effort.

For starters, lobby the test lead or QA management to spend time in the trenches. When testers spend time with business users who help work flow from input to output, both sides can learn from the experience. Understand the data that higher management needs to make good business decisions, and learn when it's safe to hand off work from one team member to another.

Don't just observe. Ask lots of questions about what constitutes individual units of work and how business users would like to see them improved.

Use a flow chart tool like Visio or Lucidchart to create diagrams that highlight where key business decisions are made. Detail these decisions in terms that will help the development or test team later, automating a manual task or improving an existing algorithm, for example.

This work is akin to what a business analyst might do, but it's a smart goal for a QA analyst too. The tester's objective here is to become as much of a business subject matter expert as possible in how work is done in the organization. When it's time to create test scenarios, they'll be able to determine what's in the software's critical path versus an edge or corner case.

It might not be possible to shadow software's end users as they toil through the day, but learn any standard operating procedures that might be lying around. If no documentation for these procedures exists, draft some with an eye toward a QA audience. Ask why something is done a certain way, not how it is done.

It's difficult to measure this individual goal. It's all about gaining an overall knowledge of how processes work on the business side. Understanding this bigger picture will yield better test scenarios, rather than simply improve test execution steps. One way to measure this goal is to see whether a tester can fill in for someone on the business side in a time of emergency, or stand in for one during code deployment verification. But trying to review or validate this measurement might result in a point of diminishing return.

2. Understand the basics of programming logic

Forget about learning a programming language inside and out. After all, QA analysts don't write the code. However, programming logic is important. All programming languages have several basic logic structures in common:

  • if-then-else
  • case structure
  • dowhile
  • dountil

Software testers need a basic knowledge of these programming language staples for continued career growth. Successful execution of manual tests and automated scripts is helpful, but testing activities only go so far. It's even more important to know the conditions under which data enters into one of the programming structures, and what must happen for that data to exit it.

Let's start with if-then-else logic. In this structure, if is whether a condition exists. If it does exist, then execute the then function. Otherwise, execute the else function (or do nothing). The if-then-else structure works well when a condition is true or false. A case structure might be appropriate, when a condition falls into one slot in a range of possibilities.

A case structure expands on if-then-else by providing multiple functions to execute if certain conditions exist. For example, an if-then-else structure might check if a number falls in a range between 2-10 and, if it does, then the number is multiplied by five. If the number is not in that range, it will fall into the else condition, and is not multiplied at all. A case structure specifies what to do when a number falls into one of many ranges. In this example, when a number is between 2-10, it falls into Case A and is multiplied by five. If the number is between 11-20, it falls into Case B and is multiplied by four. If a number is 21 or higher, it falls into Case C and is multiplied by three. Case structures can get complex and involve branching into other parts of the code.

Dowhile and dountil are basically loops. With dowhile, a function is performed as long as a condition still exists. A dountil logic structure performs a function until a condition no longer exists.

While the book itself is a bit dated, Tools for Structured Design: An Introduction to Programming Logic by Marilyn Bohl and Maria Rynn, 1978, helps convey the ubiquitous precepts of all programming languages. A grasp of programming logic in a language-independent manner helps with comprehension of the entry and exit criteria to test discrete pieces of code. This domain knowledge marries a business process to the most appropriate programming structure. A yes/no decision point in a business process generally maps to an if-then-else structure, whereas a decision point that requires an answer to one of three or more questions might require a case structure.

Measure knowledge of these concepts by reading through the code with business requirements in mind. Is it more understandable than before? To achieve this goal and implement process improvements, a QA analyst might work with developers in a test-driven development (TDD) environment. In TDD, the QA and development team collaborate on unit testing of discrete pieces of code. Code is written and made to fail an initial test, then refactored to get it to pass.

3. Brush up on QA history

When goal setting, don't repeat the mistakes of the past. Learn what types of processes came before -- failed or successful -- and how those testing processes set the groundwork for existing ones.

The way to measure understanding the past is to see if it helps achieve better Agile performance. While the traditional software development lifecycle (SDLC) and Waterfall methodology eventually resulted in bloated products and documentation, lessons on the intent and approach might still be useful today. Borrow principles and concepts from the past and mold them into usable processes.

Check out the book Customer Oriented Software Quality Assurance by Frank P. Ginac, originally published in 1998. This lightning-fast read paints a picture of how and why the Software Engineering Institute's Capability Maturity Model (CMM) caught on with many organizations in the late 1990s. It might be an eye-opener to realize that some CMM concepts are still relevant.

OKR examples for QA analysts

While it's helpful to pinpoint SMART goals for a QA analyst's career advancement, don't lose sight of objectives and key results (OKRs). OKRs are a collaborative means to define personal or project goals, set meaningful objectives and track key results to realize their outcomes.

First, the QA analyst determines a testing objective, then defines the logical key results that will enable them to meet it. As with SMART goals, track your OKRs to see the best results.

Here are some OKR examples for QA engineers.

  • Objective: Increase test coverage for a new product release.
    • Key result 1: Work with developers to automate 75% of test cases.
    • Key result 2: Boost code coverage to 90%.
    • Key result 3: Use a device farm to test on many end-user devices simultaneously.
  • Objective: Boost testing outside of QA stage.
    • Key result 1: Implement test-driven development for early refactoring.
    • Key result 2: Enhance automated regression testing.
    • Key result 3: Test in production to catch bugs under real conditions but before users see them.

Editor's note: This sidebar was written by site editor David Carty and approved by contributor Jim Brown.

4. Become a master of conflict resolution

This SMART goal for a QA analyst is another one that isn't easy to measure, but it is nonetheless important for career success.

A QA analyst's job is ultimately to find problems with the company's product -- ideally, before users do. Thus, the tester is often the bearer of bad news. Sometimes developers let out a sigh of relief when testers catch a bug before code moves into production. But there are also tussles between testers and developers, the latter of whom are adamant that their code is not at fault for issues. Developers might argue that there's a bad or incomplete requirement, or the testing wasn't done correctly.

Acquire the ability to mediate conflicts. It is a skill that will help quash issues between team members over the root cause of a defect, especially when the added project time required for remediation and retesting can lead to additional stress. Set an individual goal to mediate a certain number of conflicts.

Conflict resolution is an art that requires confidence. Conflict raises anxiety, and it can breed animosity. Deflecting or avoiding conflict entirely is a goal worth attaining.

5. Boost project management skills

QA analysts really run mini projects within a project. Test planning, resource allocation, test execution time estimates, scheduling time for defect remediation and slotting time for retests -- these are all small, individual projects that contribute to the overall QA for the software project. All of these efforts require some project management skills.

A project manager will block off time for test cycles, or sprints, within an overall project plan, but that person isn't always able to get to the minutiae that a QA analyst does. Some CMM practitioners require QA analysts to fill in the testing tasks and timelines in an overall test plan, lifting some of the burden from the project manager.

To stay in tune and relevant today, look into the Projects In Controlled Environments (PRINCE) model, which has morphed into PRINCE2 Agile. The PRINCE2 Agile strategy specifically focuses on how project management and Agile product delivery combine as disciplines, which makes it very relevant for QA analysts.

One way to measure and achieve this SMART goal is to gain certification in a standard like PRINCE2, Certified Scrum Master or Professional in Project Management.

By meeting these effective goals, QA analysts can potentially advance along their career path to a position where they can still apply their testing skills and keep their intuitive minds sharp.

Dig Deeper on Topics Archive

Join the conversation

3 comments

Send me notifications when other members comment.

Please create a username to comment.

I agree completely. I guess that I never though of it in these exact terms, but what I do is to take ownership. There are just so many ways in which a product can fail that have little or nothing to do with its functionality. 

It might not meet the needs of the user. It might not make/save money. It might create a lot of support issues that are not necessarily bugs, such as questions from confused users. The performance might be terrible. 5 years down the road, it might be used for a different purpose than it was intended. These are all things that I try to think of when we're creating or changing a product. It feels like a large weight on my shoulders, but it gives me a healthy amount of anxiety that keeps me thinking. 

It's no fun when a product isn't as successful as hoped for, even if it's not directly your fault. Taking ownership means that you try to prevent those cases, and mitigate issues when they do occur.
Cancel
I'm not sure I agree with the idea of QA "taking ownership of the product". Testing's responsibility is to discover and subsequently reveal as much information about the product and its behavior as possible, but decisions will always be made by the product owner, not the tester. I think taking ownership of our responsibilities makes more sense. It's important to develop the relationships that will help you do your job effectively, but viewing this as 'management' will likely not help with those relationships. While the examples here are great examples of good things to do, the descriptions feel a little...overzealous.
Cancel
It's a swell thought, but I'm not sure how many places I've worked that have actually given the QA staff that level of power. They're usually right up there -- or down there -- with the technical writers on the staff totem pole.
Cancel

SearchCloudComputing

SearchAppArchitecture

SearchITOperations

TheServerSide.com

SearchAWS

Close