3

Whenever, i am working on my task of Analyzing the functional specification or requirements documents of any new Feature, enhancement or Defect fixes, I just go through what is clearly evident in the spec and don't really think of all use-case scenarios, then and there.

Due to this, sometimes, i miss some important cases that were initially not included by the Business Analysts. I identify those issues/discrepancies too late in the cycle and this delays the whole agile process.

Sometimes, complex/tricky Test Scenarios are missed and this creates lot of slipped bugs in the product.

Also, when i finally point out the issues in the Functional spec, then the Development team has to deliver a new build to QA with all those features implemented. This decreases team productivity.

How can i as a Tester improve this process.

Improve this question
1
  • Although you mention 'agile' it seems your "team" doesn't operate as "one" team but is very compartmentalized?
    – Ray Oei
    Commented May 23, 2018 at 17:48

3 Answers 3

Reset to default
3

Review business and functional specifications on early phases. This should not take much time. Don't be afraid of asking questions and to look silly. After all this is your job to find bugs and bugs might appear not only in the code but in specifications as well.

Force your analysts to keep the specifications structured.

Use mind mapping tools when you review the specs. This will help you to structure the information in your mind even if it is not structured enough. This will also help you to emphasize particular areas which might miss details or dependencies.

Improve this answer
2

You see that as a problem, I see that as normal development process in an Agile team. There is a reason why The Agile Manifesto says

Welcome changing requirements, even late in development

Like you demonstrated very well in your question, it's very hard to know everything in advance. If you and your team really adopt Agile you will drop writing detailed requirements and focus on

Deliver working software frequently

side notes-

  • Why are you, as a tester, the only person responsible for "debugging" the requirements ? or maybe I misunderstood
  • Your question is much more about project management than about testing
Improve this answer
1
  • And I would add: discuss features and (possible) related use/edge cases and whatever pops up, together before and during finishing the code. So you all, as a team, have a bigger change of discovering, preventing/solving issues. Instead of you being the (only) one that didn't discover problems. This is a team challenge, not only a tester(s) issue.
    – Ray Oei
    Commented May 23, 2018 at 17:51
1

As a QA Tester, you can take some time out before starting testing and using that for writing extensive use cases which will cover most of the scenarios. This will help you in later stages. However, no matter how much you strive to think all use cases, some are missed. We tester are humans too.

Let the business analyst know about the specification they missed in the Requirement Doc, and also let the higher authority knows about it. As the BA missed the requirement, the developers fail to develop it and tester fail to identify it in early stages of testing.

As the specs were not mentioned in req. doc, how are the Tester going to know that the requirements are needed??? The tester really needs to think out of the box to do this. And if you are doing, you are doing great. Tell the BA to improve their process of Doc analysis.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.