The concept of Lean principles apply very well to software testing as we juggle to deliver a quality software in the fast-paced ultra competitive world. The 7 types of wastes hold significant importance for software development as well as software testing. I am not going to write about those here; rather I wish to highlight some “testing wastes” which I have experienced myself.
First and my favorite… mile long test cases with unnecessary details. It’s not written in blood that every test case has to be scripted in words. Testers should learn to write minimalist yet suggestive test cases. Don’t bother adding not-so-essential details, believe in the capabilities of person who is going to execute them: whether it is yourself or someone else. Adopt more creative and visual ways like decision tables/mind maps/tree diagrams to document test cases. Remember : sometimes “Less is More”.
Second one is about other test deliverables like Master Test Plan, Test Plan, Defect Status Reports and other whimsical documents. Imagine a project running over a period of 6 months, 3 kinds of Test Plans created which were referred to only during beginning and end of the project..that too as part of a ritual. Would it not be considered utter waste?
Thirdly, the most classic one. Tester should know WHAT to test so as to make the product best suited to the customer’s needs. System might allow the user to do tons of things but its important to target the business needs and make sure Business Critical workflows are functionally sound. It is not bad to be exploratory but don’t go wild and test something which the customer will not do even in wildest of his dreams!!
Fourthly, testing something which could give a false positive (which hides a defect) or false negative (which wastes everyone’s time who investigates it) due to a known issue. Simply put, if there are 10 steps in a workflow and the fourth one fails cos of a bug, its not worth testing rest of the steps and raising issues. You just don’t know what you are dealing with.
Fifthly, defect reports which no one can understand/interpret (including the reporter!!).
Consider the following:
Defect raised → Developer or BA attempts to analyse it —-> not enough details/crucial info missing / description not clear —-> discussion with the reporter —–> reporter trying to recall the issue (very likely it was raised ages ago!) —–> might need to redo the test to fill in the missing gaps.
This cycle looks familiar…right?? Needless to say, such a practise is a sheer waste of lot of time for multiple people.
Lastly, trying to automate test cases without weighing the ROI. It’s important to learn and accept that not everything can be automated.
The long and short of it is anything that does not provide (sufficient) value is a waste and we Testers cannot be very extravagant when it comes to spending time in doing wasteful things .