Chapter 13

Common People Issues

13.1 PERCEPTIONS AND MISCONCEPTIONS ABOUT TESTING

In this section, we will look at some of the common “heard in the street” statements about the testing profession. These statements are sometimes made by testing professionals, by the management team, and by academicians. We will look at where these statements come from, the fallacy in the statements, and what can be given as arguments to counter these perceptions. It is important that these misconceptions and perceptions are cleared upfront to build a successful and motivated testing team.

13.1.1 “Testing is not Technically Challenging”

If you are conducting interviews to hire people for performing testing functions, you will generally observe a very bipolar behavior among the candidates. There will be the first set of people—usually a minority—who will approach testing with tremendous pride, commitment, and enjoyment. The second set—unfortunately, a majority—will be those who get into testing, “because they have no choice.” They often believe testing is not technically challenging. There are several contributors to this perception. One of the argument given is, “If I look at development functions, I can acquire proficiency in a given programming language and that is considered valuable. On the other hand, testing is simply a routine and repetitive job that does not require any special skills.”

This argument may have been true about twenty years ago when most of the testing was manual and the products were somewhat simplistic. In the scenario that prevails today, the testing stream bears a remarkable parallel to the development job functions, as summarized in Table 13.1 and discussed in detail below. (In the next section, we will look at the differences between testing and development functions that contribute to the perceptions and misconceptions discussed here.)

 

Table 13.1 Similarities in the testing and development functions.

Functions in development projects	Corresponding functions in testing projects	Similarities
Requirements specification	Test specification	Both require a thorough understanding of the domain; sometimes testing functions require an even more holistic understanding of the entire system from the users' perspective.
Design	Test design	Test design carries with it all the attributes of product design in terms of architecting the test system, considering reuse, formulating standards, and so on.
Development/coding	Test script development	Involves using the test development and test automation tools.
Testing	Making the tests operational	This would involve well-knit teamwork between the development and testing teams to ensure that the correct results are captured.
Maintenance	Test maintenance	Keeping the tests (regression tests, functional test, and so on) current with changes from maintenance.

Requires a holistic understanding of the entire product rather than just a single module    Typically, development engineers tend to focus on specific modules. It is possible for them to be somewhat oblivious about the functionality from other modules. Test engineers, in contrast, generally require a more holistic understanding of the product rather than be constrained to a single module or component. This gives an edge to test engineers at becoming domain specialists.

Requires thorough understanding of multiple domains    As the products become more complex and more open and seamlessly integrated with one another, testing requires a deep appreciation of the domains of multiple products. Just like developing a product, an in-depth understanding of the nuances of the domain of application is required for testing as well. In fact, extending the argument presented in the previous paragraph, while most development happens in a compartmentalized manner, testing may even require a much deeper understanding of the interactions and inter-dependencies amongst multiple domains to be able to simulate real-life scenarios. Thus, testing seems to be even more suited to and challenging for someone who has expertise in product domains.

Specialization in languages    Most developers stake their claim at expertise by gaining proficiency in some specific programming language(s) or platform(s). In the early 1990s, most people sought to be experts in C, which moved to C++ and then to Java. Similarly, in terms of platforms, the preferred platforms shifted from mainframes to client-server computing to network-centric computing. Until about ten years ago, people in the testing functions found very little parallel to these kinds of “resume enriching” language skills. Most testing was either manual or used some home-grown tools. The advent of specialized testing languages and tools over the past few years has narrowed this gap about language expertise in testing. Today, the argument that “in testing we don't have any programming” holds no water. In fact, the use of most testing tools requires programming in languages remarkably similar to those that developers use.

Use of tools    People in other activities of a software life cycle had access to a wide variety of tools like CASE tools, debuggers, IDEs, and so on. Tools added more “glamor” to their jobs and were “cool” to use. Testing functions offered very little opportunity for using tools. Again, things have changed significantly on this front over the last few years. The standard testing tools available in the market not only support languages that are akin to programming languages, but also provide opportunities for better design and integration with the program code of the product being tested. Given the complexity of tools, sometimes, automating the tests can prove to be more challenging than even developing the code for the product!

