QA Team Conversion to XP?

This question you ask is one on which many traditional testers depend for career survival.

Short answer is maybe. You are right to identify the work flow as an issue, but the work flow is simple compared with training for programming and development. Making testers into programmers may be a bridge too far. There are many other skills that have closer affinity to your testers’ current skill set.

I think there is a role for Software Test Engineers, but two new creatures are on the scene, the Test Driven Developer and the Software Development Engineer in Test who will take over a lot of turf that used to belong to the STE.

XP Workflow

Under an XP workflow, unit test is the responsibility of the developer. Typically the workflow would involve creating the story card, working up a use case diagram and some use cases, then turning those into test cases. The test cases would drive the development in a methodology called Test Driven Development (TDD). Every minute the program exists, there is a test case to be implemented first, followed by some code that will initially fail, then after additional work, pass that test. When all the tests identified from the story cards pass, the product is done. Or at least the latest increment is done. Unit tests are created in a language dependent way and are part of the code. There are many references, but for a quick intro check Wikipedia, then the following web page by Scott Ambler.

http://www.agiledata.org/essays/tdd.html#WhatIsTDD

There is also significant overlap with the system acceptance testing because the test cases come from the story cards and use cases. ATDD (Acceptance TDD) makes a distinction, but I think it might be kind of arbitrary.

Not everyone takes testing with equal seriousness. Managers can push developers to not test. They can push to have testers not test too. I was dinged pretty hard one year when the developers on my team were about on budget but the testers on the project tested bug fixes and new features several hours a week even though the project plan had them only working two weeks at the end. It seemed like the right thing to do, and the project was still profitable and customers had a better product because of it.

Developers must test. It is very wasteful when they don’t because testers must run, report, and repeat. Software quality is no less the responsibility of developers than testers. This sharing should make the tester’s life less frustrating, but it also amps up the demand for a lot of knowledge and skill on everyone.

If developers fail to take testing seriously, the demands on testers may increase because you will get builds daily. For a while people may be heard to say, “why does it seem like we take one step forward and two steps backward.” The answer will be because you are now using a system where the team has visibility like it never had before and before it was only at the 90% mark that those people knew about the impending disaster.

The Shift of Testing To Developers

My experience is that to accelerate development, it can help to move jobs done by testers into development. This is true of everything from UI testing of a touch screen clear up through Windows Hardware Quality Lab testing of a very complex items like a Windows driver for WiFi.

Consider pre-PC days when engineers dictated memos and technical information to a secretary to be typed, duplicated, and distributed. Compare that to a developer using email, an intranet wiki, comments in the bug tracking, source control or code review tools, instant messaging, etc. We just have too many changes that we need to test and the surrounding communications and knowledge transfer are so daunting that much of our testing is automated for direct implementation by developers with no delegation to test.

Value Adds for Testers

I have worked with some testers who could be system engineers, and some who have crazy good communications skills (almost mind reading/telepathy). My most effective work with them was when they did a good job explaining unexpected behavior they saw in the system, usually in writing in the bug tracker, although often a demonstration was extremely helpful.

Another important criteria is that the effort of a code hand off was as small as possible. For a while developers felt some relief when testers could gen their own builds. Now, we use constant integration servers so developers need only commit source and provided we used TDD right, there are a lot of tests that run themselves and report back.

Global competition is pushing cycle times and rework is getting reworked out of the system. If tomorrow I hear from a tester about a defect I added today, how will I compete with the guy who didn’t make a defect today (or found it himself)? We are not there yet, but I think the days of cut-and-try programmers are numbered. I have seen demos from Google developers who may have rehearsed a lot, but they seem to be able to type in a program from beginning to end during a 90 minute lecture, explaining as they type with few or no problems in the change and execute cycle. Testers add value by shortening the time between work and rework, so early concise reporting about today’s build today is a big plus.

New Test Roles

Many organizations are carving out roles for SDET – Software Developer Engineer in Test. These guys script, code, and code review. The following link is to a blog for a SDET at Microsoft.

What does an SDET do?

He also describes Software Test Engineers (STE) who feed the bugs they find to SDET. Another thing that struck me about the SDET role is that unlike the traditional software developers, when they have buggy systems they need to know code for the whole system because almost any part could be the source of the problem, so the extensive mental map helps them track it down.

Forming a Vision that Leads to a Successful Transition

I have encountered a similar issue of a project manager not knowing how to fit that role into scrum. Being scrum master was her transition destination. It is a well defined role, and there is training for it. Keep looking and you may find something similar for testing.

There is more information about Agile testing here:

http://www.ambysoft.com/essays/agileTesting.html#AgileTestingStrategies

and about the independent test team here:

http://www.ambysoft.com/essays/agileTesting.html#IndependentTestTeam

Scott Ambler’s observations about the ratio of developers to testers in Agile vs. traditional approaches will not make your day (15:1 vs. 3:1). I would suggest understanding and creating a vision for your test team based on skills and tools expertise:

• Complete fluency with bug tracker.
• Understand developer level source control concepts like commit, branch, tag.
• Be able to run reports on code commits and their comments from the source control system.
• Learn to deciphering developer speak in commit comments and map then to UI and manual tests not run automatically.
• Get a system engineer’s understanding of the system, but help clarify rather than make decisions about what is undocumented and ambiguous.
• Get on a daily cycle with developers. This may mean much more frequent and rapid reconfiguration of equipment under test and test tools.
• Depending on your environment, developers may be using a much broader tool set than testers. If your lab has what they use, it is flattering and a more hospitable environment for face time and ad-hoc training from developers. Examples might include use of Virtual Machine Managers and VMs, remote debug or diagnostics via networks with SSH or remote desktop, the ability to save device state or UI appearance through screen capture or by taking a photo with a camera or smart phone, and logging to network directories or thumb drives.
• Preliminary analyses using log data moved into spread sheets and converted to plots. There is a lot of stuff being written about big data and sometimes the test output from in lab or beta test sites can be big data.
• Learn to facilitate customer interface during beta testing. This may involve retrieving log files by documenting and coaching customers over the phone, or it may be hooked into an automated system that delivers crash dumps directly to the developer (or to you if you have the skill to triage).
• Help support quantitative analysis of software and systems level products (as before, but maybe even more).
• Look for ways to get developers more aware of how many different testing methods and tools you have at your disposal, and what works well for requesting their work be quality assured, not just at the end of the project, but weekly or daily.
• Ask the developers in your organization what vision they have for how testers can help them. It should go well if you have been watching each others backs thus far. You should get great ideas together.

Good luck in the transition to XP and in preparing your team to do the same.

For typical test driven development, it’s probably not necessary for your QA’s to know any programming at all.

But if you’re doing behaviour driven development, it would be beneficial for your QA’s to know a language like Cucumber. Especially, if your business analysts are writing story requirements in the Given-When-Then style.

However, it really depends on your ‘people’, and the tools you’re working with. I would say it’s possible for them to be effective with zero programming knowledge, but it certainly wouldn’t hurt and may make them more effective.