A query on Linkedin is happening on how Exploratory Testing can complement Test Case driven testing. Here was my response.
Being a complex financial application and because I have been there I would suggest as below.
- Up-front identify the leads for the module (/logical functional and distinct area) along with the secondary lead. The Team Lead is expected to have a broad view of the entire application.
- Assuming that the domain grasp would be thorough and starting as upfront as possible with involvement of business experts. This would be critical not only for the buildup of test scenarios and cases but also for exploratory testing (there have been enough links thrown already so we all know what ET is all about).
- Ensure that the planning considers both test cases driven testing and ET. However please note that even when a tester has test cases in front of him he is likely to and in my opinion should breakaway from the test cases if his intelligence makes demands to explore behaviour that is not documented explicitly for whatever reasons. It makes sense that flexibility is allowed to the testers such that they can breakout though balanced with schedule achievement with help of target test cases per day. The focus has to be on the testers mind and why he exists (intelligent humans lending value) and credence at all times must be lent to this aspect.
- The module lead must write the test cases with reviews by secondary lead & team lead. How their work does not overlap must be planned to prevent effort overrun.
- When the test execution starts the workload is shared between the Primary & secondary (say the Cycle 1 done by Primary and Cycle 2 done by secondary). The two can also keep exchanging notes about module behaviour, defects, quirks and so on…along with running queries with business experts as needed. If needed create an excel sheet to keep track of queries / clarifications.
- The two leads over a period of time of executing test scenarios/cases would have become adept with the module’s nitty-gritties to know enough about its functionality.
- Once this is achieved it would be time to minimise the execution with test cases and switch over to exploratory testing. (I am not throwing any % since time available for testing is seldom time-boxed) The 2 in this case would be best able to intelligently explore the application in a planned manner for expected/unexpected behaviour within the boundary of the schedule.
- It is a good idea to announce prizes for the best tester with criteria announced to all up-front. It is motivating and fun if this is carefully done. It is also fun to meet in standup mode and discuss and commend people on defects which required some effort or intelligence. The discussion may give test ideas to others and the applause would motivate and bind people with good spirit. For the best tester selection criteria and since it is mostly about effort, schedule and defects – parameters around this can be set. If possible every defect could be weighed based on again parameters like defect severity, ease of understanding, reproducibility, validity, whether obvious / otherwise, creativity/depth of thinking involved, business impact & so on…
The full discussion is located here