Opportunities for conceptualization and out-of-the-box thinking    Since testing is viewed as a “destructive” job, there is a perception that there are more opportunities for conceptualization in development functions than in testing functions. As we saw earlier, the process of testing bears a strong parallel with the process of development. Even though testing is considered destructive (in the sense of finding defects in a product), these similarities are enough proof that there are ample opportunities for conceptualization and out-of-the-box thinking. Unfortunately, these similarities most often get completely overlooked by people in seeking a career in testing.

Significant investments are made in testing today—sometimes a lot more than in development    For instance, testing tools are very expensive and obviously, an organization would have to ensure that there is sufficient return on investments on these expensive tools. Hence, it is eminently possible that some of the best talent gets channeled to testing functions.

 

An internal test tool today could very well be one of those expensive test automation tools of tomorrow!    In many organizations, what starts off as an internal tool within a small group expands to be a sizable product, with ramifications and applicability across multiple groups and from there to even becoming a revenue-earning test automation product. This possibility increases the need for a still wider view of the testing functions, from a technical challenge perspective.

In view of all of the above, testing offers sufficient technical challenges for an interested professional to continuously learn, enrich his or her knowledge, and achieve greater heights of personal satisfaction as well as product quality and fulfillment.

We would like to summarize our discussions on the development—testing dichotomy by saying, “there is testing in all development and development in all testing”.

13.1.2 “Testing Does Not Provide Me a Career Path or Growth”

A number of organizations have career paths defined for people in the development and other software engineering functions but when it comes to testing functions, the career paths are not clearly laid out. In fact, even the job titles are given as “Development Engineer,” “Senior Development Engineer,” and so on! From a project life cycle point of view, developers seem to have a natural progression into being a designer, a business analyst, and a domain expert. There is also scope for being a respected “architect.” Testing organizations do not always present such obvious opportunities for career growth. This does not mean that there are no career paths for testing professionals. Since we strongly believe that there is an equally lucrative career path for testing professionals, we will revisit this statement and devote the entire next section fully to address the career path choices for testing professionals.

 

13.1.3 “I Am Put in Testing—What is Wrong With Me?!”

Since testing is an activity that is closest to releasing the product to customers, it stands to reason that some of the best talent in an organization be deployed to the testing functions and that these functions should be treated on par with other functions. But the (false) “gleam” associated with other job functions sometimes cause not-so-obvious slips in the message conveyed to the team. People are sometimes made to feel that they are in testing because they could not fit in anywhere else! Consider some of the causes and effects of such messages

1. Filling up positions for testing should not be treated as a second string function. If the hiring and allocation policy is such that all the “toppers” in a class (or the candidates from top schools) are allocated to development functions and testing functions get the “leftovers,” then obviously the management is sending the wrong signals and reinforcing the wrong message.
2. A person should be assigned to testing only when he or she has the right aptitude and attitude for testing. They should see a career path in testing, as much as developers look for a career path in development.
3. The compensation schemes should not discriminate against any specific function, notably the testing function. When the compensation and reward mechanisms favor the development functions, employees are bound to view the testing function as a means to “graduate to development” rather than look for careers in testing itself.
4. Appropriate recognition should be given to the engineers who participate in activities such as testing, maintenance, and documentation. Recognition is not just in terms of monetary awards or compensation but in the form of visibility. For example, when a product is launched and is successful, how often do we see a “test architect” steal the center stage vis-a-vis the development manager? These invisible job functions sometimes get viewed as “thankless jobs” and hence people want to move out of these functions.

The fact of the matter is that the common sense that is so obvious in all the above arguments is so often missed out because of the baggage of perceptions associated with the nature of testing functions. This erodes team work within the organization and eventually tells on the quality of the product.

13.1.4 “These Folks Are My Adversaries”

Since the main function of testing is to find defects in the products, it is easy for an adversary attitude to develop between the testing team and the development team. The development team start viewing the testing team as people who nitpick their work, while testing teams begin viewing the development teams as giving them products that are not ready for prime time.

 

13.1.5 “Testing is What I Can Do in the End if I Get Time”

