5 SMART goals for a QA analyst

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.

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.