One of the key tenets of agile development is that testing is a shared responsibility. Everyone on the team is expected to figure out what to test and to test the product. In essence, the entire team co-owns all tests.

Yet some types of tests, namely functional tests, are difficult to co-own. Unlike unit tests which are both conceptualized and implemented by devs, functional tests are usually implemented by devs, but conceptualized by someone else (It could be product engineers, QA, BA, testers, or other roles. For the sake of sanity, I will refer to this group as QA). This dynamic forces a hand-off, which makes it difficult to truly co-own tests.

One way to deal with this issue is to require that all members of an agile team can both conceptualize and implement functional tests. In other words, make sure that every team member can code. While possible, this approach eliminates a whole group of QA professionals who are great at understanding what to test and finding bugs, but aren’t interested in writing code. This is not ideal.

A better way is for QA and dev to join forces and write tests together. This collaboration could work like the “test ping-pong” technique common in TDD pairing. Using this technique, one developer writes a failing test and his pair writes passing code. Wouldn’t it be great if there was a way to do something similar with a QA/Dev pairing?

Luckily, there are tools available which make this type of collaboration possible. I’ll focus on two: Test Manager and Twist.

The Contenders

Microsoft Test Manager

Microsoft released Test Manager as part of Visual Studio 2010. Test Manager lets you define test cases and organize them. Each test case is a collection of steps and steps can be shared (meaning that a step can be reused across different test cases). Steps can be automated using Coded UI Tests, which are written in C# and can run against a web browser.

Twist

Twist is a tool from ThoughtWorks Studios. It too lets you define test cases, organize your tests, and automate steps within a test case using Sahi or Selenium. You interact with Twist through a customized version of Eclipse and tests are automated in Java.

The Comparison

I realize that both of these tools do much more than just test creation, but I’m primarily interested in how they solve the collaboration problem. To understand that, we need to consider how easy each tool makes it to “Pass the baton” between QA and devs. At the risk of oversimplification, it should be easy to do something like this:

  1. QA writes a test and hands keyboard over to Dev
  2. Dev writes code to implement the test
  3. Both parties run the test and make sure that it passes
  4. Dev hands keyboard back to QA
  5. Rinse and Repeat

With the Microsoft solution, QAs are expected to work in one environment (Test Manager), while devs are in another (Visual Studio). This fact alone makes the collaboration I described above fairly involved and needlessly complicated:

In Visual Studio

Open Test Case Using Microsoft Visual Studio

In Test Manager

Associate Automation With Test Case

On the other hand, Twist allows both parties to co-exist in the same environment and handing off a written test for implementation is literally as simple as selecting it and pressing Ctrl+Click. Twist automatically creates (or re-uses) a Java container class with a function named the same as the test step:

The Bottom Line

At the risk of stating the obvious, only one of these tools makes it easy to collaborate and that tool is not Test Manager. To be honest, that’s quite disappointing because Test Manager integrates pretty well into the Microsoft development eco-system and it would’ve been nice to use it.

You may also like:

Did you love / hate / were unmoved by this post?
Then show your support / disgust / indifference by following me on Twitter!

Comments are closed.