Even though there are different phases of testing that are interspersed throughout the project, testing is still construed as an “end of life cycle” activity. When deadlines are considered sacrosanct, and when it is considered “natural” for developers to take “slightly longer” than what was planned to get the product ready from development, it is the testing team that often takes the brunt of the deadline pressure. The time allocated to testing gets cut and testers often have to put in long hours spanning weekends to meet the deadlines, while ensuring that the product is tested “adequately.” After all, when customers report problems, the first question asked is “Why wasn't this defect caught in testing?!”

 

This double whammy of having to squeeze in a lot of work in high pressure mode (almost incessantly, given the shrinking lifetimes of products) and facing the brunt of attack for product defects has a significantly negative impact on the morale and perceptions of people aspiring to perform testing functions. Some ways of overcoming this problem are

1. Stipulating completion/acceptance criteria for a testing team to accept a product from the development team. For example, an organization may specify some minimum conditions for a product to be considered ready for testing.
2. Giving the testing team the freedom to mandate a minimum quality in the product before it can be released. For example, an organization can have norms which specify the limits on the number and severity of open problems before the product can be released.

13.1.6 “There is No Sense of Ownership in Testing”

When we talk of team structures for product development, we often see roles like “module leader.” These are often people who have ownership of the module that is being developed. Even in the maintenance phase, there is ownership at module level or component level. This ownership creates a pride that drives individuals to ensure better quality.

 

This ownership is sometimes not created for testing functions. A possible contributor to this feeling of lack of ownership is the apparent lack of “deliverables” for testing functions. Development functions produce code and the developers feel that this “touchy feely” code is their creation. This creates a sense of ownership. On the other hand, testers may feel that they only make the code better—or worse! They do not associate themselves with any concrete deliverables. No doubt the testing professional owns the test scripts, test design, and so on but the lack of direct customer exposure of these artifacts does put a damper on the mindset of the testing professionals.

One way to minimize the impact of this problem is to vest the testing team with the authority to decide the state of readiness of the product and make them the final arbiters of quality. Secondly, some of the tests can end up as user acceptance tests or installation verification programs to be shipped with the product and hence the testers get to have some more deliverables in the product. Finally, today's products are pretty complex and require not just the binaries and executables to be shipped but also sample programs and applications. In fact, most product vendors have websites that have sample programs or applications that demonstrate the use of the various features of the product. A test engineer, with a holistic view of product usage, is best suited to write these sample applications. The introduction of these samples in a product release or a website increases the sense of seeing a visible deliverable for the testing process and hence increases ownership in the testing process.

13.1.7 “Testing is Only Destructive”

There is a perception is that test engineers are only working towards “breaking the software” or testing to prove “the product doesn't work.” This is not entirely true. This “pessimism” in testing (that is, wanting to find defects) is just one part of the testing job. The pessimism attached to testing should be viewed as professional pessimism or constructive pessimism. Such constructive pessimism together with balanced curiosity is required for constructive product development. The test engineers not only say “something doesn't work,” they also point out “what works” in the product. The job of testing is a combination of pointing out what works in the product, “breaking the software" and analyzing the risk of releasing the software with the defects, and providing a mitigation plan by striking a perfect balance across all these perspectives. The balance among these perspectives brings a positive mindset to the test engineer.

 

Just because the test engineer brings the “bad news” on the product (of things not working), it does not mean the profession is bad or testing is destructive. The very same test engineer can provide the workaround to get over the defect, when the same or similar defects get reported by the customer, saving the company money and image. Knowing a problem is half solving the problem. By reporting a problem in a positive way with adequate data, the test engineers provide a method to solve the problem, without which the problems are difficult to solve on several occasions.

Thus, the job of test engineers is not only to find defects but also prevent defects by proactively reviewing the specifications, design, architecture, and code from the testing angle. Defects can be prevented by providing the test cases in advance to developers so that the code can incorporate all test conditions. This makes testing proactive, constructive, and saves effort in finding and fixing problems. The seemingly destructive nature of testing assumes a constructive dimension by virtue of this contribution towards proactive problem resolution.

13.2 COMPARISON BETWEEN TESTING AND DEVELOPMENT FUNCTIONS

