Testers who are new to agile software development often struggle to find a way to test the code in smaller pieces. This is mainly because they are trained to test only after everything is done. It is big change in mindset for them.
I think testers should take an approach that they are just trying to see if the code works. Though they might be really testing it, an “I am just trying to see… “ mindset will make them loosen up from the formality of entering bugs etc. Every time the developer says that something testable is checked in, tester should try it and inform developer if it doesn’t work. This notification could be as informal as telling the developer at the water cooler or send an email or add a task card to the task board.
Once tester has tried the functionality enough times and gained confidence that the functionality is mostly working, she could do more formal testing. However, at this point, testing the standard cases should be a breeze, and that allows tester to spend more time on exploratory testing.
Sure, this causes fewer bugs to be entered in the defect tracking system, and some testers seem to be concerned about that. One tester told me that her performance review is based on how many bugs she entered. I think it is a really bad thing to use that metric. In this situation, probably the tester prays for her teammate (developer) to fail, so that she can have a better performance review. All members
of a team should have common set of goals rather than conflicting ones.
Another concern I’ve heard is that if you don’t enter bugs, you can’t control the quality. That doesn’t make any sense, because at the end of a sprint, if you don’t have any bugs to enter, the code is of highest quality.
5 thoughts on “Try first.. then test”
I completely agree with that. If developers are willing to deliver with frequent testable code, they will come up with techniques to do that also. Also, if developers are writing executable unit tests (if TDD, it is even better), they would be lot more confident about their code. In general, I suggest that each user story should be built in multiple end-to-end slices (I call them threads). This way code could be tested slice by slice. If there is enough automation, at unit level as well as higher levels, the regression cycles would be lot smaller.
Great post.. I am have been working in Agile scrum and we are also trying to follow the same..but more than the testers, developers are not very keen to give the code before they complete story or a service layer/UI of a story (testable stuff) to testers. We have to change the mindset of both testers & developers to make this really work. Just a small thought we can also consider doing incremental regression testing when they work on the sprint/iteration which would help to find the issues early stages.
Pingback: QuickLinks for June 2011 | (Agile) Testing
Good post Nanda. I have also heard people say that “Agile cheats by testing early” when they see that the code coming out of a sprint (iteration) has zero defects. Like you said they all miss the point that our collective goal is to build quality software in an efficient way.