Top 5 Challenges of a QA Tester: Day #3

Because of where testing falls in the timeline of most projects, any delay to the project will immediately affect QA. Although this affect can be less severe in an Agile Development environment, testing still happens after development. This means that any delay in the project will have a ripple effect that can play havoc with your testing schedule.

Challenge #3:
Position of QA

Here is why:

• The testing required to fully test a product is estimated by QA – and agreed upon by the project team early in the process
• The effort is then translated into an amount of time (total estimated tester hours)
• Based on the number of testers available, a schedule is created detailing what testing will be executed, when, and by whom
• This estimate is integrated into the project schedule

Since QA, when properly done, measures most (if not all) of their work, these estimates are based on hard data. They are based on results culled from having executed these types of tests time and again. So, they are not mere guesses but are known, measured, quantified results. QA knows how long it will take to test something because it has been done before and QA has those results!

At this point it all looks good and everyone is happy and friendly. Then something happens to the project. One or more of the following scenarios may happen:

• Features are added to the product that were not originally in the schedule
• A feature is more difficult to implement than initially thought – so the development team delivers a feature later than expected
• A developer is out sick and so the delivery of a build to QA is delayed

Any one of these scenarios mean that QA does not receive the build with the agreed upon features when it was agreed that they would receive it. Again, this does not change the shipping date – only the amount of time available to test.

Can you see why any delay to the project will definitely affect your planned testing? This doesn’t even account for any inaccurate estimation given by QA about a feature that will take longer to test than originally thought.

Because the testing of a product is positioned between the development of features and the ship date, and since once a feature is coded it is often assumed it will be a shippable feature, once QA gets a build, the clock is running. The company does not want to change the date they promised a product would ship, so any delay must be made up during the testing phase.

Here are a few simple actions that you can take to help minimize the impact of these scenarios on QA:

• Review all specifications and documentation for a project as early and thoroughly as possible
• When reviewing the specs and docs, point out any and all errors, omissions, conflicting statements, unclear behavior, etc.
• For the company, this is the least expensive place to find a bug
• For you, it alerts others to issues that need to be addressed before the testing clock begins to tick
• This also shows that you are paying attention to every detail of the project from the outset and will help you be viewed as a real professional
• Plan ahead for any testing that appears it may be time-intensive
• What efficiencies can you implement to reduce the time this testing will take?
• Are there tests that you can run in parallel to complete your testing sooner?
• Be prepared to work overtime when the testing schedule gets compressed

None of this is to say that these effects are unavoidable! On the contrary, they certainly are if the proper steps are taken prior to beginning a project. If the project is planned with accurate forethought, these affects will either not occur or can be vastly minimized.

I once worked for a QA Manager who believed (rightly, in my opinion) that the need for QA to work overtime was almost always due to some other part of the project team making an error. Somewhere along the line, someone did not accurately estimate the complexity of implementing a feature, or allowed additional features to be added late in the project. So we took steps every day to minimize the impact of these potential scenarios:

• Always looking for how to improve our process and procedures
• Always searching for a way to test more efficiently without any loss in test coverage
• Always alerting the project team if there was a potential scheduling issue looming

I once worked for a company that had a project that continued to experience development delays. What they decided to do to account for these delays was to have QA work overtime. This is not a rare occurrence, but this particular situation amazed me.

They had that QA team of 20 testers work 15 hour days, 6 days a week, for 3 months! Think about that. Have you ever worked a schedule like that? I’ve seen it and it is NOT pretty.

I have never seen so many people look like the walking dead at a workplace ever! To their credit, the product did eventually ship…I think it was on time. Of course, there were a few bugs when it shipped – are you surprised?

In order to be a truly effective tester, you must be attentive to every detail! If you work the hours that those testers did, there is no way you will be as aware of what you are doing as you should be.

This has many detrimental effects to the project (not to mention on the budget):

• The most obvious outcome is that you will miss bugs
• When you find a bug, you have a greater chance of entering it as a duplicate
• When you enter a bug, you have a greater chance of omitting crucial information
• When regressing bug fixes, you will not be as thorough
• You will enter a greater number of issues that are not truly bugs
• And the bugs that you do enter will not be as thoroughly vetted out as they should be

I am not making this up. This is my experience of working with testers who cannot pay the proper attention to what they are doing.

Companies ship their product, but not without a high cost both to their budget and to the quality of their products. The consumer receives lower-quality product, the company’s brand and reputation are negatively affected, and the project team is highly motivated to leave for another job at their earliest opportunity.

Take proactive measures to build in as many testing efficiencies as possible. You will need the time savings eventually. And if overtime is not required, you can show off how quickly you can zip through a test suite without sacrificing thorough test coverage.

The real reason for the use of pressure and overtime may be to make everyone look better when the project fails.
~DeMarco