Some Thoughts On Testers And Testing Teams

Recently I heard the dilemma of being a tester from a friend: “If you find many bugs and quality flaws , the developers hate you. If you don’t find them you are anyhow useless….”  There must be surely truth to it. It has been a known and old issue for many testing departments not to have the same visibility and recognition as developers within their organization and their projects.

Agile practices brought also many additional questions and challenges to software quality management field in the last years. There has been many discussions questioning the future of testers and QA departments.  It is mainly due to the blurring boundaries between old fashioned roles. The days of DBA, sysadmin, developer and tester siloes are gone, there are various success stories of companies that eliminated the matrix structures and clear scoping of the engineer tasks : “Facebook has no testers..”, “ XYZ Company is doing dev-ops and people have full access to everything”…

Yet the need for teams and individuals who are skilled to perform various complex tasks and willing to be accountable for the quality of the outcome is bigger than ever. Today’s successful teams consist of engineers who are continuously developing their technical mastery and are able to apply the systems thinking to their work at the same time.

So what do you need and do not need as an IT manager? The question is actually not whether you need tests or not. The question is also not whether there should be dedicated engineers who master in testing techniques. The main question should be whether you need a separate testing team or discipline within a certain environment. It is of course possible to produce high quality software without a testing team in many scenarios. However, in many other cases the optimal software development and ALM processes can only be implemented through a separate testing team. There is no one-size-fits-all solution.  Every company, every development organization needs to find its own unique setup for success.

How do you decide?  First of all, take a look at the behaviors and competencies of the engineers you have in the team. And decide which efficiency and what level of testing excellence is required for your product.  Good testers are quality specialists and offer unique advantages to the QA process. They work and think differently than the rest of the engineer team. They are trained to find and report problems.  Naturally, an experienced testing engineer would very likely to have the techniques, personality and experience to find, report and present bugs faster, better and more effective than most of the other development engineers. If you go for a solution with a testing team, you need to make sure that they are more than bug documenters or quality advisors. They need to have certain authority and decision making power over certain project execution situations, spring breakers and change management.  Here the key is that the testers and their lead understand the business priorities, defined quality metrics and the stakeholder needs in the whole system so that they can find the right balance of business needs and risks. Making the right call to fix or backlog a bug, escalating an emergency to halt a sprint, getting other decision makers’ buy-in in various critical situations are vital skills for testing professionals. So if you decide for a tester team, get good people on board, empower them and support them get the credibility and trust from their peers and cross-functional teams.

If your decision is go for a one-team approach without a testing team, make the quality metrics top priority for everybody and hold certain individuals accountable in the scrum teams. Ensure that the product owner is also held accountable for overall quality of the outcome. Train your engineers to know/understand how critical each error is and what types of errors should be avoided, develop strategies and integrate in to the development process. A developer is focused to do things right and get the code out whereas the testing-mode requires to look at the “bad” in the system in a systematical way,  to focus on to find out what is wrong and be determined to break the system.  It is a conflict for a developer to try to write solid, quality code and to fearlessly attempt to break and take things apart almost in a destructive way while testing. Give your teams opportunities to practice and reflect on different modes of working in a software project; improve the approach with their feedback after each sprint if necessary.

No matter what your decision is, best practices and agreed processes may help you to find your way to plan and get your software out with the desired quality. And you have to invest a lot of energy and priority in automation: do not end any meeting or project regarding testing without having talked about the status of test automation efforts. But at the end of the day, the main impact on the quality of the software does not originate from processes or methods. What matters by far the most is your people, the team, what capabilities they have and how they work together. The development and testing leads should motivate the engineers and get their commitment for quality by clear messaging about the importance of quality, impact of testing to the project and the company.  Track and recognize the engineers’ contributions within the community, make sure you have their support for the project and there is always someone to ask for help and to discuss about issues/problems.

Quality must be everybody’s business involved in the whole value chain starting from user request to the end of life of the software. And in many organizations there is a separate testing and QA team to drive and support the quality management discipline in a professional manner. But the bottom-line is that every team member, every manager and developer carries the responsibility of the quality of the product they ship, with all its success and other consequences. If this awareness and corresponding culture can be created, it would be much easier to get the support and creativity to find the processes and organizational setup that work for your teams.

Recommended reading :

Beatiful Testing, Does the existence of seperate QA Team damage quality?, end of the tester, Systems Thinking

%d bloggers like this: