when relevant content is
added and updated.
One of the amazing things about working in the domain of software quality assurance — or QA, as we devotees so fondly refer to it — is that everyone agrees that there are standards yet so few people agree on what they are. Take for example the very basic definition of a Test Case. If you Google that phrase, you’ll see there are around 46,700,000 references! Usually near the top of that heap you will find a Wikipedia defintion. I know, Wikipedia can be controversial because of the communal nature of its content, but the link is right on top and I don’t like to read 46,700,000 of anything.
Anyway, Wikipedia states “A test case in software engineering is a set of conditions or variables under which a tester will determine if a requirement or use case upon an application is partially or fully satisfied.” Hmmm…engineering…conditions…variables…it all sounds very scientific to me.
Well then, let’s examine the concept of test case in the light of scientific method. In fact, you could say that a test case is the application of scientific method to the process of discovering whether or not a software product is suitable for delivery to the customer. It involves a few very specific steps:
1. Ask a question about something observable: for software, this question would be about a requirement, How does this really work?
2. Research what is already known about the question: in our software example, design documents, process diagrams, screenshots.
3. Formulate the hypothesis: knowing what I do about the requirement, what do I need to do to prove how it works?
4. Test your hyposthesis by doing an experiment: develop and execute the procedures, or test steps, that are implied by your test case.
5. Analyze the data and results obtained from performing the test case, and draw a conclusion: Pass, or Fail. Did the software behave as expected and meet the requirement?
6. Publish the results: if there were problems, create defect reports and begin the iterative fix/retest cycle. Keep all your test data to build metrics for process improvement. This includes your test cases, both for traceability and potential reuse as regression tests.
By Jove, I do believe we’ve located the missing case after all!