Tuesday 10 December 2013

A pragmatic approach to a better manual testing

I recently had to deal with a small Functional Testing Team (two people in total) which was used to have a non-structured approach to manual testing, with several Word and Excel files used to track down the required information, absolutely no automation in place and a very personal way of dealing with issues reproduction and environments.

I thought that giving them all the Visual Studio ALM features was surely going to be overkill. Quite a greenfield situation, but combined with the requirement of retaining their habits and their knowhow as much as possible.

The first step is converting the sparse information they have as test cases into Test Cases in Team Foundation Server. It seems obvious, but it is not. You have to set up a descriptive standard, detailing steps and expected results, so that everything is coherent with the actual target but they feel comfortable with the new tool (MTM) and process.

It is also extremely important to standardize a bit the environments they work with. If they use their own local machines, set up a standard about not just toolings, but even how to reach them. If you do this, a newbie tester can be thrown in the mix and be able to start working in a near-zero time. Once they are aware that they can replicate their recordings and they can get even the videos, they will go nuts. But it is not enough…

The next logical step is either converting their action recordings into Coded UI tests or using Lab Management. There are valid reasons behind both:

Coded UI Tests

Lab Management

Validation Standardized environments
Extended behaviours Complex configurations
Integration with Visual Studio Commodity for the members

You could take both of course, but it depends on the resources you have. I went for the Lab Management route – as they are pure functional testers, so with very little code confidence - and they are happier and more productive than ever.

No comments:

Post a Comment