Who Does Testing?

I just recently followed a tweet and read a blog post by Steven Baker (here) that discusses his frustration with the Dev vs QA scenarios that constantly come up in the development process.

Being an Agile/Lean proponent the whole concept of differentiating developers from QA makes no sense to me. My job as I see it to to build the product the user wants. Period. Obviously, if the product doesn't work as the Product Owner expects it to work I have not done my job.

This seems reasonable, doesn't it?

I can't imagine developing a product without putting unit, integration and acceptance tests in place. How do I know what I have created works and works as the customer wants without these tests? I get the stories from the business folks and create the tests to ensure that I have written the code to do what they want, no more no less.

Why should this be a QA job? I know what is to be built and since I am the one doing the coding it makes sense to me to make sure it does that when I am creating the code. For me to write some code and then throw it over a wall to someone else to test delays the feedback one whether it is really working. It is waste that should be eliminated as it becomes more expensive to fix once it gets that far.

While I realize that there is a special skill set required to do superb testing, having a delay in the flow of the testing just delays everything and adds to the time, cost and frustration when defects or misunderstood requirements occur.

I prefer to have an integrated team of developers and testers. There are folks who specialize in testing and folks who specialize in developing. Having them integrated on a team and working together cross-functionally during construction allows us to catch things sooner and also allows us to learn from each other and enhance both of our skill sets. We get better insight into each other's worlds and merge them.

The result is that I am better at my job and they are better at theirs. We also eliminate the artificial wall between us. There is a Yin/Yang relationship to coding and testing - one does not exist without the other and so we are two sides of the same coin.

Release Retrospectives

The Agile dev team/project I am currently engaged at recently released version one of the application. The application is a K-12+ knowledge portal for animal information. The portal itself is really interesting and I have had a lot of fun working on the project and I have also learned and honed a lot of my agile skills while here.

So anyway, we released the product into the wild and it is getting great reviews. It is pretty solid while employing lots of moving parts.

During the development we went through a typical Scrum style process - daily standups, poker planning,iteration planning, business verification (show n' tell). We also did weekly retrospectives for the previous iteration. It was a fairly boilerplate operation.

Once we released the product we had a release retrospective with the entire team - Product Owner, Dev Team, Content Team, and QA team. Just to be clear the whole team works together in an open agile space with pairing stations and the board, etc so we were in constant contact with each other for the whole lifecycle.

The release retrospective went better than I anticipated it would since I had met some resistance to points I had brought up in the past at iteration retros and I tend to be a rather blunt, no BS person. I don't like mincing words and that can get me in trouble at times but, well, that's just me.

So we executed the retro using the same basic formula that we used and I am sure everyone has some experience with. WE did the standard "What went well, What didn't go well, What can we do better" and then we determined which points to improve were the priority and who would lead those up for the next go round.

There were many good points brought up during the retrospective. The initial "What went well" section had valid successes such as good cross team communication, Product Owner availability, quick resolution to technical problems, etc. We ran into some nasty issues in piecing the app together and our team and especially the Tech Leads were very good about figuring out what was wrong and how to fix it.

The "What didn't go well" and "What can we do better" portions are more interesting to me as these are the ones that drive process improvement and lead to smoother development later. We covered a lot of ground with these and identified many things that were important to getting things to flow better. Things like paying better attention to skill buckets and avoiding knowledge silos were brought out. Trying to achieve something closer to push-button configuration for the pairing stations was another item given the problems we had with keeping workstations relatively synchronized was another point we wanted to address.

After we went through the process of discussing our good, bad and uglies we all then voted by placing checkmarks next to three items in each column that we as individuals thought were the biggest priorities going forward. We tallied the votes and chose the items with the most votes as the topics we planned to pay particular attention to in the next release.

The whole experience was a good, cathartic exercise for the group. We had the opportunity to address points that we all felt were important to discuss, we had the opportunity to voice our opinions about everything related to the release, the team and the process, and we were able to get it out of our systems in a healthy way that will hopefully assist us in continuous improvement for the next release.

If you aren't currently doing release retrospectives then I encourage your team to think about it. It doesn't take a long time to do it and it has the potential to remove roadblocks to future success. And it is empowering to the team to know that their input matters.