If you develop software it is inevitable to test the code that was programmed and there are several different ways to do that. For instance you can automate your tests or execute them manually. No matter how you carry out your tests you have to ensure that you test the right thing and that you test everything that is relevant. That is where test cases and scenarios come into play.
Test Cases and Scenarios
Test cases describe what and how something has to be tested. This is why they should always contain a short description, prerequisites, execution steps and their expected result. If required, test cases should also contain information about test data. Thus specification contains all information that is necessary to execute a test.
When you write test cases make sure that they can be reused and that they can be easily understood and be executed. As a result everyone, and not just the author of the test cases, can execute them without the help of others. This is an example of how we describe test cases in Redmine.
Since there is a deadline for most projects, you don’t have an infinite amount of time for testing. Therefore you need to prioritize. The good news is that you don’t always have to test the whole application. Focus on the parts that were changed and test all other functionalities roughly to ensure that no unaccounted interdependencies cause bugs. This way you ensure that the most important parts are tested. A great way to account for interdependencies between different parts of an application and for prioritization, are test scenarios.
Test scenarios are sets of test cases that represent how users interact with an application. To define test scenarios, you can interview key users or stakeholder, or you can put yourself into the position of a user and write down possible scenarios. After that you associate test cases with the identified scenarios.
Just like test cases, scenarios should have an explicit name and number and a short description, with that the tester knows what the scenario is about and what to expect.
Test scenarios can also be a good source for test cases, because going through the steps makes you think about the application and for each step you need at least one test case.
Keep Track of Test Cases
Another important thing about test cases is to keep track of which requirements or functionality is already covered by tests. Test scenarios are a good start, but a Requirement Traceability Matrix provides an even better overview of all the requirements and their associated test cases. The important thing is that you document all test cases, whether executed manually or automatically. As soon as you achieved this you will know which test cases have to be adjusted in case a requirement changes.
Something that can really help to speed up to test the base functionality is automation. For each release you only have to adjust test cases that are related to modified functionality and you can execute those automated tests as often as required. Gauge for example is a framework that allows you to easily automate functional testing. In addition to that automated integration, performance and unit tests provide a good foundation for a good product.
There are several things about tests that are important. First of all, you have to make sure that all requirements get tested. Secondly, the test cases have to contain all relevant information to ensure that they can be executed. Lastly, test cases need to be organized in a manner that they can be executed in an order that makes sense and that they can be prioritized. If you follow the tips of this post, you are already on a good way.
With kind regards,
your SCM-Manager Universe Team