Continuous Training for Test Teams

In this article, I share some of my experiences and observations on training teams, mainly in corporate settings. The operative word here is “team”, not “individual”. When training teams or groups in an organization, many of the considerations and benefits are different than those for the individual. We’ll examine those differences and I will share successful solutions.

One must recognize that the needs of knowledge workers are different than those of traditional workers. Management guru Peter Drucker first used the phrase knowledge worker to describe “one who works primarily with information, or one who develops and uses knowledge in the workplace”. To suggest how one might attain greater job satisfaction and better work effectiveness, Drucker lists four essential conditions: challenge, belief in a mission, results, and continuous training.

On that last point, Drucker isn’t alone. The best modern management and leadership models emphasize the importance of continuous training. But is that indeed what is taking place in most professional workplaces today?

Continuous Training

Continuous training sounds big, and it is. Indeed, it can take many forms. It can come from a variety of sources – a test lead, a scrum master, an internal or outside trainer, a book, a video. It could be – among many things – technical, communication, process or tool training. As such, I’ll only focus on delivery of hard and/or soft testing skills, leading and team content, and exclude tool and HR training (such as workplace safety, sexual harassment, diversity, etc.), since their goals and delivery are different from those of software testing content.

Thomas Davenport, professor of information technology and management at Babson College in Wellesley, Massachusetts, famously coined the term HSPALTA: Hire smart people and leave them alone. This indeed seems to be the common wisdom by which most knowledge workers are managed today. Hiring the “best and the brightest” is often critical to the success of an organization or project.

But leave them alone? Everyone needs training – even smart people! A laissez faire, “hands-off” mindset can quickly become a barrier to innovation and optimization. Yes, companies may indeed pull out all the stops to recruit and retain the most intelligent, skilled employees. But in our business, teams regularly make demands to do more with less, to work more efficiently, test new technologies, work with new tools, automate more of our workload, work with outside vendors and offshore teams… and the list goes on. Leaving staff members alone to identify their own training needs and acquire the required knowledge or information is just not good management. Only through proper, regular, well-organized, coordinated training can teams gain the foundation and skills they need and stay current with the know-how required to accomplish the personal, team and project goals.

Everyone wants to feel confident in their jobs, acquire the skills to do the job correctly and efficiently, minimize stress, communicate their work and, if at all possible, enjoy doing it all! When you hire people – smart or otherwise – and “leave them alone”, you may very well be putting those goals further out of reach. Change happens at an overwhelming pace in our field. New devices are introduced, technologies evolve, development platforms change, tools are developed and quickly updated. Keeping up, even within a narrow slice of the tech world, is difficult and requires continuous training.

But how can a test engineer keep on top of the onslaught of new and ever changing information? The answer: continuous training! Sadly, though, I encounter so many teams who say they have no exposure to training, to new tools, and to new ideas, and are just too swamped with work to have the time to go searching on their own.

How can leads, managers, directors, and executives maintain confidence in the quality of testing when teams feel forced to engage in the same old practices month after month, year after year, because it’s the only thing they know?

Inadequate Training

In the wide field of software development, there is one problem that seems to be unique to software testing and quality assurance.

In the course of working in a large variety of companies, what I have found to be a frequent issue is that many test teams do not have a common vocabulary. Often, moreover, they do not fully understand established common practices, or how to communicate them. Education is a big factor here. For teams in other fields, the opportunities for training and education tend to be more readily available. Teams engaged in software engineering, marketing, and engineering project management are usually composed of members with university undergraduate or even advanced degrees in their respective fields. It is much less common, however, for testers to have gone through a program of study focused on software quality and testing. There are some programs available, but they are rare.

Measuring coverage, for example, is a favorite problem area for me. Some teams can give you a number representing “coverage”, but are hard pressed to tell you what it means, what it does not represent, what its limitations are, or alternative measures – or, for that matter, even if measuring testing is effective at all! Some testers can do a fine job of testing without understanding some quality basics or the reasons why we test. But without this knowledge, intelligently communicating risk, coverage, product stability, etc., to management is severely compromised.

Certification is not the answer for teams. Some people pursue certification only with the goal of getting a better job or making more money. Others get certified only because their companies pay for it. There are some major pluses to certification: one huge advantage of an entire team being certified is the idea of the whole team working from a common reference. And yet, I have never met a person who pursued a software testing certification for the purpose of gaining new skills; more often than not, the driving force was that piece of paper, and the potential job or salary benefits it promised.

