I love the fact that I have worked at a few different companies and hence have gotten to know so many awesome people.
It also has the great benefit that I still get to take part in different conversations around Agile Software Development practices and especially when the focus is on testing.
The other day I was forwarded a little article by Mountain Goat Software which focused around the fact that in an agile team, at the end of the sprint everyone tests. And some developers may not like manual testing so they will do automation testing or pair with testers to find efficiencies.
“At the end of the sprint, everyone tests.”
I am wondering a few things around this line of text. Why does everyone only test at the end of the sprint?
I know there have been many discussions that “testing” means manual testing being done by a human. But I do think that developers are often using Test Driven Design to write code and hopefully are also running the code they write to test that it does what they intended and maybe also how it does not (depending on experience, mind set, time pressures and learned habits).
Nevertheless the above quote is important for agile teams. I have experienced that as testers you can easily become a bottleneck because the developers think their part is done. Ideally they will have written the code and written automation tests as well. Now the manual testers get to test the new feature works and hasn’t broken anything.
But this leads to the problem that the developers are sitting there twirling their thumbs or starting more work, adding it to the bottleneck until the pipeline completely collapses.
So I like the fact that there was an emphasis put out that everyone should test as the team is responsible for shipping the work altogether.
I do hope though that testers and developers in a team get to test early as well, or maybe even designers or product managers, to make sure that the feedback loops is as fast as possible. The statement has the danger to be interpreted as such that testing should only happen at the end of the iteration. (I don’t think that is actually what they are saying.)
The excerpt I read actually states that the better the agile team the later the testing can occur. This seems wrong to me, but maybe I am taking it out of context and it is referring to the time needed for the whole team to be testers.
“Establishing a mindset of we’re all testers at the end, does not mean that programmers need to execute manual test scripts, which is something they’ll probably hate.”
The article went out to say that developers may dislike using manual test scripts for testing and hence maybe could focus on other things such as automation scripts.
I actually thing that it will be really beneficial for developers to do manual testing, not necessarily follow test scripts but explore the features they wrote instead.
By all means make sure your code is well tested using automation tools but you will not know if you have written the right code if you do not manually test it. You will only know that the code is written in the right way.
Frustrations can make us creative
I recently watched a video that Chris recommended on How frustrations can make us creative and it highlighted how doing something you maybe don’t like can actually result in you finding ways to make it better a lot easier than doing stuff you enjoy all the time. So developers definitely can really gain from doing some manual testing. And not just developers but hopefully the whole team.
A sort of related example of this is, that at Songkick we try and learn about what each department does and were encouraged to help the support teams. This has actually led to improvements being made to the admin systems when developers used it to help solve support cases. It is OK here to JFDI, when an improvement can really help someone.
A small example was that someone added extra information to be pulled in on one screen, so that you do not need 2 tabs open anymore to find all the information you need to close a support case. This was a huge time saving for everyone and was only achieved because a developer used the tools he created for the support team.
So I encourage everyone to test, collaborate and try something that frustrates you and see if you can make it less frustrating to do.