Top 5 Challenges of a QA Tester: Day #4

The test plans, test suites, and test cases that are created to ensure thorough project coverage are supposed to be based on specifications and other documentation. This documentation should be created by marketing, product development, and engineering.

These documents are the foundation for QA to determine what to test and how to test it, as well as what the desired outcome of each test should be. Without this documentation, it is impossible for testing to guarantee complete, comprehensive coverage.

Challenge #4:
Lack of Tools

This heightens the probability that testing which should occur will not or that when the product does not function as desired, QA is not aware of it. It will also result in issues being logged that will later be claimed to not be bugs – if the desired behavior is unclear, QA is left to make their best guess as to what the behavior should be.

In this all-too-common scenario, there are still actions that you can take to minimize the gaps in your test coverage:

• Have the entire project team review all test plans, test suites, and test cases. This will not guarantee complete coverage, but it will increase the chances that inaccurate tests become identified and modified before you spend time executing them. This also helps spread the accountability for test coverage across the whole team because they have invested time and effort into vetting out your tests
• Spend time with the developers (engineers, product managers, etc.) to understand the desired functionality of the product
• When in doubt, LOG IT!
• As unfortunate as it is to log an issue that is determined to not be a bug, it is better to have a logged issue not be a bug than a bug not be logged

Find and review all of the specs and docs that you can that relate to your project, as peripheral as they may be. You will be surprised what nuggets of information you can uncover that no one thought to tell you about. This will give you more in-depth coverage in your test cases and your testing.

Another common tool missing from the QA arsenal is a real bugbase. Many companies consider the expense of a state-of-the-art defect tracking system to be a luxury. What this means to you is that you may have to work on a free, or a cheap, or an old-slow-featureless bugbase that will cost the company more in wasted time and effort in a single year or two than a real system would cost them in the first place.

For you this means that the sooner you can master your bugbase, no matter how unwieldy it is, the sooner you can minimize the adverse affect this shortsightedness will have on your daily work life. Master your bugbase and you will be a formidable opponent for anyone and a great ally for all.

If written directions alone would suffice, libraries wouldn't need to have the rest of the universities attached.
~Judith Martin