Books can be a great source of information, ideas, and new approaches – mainly for the individual. Reading and circulating white papers to your group is certainly easy and beneficial.

But these solve skill problems for the individual – not for the team nor across the company. It takes a great deal of commitment and even “police work”, to have a team read a book and have “book club” discussions about how to apply the lessons read.

Online Training

Online training is theoretically a good solution. It can be done at the individual’s convenience, incurs no travel concerns, and online courses are usually cheaper than live delivery. Problems include: team discussions are not easy, participation is often problematic and retention is often low.

My involvement in online classes has not been positive. I have been involved in a few hybrid programs – hybrid programs being partial online delivery, partial live delivery of content. Three situations quickly come to mind. These same problems have been repeated by companies who have hastily decided that online is the way to go, without realizing the common drawbacks. In the first situation, most students had not done, or not completed, the online parts of the training before the live delivery. Those that had completed the work showed nowhere near adequate preparation or retention of the material needed to build upon in the classroom. In the second, the worst case example, only 2 out of 20 participants had actually completed the online training, which, not incidentally, had been quite expensive for the organization to develop. I am aware of too many organizations that have tried this – with the result being that only a small number of participants even “looked at” the online component. Retention was typically abysmal.

In the third case, another organization had “policing” in place to ensure that the online videos, flash content and reading were actually completed by participants. This hybrid program included homework and tests. Students were not at all happy about that. The overall impact on the team dynamic was a negative one and there were bad feelings all around. The result was that it became even more difficult for the organization to implement the training, tool and skill changes that were needed, due to the added complication of having to overcome ill will.

For all these efforts I have witnessed, none of the variety of online content delivery of test skill, tool and team soft skill training has been successful.

Other Sources of Training

Taking classes at a university or university continuing education program is great. Having designed and taught in these programs, I know that they have tremendous value. They can be useful to teams when employees are regularly sent through these classes. New employees are sent so that teams can work from a common reference, set of practices, foundation and glossary. This takes a great deal of commitment from management to stay vigilant in training. This may seem similar to certification, but it rarely involves as large a number of hours, high cost of certification and irrelevant courses, which often are of no benefit to one’s specific work.

An important part of training teams in a large corporate setting is the conversation that takes place with learning new skills, methods, and communication tools. I have found this to be key to real change and the application of knowledge. But note that a serious commitment to both attending and paying attention in class is required, in order that it may be followed up by productive face-to-face explanations and discussions of ideas, practices and methodologies.

Foundation of Practice and Common Practices

It is important to have people on a team work from a common knowledge base, where teams can trust each other when their systems are integrated. People come into testing from very diverse backgrounds, be they subject matter experts, programmers, technical support or help desk personnel, or people hired because of their unique language abilities. How can you convey to people with very different backgrounds the technical skill sets, the communication skills, and the language and vocabulary of the job? Some teams try mentoring – and this can indeed work. But it takes the right personality and commitment. And in crunch times, this can be difficult.

