What are the approaches for writing test cases? How to simplify test case maintenance? How can a test management system improve your QA process? Zebrunner team hosted a webinar “Manual QA: Identify and fill the gaps in your testing process”. Dmitry Kostrykin, the senior QA engineer at Solvd, has clarified all the above-mentioned questions.
There are two opposite approaches to writing test cases.
The first approach relates to smoke, sanity, and MBA test types.
Smoke tests focus on a determination of whether the system is stable enough to proceed with testing. Those types of test cases usually address basic questions like does the application work, whether the feature operates properly, etc.
Sanity tests verify if the system is working as expected after minor changes.
The main difference between smoke & sanity tests lies in the execution. Smoke tests are usually executed in the earlier phases when you get the first build and the application is not stable yet. Sanity tests are executed at the latest stage. You need to check whether your application is still stable as was before and if it’s not impacted by the previous minor changes.
MBA tests stand for Minimal Business Acceptance. This testing type covers most business-critical flows. Without proper working of which it doesn’t make sense to use the application at all.
In your project lifecycle, smoke and sanity test cases are running dozens of times. “Make sure your test cases are fast to execute, independent of other scenarios, and cover the most crucial uses paths without too much detail. We have to guarantee that we can quickly reuse and execute such test cases”, Dmitry recommends.
The second approach relates to regression and functional testing.
Regression testing checks if existing functionality is not negatively impacted by recent system changes. This is detailed and granular testing of specific functions and interactions between different parts of the system.
Functional testing verifies if the system meets the requirements and functional specifications. Functional tests are written with a focus on all functional flows of the system and their ability to meet business requirements.
“With such test cases, we are not too focused on the specific execution. Here we have to ensure that we completely cover all possible details and all flows on the application. Also, we have to ensure that we are not missing any details”, Dmitry adds.
Zebrunner Test Case Management boosts up test case creation and provides you with features that streamline the manual testing routine. Use ‘shared steps’ to simplify future maintenance of test cases, and ‘drag-n-drop feature’ to move quickly test suites, test cases & test steps. Import your existing test cases from other test case management tools in one click.
Shared steps are a specific type of test case which can be reused and inserted in the body of default cases to optimize your efforts. Shared steps facilitate test case maintenance. Any changes to shared steps will be reflected in all test cases that use it. Shared steps are especially helpful in regression testing because you can use the same steps in multiple test cases.
When you need to execute the same set of steps during different validations it doesn’t make sense to write them again and again. Create only one single share step which will contain all the necessary details. Then, insert it into your test cases. If this functionality is changed, you don’t have to rewrite all your test cases that include the same set of steps. You do it only once, and all your changes will appear in all the test cases which are using shared steps.
Dmitry’s advice is, “There is no one strict approach on how to organize a test case structure. Choose the method which suits your project and your team’s needs best, and which will be clear and understandable for you”.
There are three examples of how your test cases can be organized:
- By functionality or by areas of your application
- By test level
- By testing type.
A good approach is combining test structuring methods within each suite. Another approach is the definition of test case attributes.
Test case attributes allow you to specify some meta information on a test case level. This way you can categorize your test cases properly. There are various types of attributes: test level, test type, regression level, site area, functional area, device type, etc.
Most test management solutions provide you with the possibility to customize the test case attributes. Define what attributes bring value to your project and establish them. “Setting up a proper process and rules for use of additional attributes at the test case level will give you the flexibility in searching for test cases and reporting”, the webinar speaker says.
Test run planning
A test run is a set of test cases that must be executed within a given period. A test run is based on specific goals and milestones of your project, as well as the overall testing strategy you use.
Top factors to consider when you are planning a test run:
- Scope of testing. Verify what functionalities are being released and deployed and for what environment. Select relevant test cases and include them in your testing scope.
- Testing types for execution.
- Timelines for testing. It allows you to meet deadlines.
- Available resources.
- Impact area. Discuss with developers if the latest changes in the application can impact other areas. In case it’s possible, include additional validations in your test run.
“Make sure you create test runs that are flexible and adaptable because project requirements and timelines can change over time”, Dmitry Kostrykin points out. Also, he suggests unifying the test case structure. “You can work with various phases of the project lifecycle or you can work with different projects. Everything above-mentioned requires different data sets and different actions from you. Customization of your layout is pretty useful here. This way you can tailor test cases to your specific needs”, Dmitry says.
Peer review helps to evaluate a performed work. In software testing, peer review is a validation of test cases and test plans by other project team members. It increases test case accuracy significantly.
QA Engineer. He validates and reviews any documentation you have created. In terms of manual testing, this can be represented by test cases, test plans, test strategies, and any other test artifacts. QA engineer provides you feedback on whether your documentation meets QA standards, whether it covers all the necessary scenarios, and whether it’s feasible and accurate.
Developer. He focuses on checking if your QA documentation is technically accurate and whether it meets all the standards, whether it meets and covers all the functionalities which he has developed during the development phase.
Business analyst or Functional analyst. This person reviews whether your QA documentation is covering all the functional flows of the scenarios and whether it covers all the acceptance criteria which have been specified in user stories.
Product owner. He does a peer review from a business perspective. The product owner focuses on whether your QA documentation meets the business needs.
There are a lot of different ways how to establish a peer review process:
- Assignees. Create a test case and assign it to another person. He will review it as soon as it is reassigned.
- Additional properties. Create in the test case management solution a custom attribute called ‘review status’. It can have multiple values in the dropdown like unchecked, checked, in progress, etc.
- Suites. This practice means you have some dedicated suites that contain only not reviewed test cases. Once these test cases will be reviewed, they will be moved from the specific suite to the final one.
- Test case titles. You add a specific word in the title of your test cases. As soon as these test cases are reviewed, you remove this word from the title.
- Labels or tags. It can be a simple line of text with some labels.
- Comments. Add a comment field and monitor comments on the level of every test case.
- Slack notifications. Create a special Slack channel and integrate it with a test management system. You will get notifications in Slack when your test cases will be reviewed.
Use test case management system opportunities to track the status and progress of reviewed and not reviewed documentation.
