Agile Testing: Frustrations can make us creative

  

creative space design of a restaurant

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.

 

 

Advertisements

4 thoughts on “Agile Testing: Frustrations can make us creative

  1. I love learning about teams that take a whole-team approach!

    And in Mike Cohn’s defense – I worked for Mike Cohn back in 2003-4, he was our manager. When he says “test at the end of a sprint”, he means pre-release regression testing. On that team when I worked for him, we started out with NO automated tests, we didn’t even have a regression test checklist. I wrote up a manual checklist, and the last couple days of every sprint, we divided all that regression testing among ALL of the team. Everyone did manual regression testing. It was great motivation to get regression tests automated, and to start designing the code so that regression testing (or checking if you prefer) could be automated more easily.

    Testing on that team was a whole-team activity, we started every new feature by thinking about how we’d test it. We continually experimented with improvements so we could build better quality into our product. It’s great that more and more teams are finding this way of working fun and beneficial.

    Liked by 1 person

    1. Thanks for your comment, Lisa. It is good to have some background knowledge that at the end of the sprint equated to pre release regression testing. I have more recently been in the situation where the regression tests were automated and we did exploratory testing throughout our time box and I guess I forgot about those early situations where regression testing was a complete manual task.

      I love that you could start every bit of work with the thought of “how will this be tested”. In my new job we do consider it as well, but I find I need to think about this a little a bit and struggle with the abstract level sometimes.

      Convincing a team to do whole team approach to testing I think may be the hardest part. In my previous post I discussed how we did it with time boxed sessions and it was great fun and we found some really nice user facing issues. 🙂

      Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s