This took much longer than I anticipated with the test scripts needing to be revised after my UAT resource (my partner who is a developer) felt they could not understand the requirements. It was an excellent lesson on using picture representation solely, to identify the steps and expected results that meet the acceptance criteria.
This asks the obvious question what makes an excellent test case and how do you write one?
For me, it’s written in simple language, with minimal acronym’s unless the author has included a reference legend and includes the following points:
- Title identifies what the test is
- Precondition & Assumptions are included
- Clear steps to follow
- Expected results
Reusability is needed to minimise any resource waste. Being mindful of the range of testing experience and the complication of the systems I always have a library. On a greenfield project (assumption mature projects have this setup) when I first start learning a system, I create End-2-End test cases broken down into reusable mini test cases you can assemble together. As the library grows with the complexity of testing I can create my system test case and have reference links back to the library for expected precondition set-up. This I have found valuable when new team members come on board or the stakeholders decide they would like to look at creating an automation suite. There may be some pushback from the business around this as they may see it as unnecessary work but I feel it’s supporting the business in their future growth and a simple strategy for the prevention of knowledge loss. Part of my role is to identify these risks (within testing) that may impact on the company’s strategic objectives, revenue or costs and take them on that journey. As a holistic tester, I do not only focus on testing code changes but I consider the entire business ensuring changes are aligned with vision statements, road map or strategic planning.