Embedded testers

You may remember a few month ago that I wrote a post about agile software development. One important part of the agile process is being able to get the software tested in a timely fashion. Typical software development strategies say that you deliver the finished product to the tester at the end of the development process; this has several floors:

1) When the product is handed over its the first time that the testers have seen it. Most testing teams think of themselves as customers, meaning that they will be looking at the product with a critical eye. They will pick fault with everything; this is a good thing as it allows us to create a better product.

2) When the test cycle ends the development team may have a large collection of bugs that need to be addressed

3) When the test cycle ends the development team has moved on to something else and the memory of the inner workings of the product have faded.

Points 2 and 3 are very important especially to management. One way to address this in an agile environment is to embed either one or two testers into the agile team.
What does this give us:

1) The testers can see what the developers are up to during the design phase
2) The testers can provide input during the design phase about things that they would test in certain scenarios
3) The developers gain an insight into the things that the tester will be looking for
4) When UI is being considered the testers can give input regarding usage and how they would test it
5) Data validation can be fleshed out with the testers giving valuable input regarding edge cases that they may try
6) The management can see development and test working together to a common goal

The fact that the testers can provide input into the development process is a big win as they will be able to contribute more and more in each scrum iteration.

The goal of each scrum is to try and deliver working software at the end of each iteration. Having an embedded tester means that you can start to provide them with very early alpha releases of the stories that are being delivered.

They can test and advise you of changes in an ad-hoc fashion, they can build up a series of tests that they will perform on the final release code and all the time they can keep the development team informed about what tests they are planning to perform on the code.

This has the effect of making the development team more aware of any potential issues in the code which should lead to fewer bugs being reported at the end of the iteration.

The continuous feedback from the ‘smoke testing’ can feed into the unit tests that the development team create to test the logic of the code being written. The acceptance tests can also be included into the unit tests so that you know that the final acceptance tests will be covered.

When the general testing is complete the only thing that may cause your software to fail is destructive testing where they aggressively test the product in a way designed to cause it to fail with the aim of seeing how the code reacts and what exceptions are created. This can also impact the user experience in a negative way if the product falls flat with huge exceptions / crashes etc…

As a developer, how can you build a good relationship with your testers? Its not as hard, some testers are technically minded, some aren’t. The important thing to remember is that you need to exchange knowledge, as long as both of you are exchanging the knowledge and understanding what it means in the scope of the project life-cycle you can work more effectively as a team.

You may find that the information that the testers are providing to you are either too light on detail, in this situation Its worth spending a little time showing the testers how to effectively collect information for you to use, this could be using 3rd party tools to get information / data. An experienced tester will know quite a few tricks and techniques that they can use to get you information that adds value to the bug report.

Some tools & utilities that I commonly use are:-
– Fiddler Http Debugger Proxy (http://www.Fiddler2.com)
– Log4Net (http://logging.apache.org/log4net/)
– WireShark
– Windows Event Log
– PSR (Problem Step Recorder – build into the Windows OS)

Fiddler is a very effective tool as it allows you to see traffic between and application and a remote resource such as a web service. We find that in conjunction with Log4Net it is possible to get a very good idea of what is occurring in the application during each web request.

PSR is a great tool for capturing a users actual movements, key presses and mouse clicks, it saves the data as an .mht file which you can open in an browser window. It captures the screens and embeds them into the .mht file.

Remember, there is no I in team, communication is key.