I wrote a blog recently “the value of a software testing process” in which I questioned the traditional benefits of software test scripts based on the re-use and repeatability theory.
My approach to any rapid change software development is to make a some basic assumptions
1) The code is going to change quickly
2) The person who coded won’t necessarily be there for the next release
3) The person who tested the last time, won’t necessarily be there for the next release
4) Test documentation helps to provide structure and is excellent as a guide to ensure adequate coverage
5) Testers are able to think outside the square and aslo be able to fill in the gaps in a test
I use one spreadsheet (if possible) to track the following information;
a) test script number
b) test link (if available which is a reference to requirements etc)
c) test purpose – a clear concise description of what I am planning to test
d) test results – Pass or Fail
e) defect number – I assign a number of use the defect tracking system
f) test estimate – the time I anticipate it will take to test this functionality
I use the document to first scope out what I want to test, a quick and dirty overview of what I am planning. I also use it to estimate how long testing is going to take. This is helpful if I am ever asked to substantiate my estimates.
Once all stakeholders are in agreement onto the scope, I create a concise and descriptive purpose of each test. This is in essence my test script. I use the same spreadsheet to enter results, defect numbers and to calculate simple metrics such as the pass rate.
I have uploaded an example below;
I hope you you find this post useful. Please feel free to use the ideas I have here.
Sign in or become a Anne-Marie Charrett member to like this post.