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 www.IEEE.org and subscribe to their extensive glossary, and the Software Engineering Institute at Carnegie-Mellon (www.sei.cmu.edu)).
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:
Summary
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. |
