Dynamics of a QA Team
I recently had a discussion related to the size of a QA team and the separation of the different areas of QA into different independent groups. The conversation focused on why functional, performance and security testing has to be handled by separate and independent teams based on the dynamic of large organizations and the size of their QA teams (banks vs. smaller software shops).
In my opinion separate teams do not work. Why? Beyond reducing what is a strong team to little more than basic testers, it discounts the contributions, value and knowledge gain that each type of testing provides to each of the other types. What contributes to the success of the team is the information learned during the functionality testing phase provides value into the performance and security testing cycles. When teams are distinctly separate and there are siloed forms of testing, organizations strip their quality assurance team of its global perspective and the resulting overall product quality suffers. The understanding of how the application functions remains with those performing the functional testing and those executing the performance testing are left without that knowledge resulting in poor performance and security tests (social behaviors and demographics of users are ignored). In the cases where the types of testing are performed separately, only the functional testing is performed during development and often times performance and security testing will occur after a project is completed, and can result in significant refactoring, which costs time and money.
Answers (4)
I like your thoughts. Another benefit of not siloing testers is that there is always a backup resource if something happens to the primary tester.
I have worked on projects that are not overly complex and done everything myself and on projects that are so complex that it is not possible for a single person to cover everything. I have observed that these type of complex projects tend to get siloed more often, probably because they are too complex to efficiently divide work in ways other than the silos you mentioned. Which leads me to think that projects that are that complex eventually fail unless they are broken down into simpler managable projects. What do you think ?
In my opinion, QA teams should not be siloed for the reasons that you mentioned. In order to test performance and security, you have to know the functional behavior of the AUT. Cross-training different QA teams can be very difficult. And there is a big difference between delegating appropriate testing responsibilities to a QA Team and completely separating the teams in regards to location.
The same can go for outsourcing. Difficult to train outside groups, communication issues, etc. The benefit of outsourcing would just be having more hands on deck and you can possibly gain some experienced QA Engineers.
I'm answering your question from the perspective of the QA team dynamic. It's hard being the only real QA guy in the shop while managing a team of testers who are still learning. You end up spending time over sighting all aspects of the QA engagements with projects, playing at being the guru instead of growing gurus internally. Separating teams may appear beneficial in that it focuses a small team on one task, but in reality it quarantines the escalation of issues and generates the need for more management over sight rather than fostering self help and shared delivery responsibility. Silos are bad for growing local QA gurus, worse still they can lead to tester branding as an SME for a particular application. As a QA resource manager, the last thing I want to hear is a tester being requested by name for a new project. As test team effort ebbs and flows with the delivery schedule of projects, multitasking across projects also helps to even out utilization.
Wilton A.
Principal Research Scientist at Battelle Memorial Institute
Best Answers in: Personal Real Estate (2), Engineering (2), Mentoring (1), Staffing and Recruiting (1), Employment and Labor Law (1), Business Analytics (1), Supply Chain Management (1), Branding (1), Market Research and Definition (1), Product Design (1), Ethics (1), Biotech (1), Computers and Software (1), Using LinkedIn (1)
Terry, when I read your question, I found myself asking another one in response. When you say QA teams shouldn't be siloed, my response is: "Siloed from WHAT?" If your opinion is that different types of QA testing teams need not be overly "protected" from other types of QA testing teams, I would tend to agree. That is, white box testers need not be sequestered from functional (or requirements-based) testers and so on. If, however, you're talking about siloing the testers from the developers or the integrators, well, I would beg to differ.
Once the software deliverable leaves development, however, I'd think that everyone who tests it, be they individuals or teams, can and should freely interchange information and learning acquired in the testing process. I hope I didn't misunderstand your question.