When there are no universally agreed upon definitions of commonly-used word in software testing – for example, regression, acceptance or smoke – communication of our work is compromised. Most people wouldn’t know what common or standard definitions are, or even where to find them. (You can go to and subscribe to their extensive glossary, and the Software Engineering Institute at Carnegie-Mellon (

Having good training across teams in the organization can get everyone on the same page with complete and effective bug reports, meaningful metrics and fluid communication. The vocabulary they use to describe coverage and risk have a very powerful impact on the management of software development projects. This results in better testing, understanding, risk analysis and a better product.

Other Unintended Benefits

There is also a team building aspect to training that I’ve seen bear fruit on many occasions. When team members share problems, some often glean solutions from others venting about similar situations. There are additional benefits in having people who test, but who do not normally meet each other, share information and knowledge about test cases, tool usage, new tools, and new uses for tools developed in-house for particular applications. These programs can also provide forums for discussing project politics, how best to manage difficult situations, system problems, system limitations, and possible solutions. Investment in team training also leads to better team retention.

Another unintended benefit to team training is that it brings about the discussion of “educating up”, since not everyone involved in software projects has a great understanding of why and how people test. I often hear: “This was fine – but my manager is the one who really needed to be here!”

Corporate Curricula

Developing corporate curricula has become increasingly popular, particularly with more software development work being distributed to various locations. Corporate curricula can ensure that each individual has a foundation of core competencies and essential skills (both hard and soft), uses a common vocabulary, uses test tools in the most effective way, understands development team goals or has a better awareness of users and their needs. Corporate curricula are most often a series of classes, each focusing on one topic developed for a specific need of the organization. They are not cookie-cutter, off-the-shelf classes. Chunks of content may be off-the-shelf, but they are combined in a way unique to your organization. I have been involved in developing and delivering a number of these programs and they have been very effective.

Corporate software testing curricula often includes – training across the suite of application lifecycle management (ALM) tools, quality basics, reporting, metrics and a common set of practices specific to the organization, delivered with the result being more confidence in the test effort across the company.

Brown Bag Lunches

Many teams do not share information across the organization. Also, you may be surprised at how little training actually takes place for test teams. I know many training coordinators who say training budgets are often not fully utilized. Taking the time to do training takes commitment and time away from one’s work. But there is at least one good alternative to missing entire days of work due to training: Brown bag lunches.

A brown bag lunch involves all participants bringing their lunches (the “brown bags”) into a meeting room for approximately 1 hour of training or discussion focused on one topic. Such sessions can be a great way to conduct team training in your office. Training can be on a regular basis, (most commonly, as the name implies during lunch). I have conducted many series of brown bag lunch training sessions for Silicon Valley companies in one-hour segments, typically over the course of five or six months. We’ve almost invariably had an incredible amount of discussion and gotten significant amounts of training done – all without pulling people away from their projects.

This was convenient since I am in Silicon Valley. Of course, not everyone has access to good, local, competent, software testing trainers. But it does not have to be an outside company doing the training. With a few dedicated people, responsibility for topics can be divided up, and content development time set aside. Good lunchtime discussions can result in some truly great training and, moreover, the development of in-house experts.

Cross-team Round Table

In large organizations, it is often a sad reality that groups who test rarely spend time with each other. Server test teams, security test teams, localization teams, performance testing teams, functionality testers, etc., rarely cross each other’s paths. And yet these teams very often face similar problems. Moreover, they generally use the same bug tracking, automation, test and project management tools, work under the same schedule constraints, and face the same political or communication problems. Test teams having round-table forums or discussions can be a great way to share information, increase tool usage, benefit from others’ expertise and problem solve across the organization. They can also be a valuable and unique form of training and cross-training.

Training Offshore Teams

Training offshore teams is absolutely crucial to successful distributed software development. Training is the main solution to virtually every problem people experience with offshore, outsourced and outsourced-offshore teams. From cross-cultural communication to tool training, the amount of training for offshore teams must be significantly greater than that of a home team. If for no other reason than the lack of easy knowledge transfer across local teams, this is problematic to remote teams.

Software professionals in Western Europe, Japan and the US have been testing software for a long time. Over the decades, communities of testers have grown up with various skill sets and with varying degrees of exposure to training courses, books, and software testing conferences. But in many countries outside these regions, the situation is drastically different.

The number of languages in which contemporary books about testing is published is quite limited. Having conferences and access to training courses even in some of the current low cost centers (LCCs) popular for development these days is rare and new.

This often leads to people hired into testing lacking skills, and having limited or no access to the right skills to effectively test. These people have technical training, often having received software development training, but are not skilled enough to be developers, so they are hired as testers with no training specific to testing. Without good knowledge of test case design, test data design and reporting, there is no way that an effective test effort can be executed.

The most common experience I have when I go to an LCC to train teams on software testing is to be confronted by a profound variety of backgrounds (more diverse than you find in American development organizations). The level of understanding of technology and of business communication skills varies greatly. In my experience, the investment in training for offshore teams is directly proportional to the odds of a project’s success. That is, teams that do not get trained adequately are significantly more likely to fail. Training offshore teams is such a broad topic that it’s difficult to talk about it in a brief way. Training in such subject matter as technology, tools, process, platforms, SDLC, and corporate culture are essential, not optional, and this list is really only the beginning of the list of topics that offshore teams should receive training in.

For a full discussion on Training Offshore Teams see:


What is most important when managing knowledge workers is not making the mistake to “hire smart people and leave them alone”. Peter Drucker identifies continuous training as one of the four essentials of managing knowledge workers. This continuous training can take many forms, but be careful to chose wisely. In multi-product companies or a setting where work is distributed among numerous project teams, classroom delivery of cross-team corporate curricula is very effective. Also, be sure to devote extra training effort to your offshore team.

Michael Hackett   Michael is a co-founder of LogiGear Corporation, and has over two decades of experience in software engineering in banking, securities, healthcare and consumer electronics. Michael is a Certified Scrum Master and has co-authored two books on software testing. Testing Applications on the Web: Test Planning for Mobile and Internet-Based Systems (Wiley, 2nd ed. 2003), and Global Software Test Automation (Happy About Publishing, 2006).
He is a founding member of the Board of Advisors at the University of California Berkeley Extension and has taught for the Certificate in Software Quality Engineering and Management at the University of California Santa Cruz Extension. As a member of IEEE, his training courses have brought Silicon Valley testing expertise to over 16 countries. Michael holds a Bachelor of Science in Engineering from Carnegie Mellon University.
Michael Hackett
Michael is a co-founder of LogiGear Corporation, and has over two decades of experience in software engineering in banking, securities, healthcare and consumer electronics. Michael is a Certified Scrum Master and has co-authored two books on software testing. Testing Applications on the Web: Test Planning for Mobile and Internet-Based Systems (Wiley, 2nd ed. 2003), and Global Software Test Automation (Happy About Publishing, 2006). He is a founding member of the Board of Advisors at the University of California Berkeley Extension and has taught for the Certificate in Software Quality Engineering and Management at the University of California Santa Cruz Extension. As a member of IEEE, his training courses have brought Silicon Valley testing expertise to over 16 countries. Michael holds a Bachelor of Science in Engineering from Carnegie Mellon University.

The Related Post

How to ensure a successful test-driven environment In order to ensure a higher quality product is released in the end, many teams have turned to test-driven development. Under this scenario, quality assurance metrics professionals first create various QA tests, and then software engineers code based on these tests, typically while using a robust enterprise test management ...
LogiGear Magazine – February 2013 – The Rapidly Changing Software Testing Landscape
The book is an incredibly effective and valuable guide that details the risks that arise when deploying cloud solutions. More importantly, it provides details on how to test cloud services, to ensure that the proposed cloud service will work as described. It is a great start to the topic. The 6 chapters detail a paradigm ...
DevOps has been described as Agile on Steroids; DevOps has also been described as Agile for Operations/IT. I like both of those descriptions. Many organizations want Development, Test, and Operations teams to move to DevOps now. DevOps is a big topic, but DevOps is not the focus of this article. We will not be talking ...
It is a fundamental role for testing teams to align their test design, test automation, and test case development with DevOps–not only to verify that code changes work but that the changes do not break the product. A key differentiator of DevOps is testing maturity. An organization can automate their integration, testing, delivery, and monitor, ...
How to Adopt the “Third Way” in the Dojo’s Method to Master CD In The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations the authors describe “The Three Ways” – the underlying principles forming the basis for all DevOps practices. 
Having the right skills and experience, even if you have to go outside, is essential for designing tests for large-scale cloud deployments. Moving existing applications to a cloud environment adds new dimensions to testing. One of the primary reasons for moving to the cloud is scalability. Capacity to handle traffic and data transfer can be ...
  LogiGear_Magazine_June 2016_Testing in the New World of DevOps  
Do you want to speed up your automated tests by a factor of 10 and deploy your application continuously? In this article we share how the JIRA development team at Atlassian has accomplished this using Stages in Bamboo. Stages have allowed the JIRA Development team to take a week’s worth of testing and condense it ...
LogiGear University announces the launch of a new, free video series on Testing in DevOps and Continuous Testing which is available today.
DevOps may be the next big buzzword, but Test teams really need to focus on its little sister, Continuous Delivery If you pay attention to trends in software development—from the perspective of what some sophisticated teams are doing, what articles and books are being written, to conference topics, you may have noticed the tools being ...
Run your TestArchitect API and headless browser tests inside Docker containers as easy as flipping a switch Docker is a virtualization platform enabling you to create containers – mini virtual machines— which have their own predefined environment, including file system, libraries and settings. Best of all, these light-weight images eat up only a few megabytes ...

Leave a Reply

Your email address will not be published.

Stay in the loop with the lastest
software testing news