The perceptions and misconceptions discussed above arise because of some significant differences between testing and development functions. Let us look at some of these differences now.

Testing is often a crunch time function    Even though there are different phases of testing and different types of testing that get distributed throughout software life cycle, the major thrust on testing usually comes close to product release time. This concentration of testing functions close to product release time throws in some unique planning and management challenges.

Generally more “elasticity” is allowed in projects in earlier phases    It is considered almost normal to expect that the development functions will take longer than planned! However, since the final deadline for a product release is seldom compromised, the same amount of elasticity and flexibility that is given for development activities are not usually given for testing activities. Thus, planning testing projects usually affords less flexibility than development projects.

Testing functions are arguably the most difficult ones to staff    For all the reasons we are discussing in this chapter, there is a much smaller number of people who take to testing as a career compared to other functions. This makes it difficult to attract and retain top talent for testing functions. However, since testing functions usually take place under time pressure, the uncertainty on the people dimension calls for more exhaustive contingency planning.

Testing functions usually carry more external dependencies than development functions    There are two factors that contribute to this. The first factor is that testing comes at the end of a project life cycle. Secondly, testing activities usually have a number of “show stopper” situations wherein the testing activities would come to a standstill until certain defects in the product get fixed. Once the product is retested after the defects are fixed, it may uncover more serious defects, thus increasing the external dependencies even further.

13.3 PROVIDING CAREER PATHS FOR TESTING PROFESSIONALS

We briefly discussed the myth that people believe about the lack of career opportunities in testing. As we saw earlier, there is a pronounced feeling of uncertainty about career paths in the minds of aspiring testing professionals. The objective of this section is to share some of our thoughts on what testing professionals can expect as a career and to re-emphasize that a career in testing could be as rewarding and satisfying as any other career for motivated and competent people. In this section, we present the career progressions that a testing professional may look forward to and the competencies he or she needs to acquire as he or she makes this progression.

When people look for a career path in testing (or for that matter in any chosen profession), some of the areas of progression they look for are

1. Technical challenge;
2. Learning opportunities;
3. Increasing responsibility and authority;
4. Increasing independence;
5. Ability to have a significant influence on an organization's success; and
6. Rewards and recognition.

To go higher up the value chain in each of the above dimensions, we have identified a framework comprising three stages through which an individual goes through.

The first stage is the follow stage. At the beginning of this stage, the trust and confidence level between the individual and the organization just starts to evolve. Most professionals, when they start their career with an organization (especially fresh from school), are simply given instructions to be followed. At this stage of their career, they have fairly detailed instructions on what tasks they have to do and how they should go about carrying out the defined tasks. This is required as both the individual and the organization try to get a feel of each other's strengths and evolve a method of working together. Thus at this stage, the work

1. Is fairly task oriented;
2. Comes with detailed instructions; and
3. Leaves little requirement for decision making.

A demonstration of capability in the assigned tasks at the follow stage leads to the individual getting recognized as trustworthy as well as enables the individual to learn the ropes of the tasks that he or she is executing. The individual is ready to move from just executing tasks by following instructions to formulating tasks, for himself or herself as well as for others. At this stage of the career, there is an increased focus on

1. Independent decision making;
2. Clarity in communication to assign work for others; and
3. Interacting with other groups.

When an individual reaches the formulating stage, he or she has demonstrated an ability to plan ahead as well as to delegate and monitor work. At this stage, the individual has created a competent next level to take on some of the functions he or she has been performing. This takes him or her to the next stage of playing an influencing role to mentor and nurture other individuals. At this influencing stage, the individual becomes a role model. Others in the organization feel comfortable approaching these role models for advice and guidance for the chosen tasks. At this stage, these role models are ready to assume additional responsibilities in other dimensions. When they assume these additional responsibilities, they may begin in the following stage for the new areas they are starting off, presumably under the tutelage of an existing role model in the new area.

