MenisMas' Blog

I've read several times in the last few months that there are companies removing Test or QA Teams in the organization. Something that was like a "seriously? It can't be as testing ensure the quality and quality is one of the most important thing if not the most in product development", but after a few months tuning the ALM I was involved I've started to understand what the comment "that company has removed QA" means. I have to say I didn't read more than comments about remove QA, I never red the reasons, probably because I didn't want to know as I thought on that as something unthinkable.

If we imagine the usual situation where there are teams developing the software and teams testing the software, some years ago those teams where located in different places even in the same office, but now companies are moving them together, QA team member next one or two or even three developers, keeping the communications faster and clearer which is one of the key of the QA - Development relationship.

6 months ago we started building our QA Team with our first member, sitting down next to Developers and understanding how company runs Development Lifecycle, and at some point our QA player started to write UI, Integration and Instrumentation tests, so he became to be part of Development Team but not developing code or fixing bugs, everything related to testing the code to be written or already written.

After few months running this experience we can say it has been great for both parties, developers and testers feel they are the same team and they are developing the same product, giving to that product the right quality. Now, we can say or understand QA Team Members are becoming part of the Development Team, removing the words QA Team, but behind the scenes QA is still present.

Let's say we are part of an Agile team, running sprints to develop a software product where developers, testers, product owners and scrum masters are collaborating to deliver new features or functionalities in each sprint. One the classic discussions are around testing within sprint or testing after the sprint, but let's have a quick look to both approaches.

Testing within the sprint could mean that developers write Unit Tests and Code as first thing in the sprint and deliver the new code to QA Team some days before the sprint ends to let run testing plan and see if new code is bugs free.

In the other hand, testing after Sprint ends could mean developers are focused in write the new functions and features while running the sprint and the code is released to QA Team once sprint ends, letting developers to run a new sprint.

My thought came to my mind when running running sprints following the first approach (testing within sprint) developers were always delivering new features to QA Team with a very tight time to run the testing plan. We made the decision to run testing plan at the beginning of the next sprint, which means developers would prepare a new release ready to test when Sprint ends and move to the next Sprint. This helped to let the Developers understand the release ready to test should be under proper testing (developer testing) as they are the owners of the work delivered, letting QA Team to be focused on ensuring the software works as the Product Owner defined.

With QA is not testing we say Developers proceed with the testing of the new code written, following TDD they test their code runs properly and put in the output the expectations for the given inputs. With this Development Testing in place, he QA Team will run testing plan rounds being focused in the functionalities, ensuring the quality of the product meet expectations.

Of course this is not a must, each team should find their path at any moment and look always to the results to see if they should tune their current process, an specific approach could work for a particular moment developing a particular product with particular team members, a change in the equation could produce a change in the approach followed, just keep looking yourself to keep moving to the great success.