Agile Testing with Lisa Crispin

I’m doing a tutorial and a keynote at Agile Testing Days in Berlin. I think this is the first big agile testing conference to be held in Germany. Take a look at the program – it’s an awesome lineup of agilists. And since the most helpful part of conferences is always the informal connections you make, I’m happy to say that I know of a lot of interesting people planning to participate also.

Here are a couple of discount codes:

10% for the Tutorials: code SPEAKERSTUT010

20% for the conference: Code SPEAKERCON020

I hope to see you there!

If you’re in the Oslo area, don’t forget I am doing an Agile Testing course at Program Utvikling the following week.

There are a lot of creative, smart people on our team! Unfortunately I missed the discussion where these ideas come out, but we are trying some ways to organize such a big team. We will have “cells” or sub-teams, each one will take on a set of stories.

Today, each cell wrote high level acceptance tests together. Our cell started out doing BDD style tests on a FitNesse wiki. We used my desktop and the group in Weston VNC’d in and projected it on screen. But they couldn’t scroll up and down. And tests were taking too long to write. In our pomodoro retro, we decided to do high level test cases together as bullet points only, then have a pair flesh the tests out into BDD style and automate them.

We also decided to try Google docs. We kept using VNC and projecting the screen, but since the page is saved often, each person could also look at the doc on his own machine and scroll up and down. Both changes worked better. I had to split off for a long phone call with someone from an internal development team (that’s a whole ‘nother blog post), and when I came back they had finished the tests.

We are doing what I just learned is set-based engineering to decide whether we’d rather write our SWAT tests in C# and Visual Studio, or in FitNesse. We will do both this sprint and see which is better. My teammate Maykel started writing FitNesse fixtures that would allow using BDD tests to run SWAT from FitNesse, and I think he also had some way to make the tests run faster in FitNesse. One pair will automate the acceptance tests, while the other pair does a spike.

Thanks to the people who commented on yesterday’s post, I feel much better about having the testers get together occasionally. It’s true that we should have a testing community within our agile team, just as we have started one company-wide. I think we are on the right path with this team, despite it being larger than I would like.

I’ve worked on agile teams where programmers, testers, DBAs, sys admins and other roles all saw themselves as part of one developer team for so long, the idea of a separate test team gives me a chill. Yet even on experienced agile teams, there are still testers who see themselves as a “test team”.

I need to investigate more what they mean by this, I might be misinterpreting it. My new team is the combination of three teams, totalling 17 people (not counting the business folks). I think that’s unwieldy. Today, an experienced tester on my new team, who has worked on an agile team for some period of time (I’m not sure how long), proposed that the “test team” get together and discuss practices and strategy. I about blew a gasket, but that didn’t keep the meeting from happening (I’m always on phone and video with my team, so I can’t hep being in the meetings.)

The content of the meeting was reasonable enough. One topic was patterns of tests that we do, for example, for a numeric field you would always try certain test cases such as alpha and special characters, null, etc. Standard stuff.

The next topic was about automating tests on a page and end-to-end level, in addition to at the story level. This bugged me. If you tie tests to a page in the UI, and later stuff gets moved around so that what used to be on that one page is now on different pages, your tests will break. As far as automating end-to-end tests. we definitely have to be careful since the ROI can be bad on automating those.

My teammate Chris McMahon explained how our team up to now has been trying to group tests at the domain level. One FitNesse test contains all tests related to a rating scale, for example, until there are about 200 test steps and then we split it up into some reasonable sub-grouping. We’re testing at a feature level, no matter where we are in the UI.

The next topic was localization. Our app accommodates data in three languages. Someone proposed that we design our tests so that they could be run for any language. This sounds good to me, but how hard is it to do, and is it worth it? Is the localization already tested by the team that does the framework for it? I suggested we definitely needed programmer agreement for this topic, and everyone agreed.

I then brought up topics I’ve been wanting to raise, the non-functional testing. Our company has teams to do performance, scalability, reliability and security testing, but isn’t our team still responsible to make sure those happen in a timely manner? This discussion proved helpful for me, as I learned about the teams that do this testing, and how we can become involved and do a lot of it ourselves. I’m glad to get these activities out in the open and on our minds so they won’t be overlooked.

In the end I needn’t have been so spooked by the idea of testers meeting together. As it turned out, the programmers got into a design discussion with the database guy, and we were not involved in that (welll, I didn’t know about it until it was underway), so it was an opportunity for the testers to talk. But I don’t want that to happen too often.

I’m looking forward to starting work on stories. I think our test design will evolve as we write new code. We will pair on everything, so I hope that means the programmers and testers will remain engaged with each other.