Let us illustrate this progression for a typical test engineer from a functional point of view. A typical test engineer's career may begin by executing certain manual or automated tests. The job calls for diligently following the given instructions and completing the feedback loop as per the specified process. After some point of time, the test engineer may grow from executing tests to writing the tests scripts using an automated tool. This increases the technical challenge for the test engineer. He or she then moves to test design, which will involve better understanding of the product and the domain. This can in turn lead to formulating standards for designing and coding of tests, thus having a wider impact on testing. Finally, the engineer can reach the influencing stage, where he or she can take part in activities like evaluating test automation tools, interfacing with external product groups, and participating in upstream activities such as design to enhance the effectiveness of testing.

We have presented in Figure 13.1 one possible career progression for testing professionals that takes into account the three stages of growth. An individual starts his or her testing career as a test engineer. During this time, most of the role he or she plays is in the follow stage. In areas like categorizing defects, the test engineer is expected to get involved in formulation, being closest to reality. Table 13.2 above presents the various responsibilities that a test engineer would face.

 

 

 

A test engineer, upon gaining the necessary expertise and demonstrating ability and competence, moves to the role of a senior test engineer. At this level, the individual carries out the activities of a test engineer but with more independence and less supervision. Thus there is a progression to the formulate stage in a number of activities. In addition, there are a few new tasks added, wherein the individual begins to gain familiarity (by being in the follow stage).

The next stage of progression is a test lead, who essentially has module level responsibility for testing a module of a product. The test lead and the module development lead work hand in hand to make sure that the module meets the functions it is supposed to accomplish. A test lead's role involves a significant amount of influencing and getting the job done by other test engineers and senior test engineers. This role also entails an increase in communication requirements, both within the group as well as with other groups. The test lead becomes the anchor point for people performing downstream testing such as integration testing and system testing.

 

 

 

 

The test lead position presents a decision point for an individual. He or she has to choose between climbing the technical ladder or the management ladder. On the management ladder, the individual can don the role of a test manager or a department head. In this role, the responsibilities get focused on people issues and higher level strategy issues. Most of the functions are at the influencing and formulating levels. If an individual does not want to climb the management ladder but chooses to rise on the technical front, he or she can take up the option of being a test architect. This role essentially does not contain direct people management responsibilities but focuses more on aspects like providing overall technology direction, being a torchbearer of organizational values, helping in hiring and mentoring top talent in the organization, and playing an active role in the choice of tools for test automation.

These different roles have been found to be quite effective in fulfilling the aspirations of test engineers for a successful career. In order to carry out the required functions at various levels, a good combination of knowledge, skills, and attitude are required. Knowledge refers to knowing what to do in different situations. Skill refers to understanding how to do the required things. Attitude pertains to being motivated and wanting to do the right things. The ability to provide a career path for employees depends crucially on identifying the right combination of knowledge, skills and attitude. Table 13.6 summarizes the various attributes required at each of the job levels.

 

 

In addition to all the above, every team member, regardless of his or her level in the organization, should have some common traits. These traits include

1. Being a team player and understanding the importance of the success of the team as a whole rather than focusing only on individual interests. As discussed earlier, the success of the testing team depends on uncovering defects before the product is shipped out. This should not be viewed as a function inimical to development. The focus of the entire organization should be to release high-quality products in a timely manner and the testing team members should also keep this overarching goal in mind.
2. Taking initiative. As in most other professions, successful people are those who take initiative, volunteer, experiment, and share their learning with others. Testing profession is no exception to this.
3. Being a continuous learner. With the technology landscape changing rapidly, it is essential that an individual be able to quickly adapt to new technologies, processes, and tools.
4. Being able to react quickly to changes without giving up on proactive planning. Testing will require a lot of flexibility on the part of the team members, especially because it is a downstream activity. They have to be able to respond quickly to changing priorities, delayed handover from development, and flux of employees. At the same time, they should anticipate such contingencies as early as possible, so that they are better prepared to meet the changes.

From the above discussion, it is obvious that fears about the non-viability of testing careers are completely misplaced. There is enough challenge, enough rewards, and enough career opportunities for an aspiring and competent professional to scale great heights in testing.

13.4 THE ROLE OF THE ECOSYSTEM AND A CALL FOR ACTION

