4

The process which we generally follow for quality is:

Everytime we receive a Requirement document, we study the same, analyse it, discuss it and then after multiple rounds of the same process it is finally kicked-off i.e. Business Requirement Document (BRD) is reviewed and approved and can be referred both by developers and QAs. So as a part of QA team we are assigned with the task of creating test cases as per the BRD, sometimes we have mock-ups to refer and most of the times we don't have any mock-ups.

Now, the issue being faced is we are able to create test cases as per BRD, but they are always not enough because BRD covers only the Happy paths or you can say the positive sides of the product i.e. How product is expected to work., it doesn't contain anything about the real world interference of the product or the negative cases. Due to all this, many issues are reported during the dynamic testing phase, when system is actually being used or tested. Such bugs/issues are reported which are not documented at all during the test case creation phase.

Because of all this, test report many a times says test cases are passed (not 100%) but still there are lot of bugs or in easy way many bugs exists at tracker which do not have any Test case ID (ideally every bug should have a test case ID, may not be 100% but at least 80-90%), to overcome this situation many a times QAs have to create or update test cases according to the bugs (which I know is not a good practice). This problem becomes more severe when we don't have any mock-ups.

  • How such bugs can be captured, using the Proactive approach i.e. create test cases first and during their execution report the bugs (if any) or the approach we are following is fine?

  • How one can be sure that, only the execution of created (reviewed and approved) test cases will lead to good quality?

As many issues are related to -ve scenarios which are missed in documentation. Either we need to change/update Testing Approach or we need to update the mind set (resource training etc.) for creating test cases. I hope many other manual testers have faced the same issue.

Improve this question
2
  • Have you explored "explorative testing"?
    – dzieciou
    Sep 18, 2015 at 8:09
  • Why don't you write negative test cases to check the quality?
    – Muhammad Ali Khamis
    Apr 26, 2017 at 14:43

4 Answers 4

Reset to default
2

Not all test cases will derive directly from a requirement. The requirements document is a necessary, but not sufficient basis for test coverage. If there are bugs not linked to test cases, you must try and see if there are paths through the software that are not being tested at all (if this is the case, write a new test case that can "find" the bugs that were orphaned).

Improve this answer
1
  • Right, we sometimes follow this approach of updating the test cases, but we update test cases only for those scenarios for which we found bugs. Perhaps this is the gap in test case coverage.
    – Dhiman
    Sep 18, 2015 at 14:42
1

Test Cases from

  • Requirements Perspective (Functional Cases)
  • Implementation Perspective (If Implementation has some Async processing, Queuing, Batch processing, Depending on implementation you can deep dive to cover +ve and -ve implementation cases)
  • Support Perspective (Depending on above implementation aspects Supportability, alerting, retry, notification aspects)
  • Customer Perspective (Data Migration, User Friendly aspects, Mimic actual customer workflows at every level (agent, store manager, admin, operations etc..)
  • pair up with dev and do early testing to get better knowledge on above areas
  • Meet customer to get better perspective of different usage patterns for different roles (agent, store manager, admin, operations etc..)

It takes time to build knowledge of product, understand customer expectations and bridge both expectations from QA perspective. This is a recursive excercise with repetitive learnings in building the knowledge and familiarity.

These are pointers to address key core areas.

Improve this answer
0

Your problem is specific on how to handle bugs coming out of -ve testing where there is a lack in -ve test cases. As above answer says: all test cases can't be derived from requirements directly, the real world scenarios comes up with the questions you ask from Business Analyst. for that you need develop the attitude of end user to understand the actual usability of the application being developed, once you have that you'll not be bound by the requirement rather you'll be the one who can give a valuable and constructive feedback to Business Analyst and in turn your test cases will have a fair coverage. Hope this helps.

Improve this answer
0

Test cases based on requirements are useful, and needed, to perform a regular acceptance test showing that the product works correctly with the expected behaviours (user requirements).

Several different test types should be added and regularly performed by the team for a complete test, but, for the aim of your question, you should include in your test plans at least the cases needed to reproduce most critical bugs you have found. It is useless to say that in this case we are talking about regression check that should be managed implementing testing automation.

Improve this answer

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.