5 SMART goals for a QA analyst

What are SMART goals?

The SMART goals framework helps those who employ it set meaningful, realistic goals. To set SMART goals as a QA analyst, first learn what a SMART goal consists of:

• Specific. Goals in this framework should be as specific, clear and focused as possible. Ambiguous goals leave margin for distraction or waste.
• Measurable. A measurable goal provides information that lets teams track progress and gives concrete benchmarks for achievement.
• Achievable. A SMART goal is achievable -- completing it within the allotted time frame is possible.
• Relevant. The goal should align with the broader objectives of the team and organization.
• Time-bound. The goal should have a target end date.

5 SMART goals for QA analysts

With a basic understanding of the SMART framework, consider these five example SMART goals for QA analysts.

1. Get indoctrinated in business process mapping

This SMART objective is easier said than done, but 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 sound business decisions and know 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, such as 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 also a worthy goal for a QA analyst. 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 creating test scenarios, they can 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 improving 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 an emergency or stand in for one during code deployment verification. The team could theoretically use the key performance indicators for that specific process to measure the QA analyst's performance as a stand-in. Trying to review or validate this measurement might result in a point of diminishing return, however

2. Understand the basics of programming logic

Though it's not a critical requirement for QA analysts, coding proficiency can help to keep up with changing test methodologies and improve automated testing.

Traditional QA analysts and manual testers won't require as much coding knowledge as SDETs or automation QA engineers. After all, QA analysts don't write the code. However, programming logic is important for any QA profession. All programming languages have several basic logic structures in common:

• If-then-else.
• Case structure.
• Do-while.
• Do-until.

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 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, a number between 2-10 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.

Do-while and do-until are basically loops. With do-while, a function is performed as long as a condition still exists. A do-until 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, originally published in 1978, helps convey the ubiquitous precepts of all programming languages. A grasp of programming logic in a language-independent manner helps comprehend 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.

Read through the code with business requirements in mind. Is it more understandable than before? A QA analyst might work with developers in a test-driven development (TDD) environment to achieve this goal and implement process improvements. 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 setting goals, don't repeat mistakes from 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 of 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 shows how and why the Software Engineering Institute's Capability Maturity Model (CMM) caught on with many organizations in the late 1990s. It might be eye-opening to realize that some CMM concepts are still relevant.

A SMART goal might be to read the book and draw parallels between the book's subject matter and current practices, then use those parallels to improve Agile performance in the organization according to specific metrics.

4. Become a master of conflict resolution

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

A QA analyst's job is 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 when issues arise. Developers might argue that there's a bad or incomplete requirement, or that 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. Or, take a course on conflict resolution by a predetermined date, then seek to apply the skills learned in that course to disputes in the workplace.

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 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 focuses on how project management and Agile product delivery combine as disciplines, making it relevant for QA analysts.

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

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

Jim Brown is a senior QA analyst at Boston University and a former technology journalist.