The perceptions, misconceptions, and issues discussed so far cannot all be corrected by each and every organization individually. There are collective and much higher-level actions that need to be done. These actions pertain to the entire ecosystem covering the education system, senior management, and the community as a whole. We will look at some of these issues in this section and present a call for action that is required from each of these constituents.

13.4.1 Role of Education System

The education system does not place sufficient emphasis on testing. Consider some of these facts about what prevails in most universities.

• There are formal core courses on programming but only a few universities offer core courses on software testing; most do not have a formal full course on testing and even if they do, it is at best a sparsely populated elective course.
• There are “lab courses” for various development tools but none or very few for common testing tools.
• Even during courses like Operating Systems and Databases, the emphasis on exercises and practical work is only on the programming aspects, not on appropriately testing the built product. As a result, students end up with a lopsided view that the work of producing an operating system or database ends when coding is completed!
• Most “projects” done as a part of the curriculum (for one full semester) never ask for test plans nor look at testing effectiveness. Almost the complete weightage is on coding. Since students work towards where the rewards are, there is almost complete neglect of testing functions. This sets in as a habit that has to be “unlearned” when they start their careers.
• Most courses and projects reward individual performance and present very little opportunity for team work, which is so essential for the success of development and test engineers. More importantly, communication and soft skills, which are absolute table stakes for a test engineer, are neither emphasized nor formally taught.
• Real-life scenarios like constant churn of changes and the impact of such changes on the quality of the product and the demands placed on testing and quality assurance methods are seldom emphasized. This reduces the student's ability to react quickly to changes.

 

 

Some of the things that need to be done to improve the awareness of importance of testing and to inculcate the right knowledge, skills, and attitude towards testing with a sense of urgency are

• Making a course on software testing mandatory for all students of computer science, software engineering, and information technology;
• Giving extra attention to communication and soft skills during degree programs;
• Requiring every practical assignment in every course to focus not just on the programming aspects but also on testing the developed product in a systematic manner; and
• Setting aside a certain percentage of marks for project work for developing test plans and presenting appropriate metrics for testing.

Overall, the academic community has to instill the right value systems to appreciate the importance and value of the testing functions. This calls for some attitudinal changes in the academia as well as leading by example by changing the evaluation criteria appropriately.

13.4.2 Role of Senior Management

The senior management of organizations plays a vital role in the development of test professionals. It is simply not enough to use words like “quality is our top concern” or “people are our top priority.” This commitment has to be translated into visible action. Some of the concrete steps they can take to achieve this are as follows.

1. Ensuring a fair distribution of appropriately talented people in the testing arena. For example, by allocating some of the best hires from the “Ivy League” schools for testing functions, the senior management sends a strong signal about its commitment to quality and recognition of the importance of testing functions.
2. Not allowing development engineers to look down upon test engineers. They are—and should be treated—as peers, equal stakeholders, and contributors in the success of a product.
3. Encouraging and consciously ensuring that there is active job rotation among development, testing, and support functions. Such job rotation will increase the cohesion in the organization and minimize the chances of testers being “looked down upon.”
4. Demonstrating equity in recognition and reward schemes to the top performers in all the functions, including testing.
5. Nurturing talent in test professionals by providing them opportunities to further their knowledge and skills. This can be accomplished by encouraging participation in community activities such as conferences and by rewarding people who go in for the various certification programs. This should result in the creation of role models for testing, who are highly visible in the organization and thus motivate more people to take testing as a career.

 

 

We will summarize the role of the senior management in fostering testing professionals by adapting a quote from Agatha Christie's Witness for Prosecution given in the shaded box at the beginning of the section.

13.4.3 Role of the Community

Regardless of whatever the senior management or academia do, the success of the testing community starts from within. There are a few things that the members of the testing community—the testing professionals — should do in order to showcase and promote the testing profession.

 

 

Testers should start with a sense of pride in their job and the realization of their role in a more holistic way, in the bigger picture of the entire product. It is often this lack of internal pride that acts as the biggest bottleneck. This creates an apparent sense of lack of parity with developers and develops into a self-fulfilling prophecy.

The pride in work is best illustrated by an oft-told story given in an inset on the next page.

