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.
4 comments on “Whole Team Approach – difficult concept?”
Good luck with the new team! 17 does sound a bit big, hopefully you’ll end up being able to chunk it up a bit by feature – not discipline. I’m sure you’ll keep them all in line! 😉
I don’t think getting just the testers to talk periodically is necessarily a bad thing. At one company I had a team of 4 testers reporting to me. We were agile-ish with testers part of the product / project / release team along with the developers. But once a week we would meet for an hour to just geek out on testing. It wasn’t plotting against the people doing the coding, but to talk shop, trade techniques we had learned / invented / discovered.
I think I understand your concern for testers and developers starting to segregate from each other and identify more with the clique than the product you are building, but channeled properly it can be great for the people who self-identify as testers.
(Or this could make no sense at all and I misinterpreted the post as I’m just back from the first lacrosse game of the season and realizing how un-fit I am 🙂 )
-adam
At one of the agile mailing lists (agile-testing?) someone talked about Communities as a way of letting specialists exchange experiences.
So, even if you’re a cross-functional team, it’s probably beneficial for everyone whose primary function is ‘tester’ to get together and talk about testing techniques.
That’s not to say a developer with an interest in test automation, for example, shouldn’t be welcome, of course.
I’m curious about team organization this way — dividing teams by feature groups, but building communities/interest groups to advance the crafts is my favorite idea so far. Not sure how it would pan out in practice.
Thanks for a good post.
Thanks, y’all are right. I’m always a proponent of a company-wide testing community, but have been averse to anything that smells of a separate test or “QA” (man I hate that term) team. It will be interesting, as Kim suggests, to see how it pans out.