Mukesh is currently working as the Technical Lead in the Software Quality Assurance Engineer team with Clarice Technologies for approximately 2 years. He has worked on multiple android and iOS projects. Prior to joining Clarice, Mukesh worked with Allscripts on various enterprise solutions for 4 years.
This article is the outcome of a string of QA discussions that take place within the Clarice QA Forum. We will be seeing many more such interesting articles to discuss some common problems that a tester always experiences in his/her profession through a series of write-ups such as:
- How to deal with frequently changing design scenarios?
- What to do with the old test cases which are less relevant every new cycle?
- How can we reduce our re-work and still provide quality?
Who moved my label?
Well, there isn’t a silver bullet for this and the solutions are always subjective. Solutions vary from project to project however we can always minimize the intensity of the issue by taking below points in to consideration:
1. Preventive Measures:
Functionality is the Key, not UI:
- While creating the test cases document in an environment where the design change is very frequent, it makes most sense to write test cases / automation scripts based purely on functionality
- Lesser emphasis on UI elements will help reduce the rework effort and specially when majority design changes in your project are based on the UI (not work flow)
- Even if some design changes occur related to functionality, we can always update the test cases
QA in early phase of the cycle:
- If we could make it a process where QA is included right at the design level, we could get rid of most of the design flaws. QA can thus contribute towards Design QA
Fix the labels:
- Whenever we have automation involved, the labels of all UI elements such as buttons and fields should be properly maintained. So if any structural changes occur in future we don’t have to update the scripts
Below is a basic flow diagram which will help you visualize this problem better followed by certain ideas to solve the problem mentioned above:
2. Curative Measures:
Fix a time bound milestone to update test cases:
- At the test plan level, incorporate some buffer and plan bandwidth to update the test cases based upon any design change that may come up
- We should update the test cases based on the duration assigned in the test plan. This will eliminate the multiple efforts of updating test plans
- When projects have frequently changing designs/functionality, we need to focus on and check the features which are getting implemented/updated in the upcoming build. We should update at least those parts of the test cases which are related to the implemented/updated features
- Instead of putting off the task of updating the test case document when the design has been frozen, we should keep it updated as per changes in each build. This will gradually eliminate the huge task of updating the entire test case document at the end of the cycle
Frequent review with clients/designers:
- As a QA, we should have frequent review of our test cases with designers and developers. We can get hold of their plan to change the design much ahead of the actual change. In the mean time we could think of a QA strategy and plan for anticipated design change
I look forward to your comments…