Testers should themselves see a career in testing rather than view testing as a stopgap arrangement or a means to get into development functions. Hopefully, the career paths outlined in the previous section will motivate people to take up testing as a career.

 

Test engineers need not be just followers of technology—they can take an active part in shaping and using new technology. There is a misconception that new technology is difficult to understand for test engineers, and that only “developers” are better equipped to understand it. Sometimes, test engineers are under pressure to learn the technology and test the product at the same time. Learning the product and testing it at the same time may lead to ineffective testing. This scenario must change. A positive scenario would be one in which test engineers understand new technology areas proactively before they are implemented in a product. This can be achieved by being part of the product development team and contributing to ensure that the technology is correctly adopted in the product so as to benefit the customers. Proactive involvement of test engineers in understanding new technology can bring in better user perspective that can enhance the market potential of a product.

One of the reasons why there is a strong fraternity of professionals in development and other software engineering arenas is the existence of communities and forums for sharing experiences and furthering knowledge. There are a number of conferences and symposia that cater to various aspects of development. In contrast, the number of forums devoted purely to testing is very limited. The good news is that this has been changing rapidly over the past few years. It is important to keep up the momentum to create sustained forums for the testing profession. Some of the activities that could be taken up include

• Creation of industry-academia collaboration in recognizing champions and spreading the message of the importance of testing;
• Institution of awards for stellar contributions to the testing profession; and
• Organizing events focused on testing.

A synergy amongst the various stakeholders of the ecosystem described above enhances the chances of spotting aspiring test professionals early, furthering their knowledge, skills, and attitude so that they fit better into the industry. They can then continue to grow in the testing profession and understand the business value of the testing profession and appreciate where they fit in the overall scheme of things.

The topic of people issues are not discussed at great length in the literature. When it comes to issues facing geographically distributed teams, the material available is even lesser. One of the popular books that focuses on people issues across the board in software engineering is [DEMA-87]. [SRINI-2003] provides insights into the issues involved in building effective test organizations. [RAME-2002] covers the important aspects of managing global software projects and the various organization structures possible for testing as well as other types of projects. [IEEE-2001] was a special issue on global product development. Although the issue does not have any article directly related to testing, the issues pertaining to teams that are geographically distributed discussed here are widely applicable to testing as well. [BURN-2004] discusses the issues of building a test organization on various dimensions of skill development, providing a career path, etc.

1. What arguments would you give to a person who says that the testing job is not challenging?
2. Through the text, we have been talking of only two job functions and have labeled them—"development" and “testing.” Consider the other job functions like support and maintenance.
   1. Compare the career paths and progressions in testing to those in these job functions.
   2. Compare the nature of these new job functions with testing and identify similarities and differences.
3. Discuss how a job rotation among all the job functions—development, maintenance, testing, and support can be rewarding for the employees and worthwhile for the organization.
4. Which of the following statements by senior management would you agree with? Justify your answer
   1. “I will give you a Java development job if you do the testing function for six months.”
   2. “Our hiring policy will be to hire under graduate students (freshers) for testing functions; Freshers are not allowed for development functions.”
   3. “Every developer will have to rotate to testing and support functions for three months.”
   4. “The bonus allocation percentage should be the same for top performers in all the job functions.”
5. How will you respond to the following statements by test engineers?
   1. “Both he and I are from the same college and I have got higher grades than him—why is it that he has been given development function whereas I have been put in testing?”
   2. “My performance in the testing role is poor because I told you I am not interested in testing … put me in development and see the change in my performance.”
   3. “I enjoy testing, show me what new things I can learn in testing.”
   4. “I have taken up testing—shouldn't I get a higher compensation?”
6. You are having a set of test engineers from whom you have identified a few who can advance to the level of senior test engineers. List the kind of training programs you will put them to.
7. When a person wants to move laterally from the position of a test architect to that of a test manager,
   1. What challenges should he or she expect?
   2. What training programs will he/she have to undergo?
   3. What changes would the person have to make internally to be successful in the new role?
8. One of the tasks in the management ladder was “driving quality at the product or organizational level." Elaborate on this and break this down into more detailed activities.