First off, I should probably define what I mean by “Professional Testing” – in this case what I mean is software testing performed and managed by individuals whose full time job is software testing and who have been trained in effective testing techniques and tools.

In my mind the correct structure for Agile teams is to have professional testers embedded within the team who perform some of the testing themselves while also mentoring and teaching other team members (who are not professional testers) when these team members test.  These testers should work closely with the developers and other team members during sprints to ensure a common understanding of the requirements for the work with feedback immediately around the development and testing while also championing the continuous improvement of the quality processes within the team. 
(This structure becomes even more powerful when the team develops test scenarios collaboratively prior to the start of development so that these scenarios are reviewed by the team and the users.  Then these scenarios are broken down into test cases while the developers write the code so that it passes these test cases.  But this is not topic for this posting…)

Many teams find themselves in a situation where they do not have this perfect scenario.  In fact, there are numerous teams who don’t have professional testers at all.  It is common that these teams use business analysts, the product owner and/or developers to perform all levels of tests: unit testing, functional testing, system testing, regression testing, acceptance testing, integration testing, performance testing, etc…  Generally, in these situations, the individuals performing and managing the testing have not been trained at all on testing techniques, best practices, or testing tools. 

In this situation, the team and management usually understand the importance of professional testers and their value, but are unable to staff their team due to the lack of availability of professional testers within the organization or the lack of funds to obtain professional testers.  Therefore, the team and management start looking for ways to gain the benefit of professional testers in other ways.  It is during this search where off shoring some of the testing often comes up.  On the face of the suggestion, it looks promising.  The team can get support from the professional testers that they need but at a price tag which is palatable to the business’s budget.  Everyone wins, right?  Well, let’s see…

Testing is one of the crucial feedback layers within Agile.  Developers and testers must work very closely together to clearly define what is being built and the expectations of the result.  Developers and testers should hear the requests and requirements for work at the same time from the same people to provide consistency as well as an ability to check each other, promoting a clear understanding of what was requested.  Additionally, Agile testers must test from the perspective of the users who will utilize the system and this perspective and understanding is established and reinforced by high levels of collaboration and communication with the users.

If your testers are separated by thousands of miles and a multitude of time zones from your team as well as your users, the collaboration that is required is close to impossible.  Open communication between these groups will be attempted, but schedules will not overlap, conversations will be cut short because of the time of the day, and misunderstandings will abound due to limited real-time communication.  Clarifications around details or misunderstandings will now take a day to get since the testers can only send an email and then wait until the beginning of their next day to get the answer.  Soon reams of requirements documents will be produced and used to define what the testers should be testing.  Because of the need to produce the big documents, the analysts need more time to gather and document the detailed requirements.  Then, the testers need time to read through and understand these huge requirements documents.  In the meantime the developers have been involved in these requirements discussions with the users and have already been developing well before the testers get their understanding of the requirements (often even before they even get the documents).  In fact, what the team finds is that development is always done before the testers are ready to begin.  And when this development is done, will the developers sit idly and patiently await for the test results to them fix bugs, or will they move on to new development tasks, further complicating the problem?

So, let’s summarize: We now have an Agile team which has a requirements gathering and document writing phase that must precede the actual development and testing.  We also have development that is fully complete prior to starting testing.  Sounds a little like Niagra Falls, doesn’t it?  This team will get few benefits from other aspects of agile that it is able to implement- Agile is a holistic thing- the best benefits are realized when you do it all.  This may seem a little extreme, but it does happen on one level or another.

Can we just automate the regression with offshore testers?
You may be thinking “If we just want to automate regression testing, then this wouldn’t happen.”  But, consider this:  Your current “non-professional testers” probably do not have explicit regression test scripts that can converted to automated tests without some detailed discussions around requirements and original intent.  These discussions need to happen in the same way that the original requirements were collected, which will not be possible due to the time and distance issues.  Therefore, the tendency will be to do one of two things: (1) Create detailed requirements documents that the offshore testers can reference; (2) Work with the “non-professional testers” to add all of the detail that is needed in their current regression scripts.  In both cases your outcome is the same: replacement of communication and collaboration with reams of documentation.

Is there any other way?
So, what are the alternatives if there is not enough professional testing expertise to have testers on the teams?  Aren’t professional testers extremely valuable and basically a requirement on Agile teams? Yes, but in cases like this, you must look for a solution that will still support the Agile process that the team has adopted.  Therefore, my suggestion would be to identify at least one person who is on or could be put on the team and get them the training they need to start progressing toward becoming a professional tester.  Also, leverage the professional testers in the enterprise to mentor and support this person.  Soon, you will have a person on your team who will be mentoring the rest of the team around testing techniques, best practices, and testing tools and championing the continuous improvement of the quality processes.  All of this for what is very often much less money than what would have been spent on the offshore testers and more importantly a solution that does not have a strong tendency to completely eliminate all of the benefits that you are currently seeing from the adoption of Agile on the team.

Thoughts?