This paper covers the relationships between computer software developers and testers in the real world of a software life cycle. It stresses problems, solutions, and desired outcomes of human relations while dealing with artificial intelligence and creations of it. Examples provided show the real office experiences of the author and the behavior of different people during conflicts. The paper intends to focus on the fact that human relations problems covered and the solutions provided are perfectly do-able and feasible.
Q: How many QA testers does it take to change a light bulb?
A: QA testers don't change anything. They just report that it's dark
Software developers (programmers) are the people who bring computer software (programs) from latent stages to towards fully functional and operational products that can perform some operations. On the other hand, software testers function to ascertain that developed software does what it is supposed to do. Testers emerged from the ranks of developers at first, because at the roots of software development, programmers did their own testing of the code.
During the late 1960's software testing processes were ad hoc: developers tested their own codes. Later, this process was modified in the sense that programmers exchanged programs and reviewed each other's codes. In the early 1970's, Glenford Myers started to revise such techniques and the "science of quality assurance and control" was born. In 1976 Myers published his first book and in 1979 his fifth, The Art of Software Testing. Many people believe that The Art of Software Testing was the first good work ever written on software testing, and Myers became the father of the software quality assurance discipline.
Software Quality Assurance involves the entire software development process–monitoring and improving the process, making sure that any agreed-upon standards and procedures are followed, and ensuring that problems are found and dealt with. It is oriented to prevention. Testing involves the operation of a system or application under controlled conditions and the evaluation of the results, i.e. "if the user is in interface A of the application while using hardware B, and does C, then D should happen". The controlled conditions should include both normal and abnormal conditions. Testing should intentionally attempt to make things go wrong to determine if things happen when they shouldn't or things don't happen when they should. It is also oriented to detection.
Organizations vary considerably in how they assign responsibility for QA and testing. Sometimes they're the combined responsibility of one group or individual. Also common are project teams that include a mix of testers and developers who work together, with overall QA processes monitored by project managers. But, usually, QA lead is established. Everyone realizes that testers are essential participants in the software life cycle, but personal issues between developers and QA's always arise due to different perspectives on the process.
A common mistake can be seen today: testers are perceived as junior developers, and thus QA's are encouraged to emulate the skills and attitudes of developers. In fact, good testers have many traits that directly contract with those that good developers need. The skills that jobs require are different, and often in opposition to each other, and an understanding of that fact is important to get teams of different people working together efficiently.
Unfortunately, many times opposition of opinions grow into personal dislikes, and personality conflicts take over the process of cooperative work. A misunderstanding of what the testers' job is creates constant conflict at the place of employment. Many developers do not realize how difficult system testing can be. It takes patience and flexibility. It requires an eye for detail and an understanding of the big picture. Many testers are frustrated working with developers who think testing is easy. At the same time, I have not yet met one tester who was not fascinated with code writing work.
Having good models for software behavior and at the same time simulate users' behavior is extremely important in system design. Good testers and developers need both. But there are times when each team stresses different talents and calls for different emphases. The difference in focus can be seen in typical responses to bugs. Testers often assess a problem in terms of the potential severity to the customer, but developers tend to pay attention only to fulfilling required functionalities. Both teams clash over the argument of what is more important and what comes first, "the chicken or the egg"
Developers focusing on the application design may respond to bug report (testers' work of art) in one of three ways. First, they dismiss problem–"Why would anyone in the world do that?" The software is working fine in accordance with the design, so they are dismissive because they do not want to admit variations of obvious user behavior deviation or do not want to change their "perfect code". Second, they believe that testers are "just out to get them" and nag without legitimate reason because that the testers just want to show something for their work. Third, developers could see bugs as an interesting addition to their work and bugs show a flaw in the design or at least in their understanding of the design.
On the other hand, testers often are dilettantes and they are proud of it. They sometimes refuse to become too knowledgeable in order to preserve user traits to keep an edge of "dumbness". However, good testers are not afraid to accrue understanding and do require developers to provide exact business rules and design specifications. They get frustrated when developers do not provide such information justifying that they do not possess any. QA's refuse to understand that application can be coded without documentation and specifications. They blame developers for laziness and ignorance./p>
Theoretically, the software life cycle involves a design stage in which applications’ business rules, requirements and specifications developed. QA's are always pleased to be present on meetings where requirements are discussed. However, management and developers most often refuse to acknowledge that all people who are involved in the process must be on such meeting. They ignore testers at this stage of the software development. Although, QA's presence on business meetings is a rare case, I have seen QA's there. They are the quietest part of the team–at this stage software has no bugs because not a single line of code is written yet.
In the coding stage of the software life cycle, programmers write their codes and provide documentation on usage. Only at this stage QA's begin working on the application. Testers are the first to use such requirements to test software functionalities during their preliminary testing runs. Nevertheless, since we all live in the real world none of such procedures are not followed to the fullest. Many times QA's are glad if developers provide descriptive verbal explanation as to what software does and what an average user should expect from it. They are laughed in the face if they ask for anything more than that and accept to get by on what pieces they can gather
The very last stage in software development and production is user acceptance. In this day an age, we know that there is no perfect software yet (of course with the exception of compilers). Users are the ones who suffer the most next to testers, but users get hit worse because of their financial responsibilities and absolutely different role. They do not care what is involved in the design–all they care about is if the application that has been sold to them works to their requirements. Users do not accept that programmers and QA teams had their differences during development and that issues had not been resolved. Users are the ones to pass final judgment if a software development company is to exist. The quality and usability of the software are their main issues and that is what both teams who make and sell the products should be concerned with.
Following are several examples of real life cases and they intend to draw a picture of why users may not get what they paid for.
In my practice I have met some developers that were not very patient and appreciative of the work of QA's and disregarded bug reports for reasons they only thought valuable. Mr. A received a bug report from a team of testers. He spent his time and effort on applications that he thought were perfect; he spent hours figuring out the best possible solutions for what the customer wanted. At that time, he was forced to redo his code just because the QA’s found bugs in scenarios that only they made up. Mr. A refuses to accept a very rare case because a "normal" user would not even think about it. He sent his report back to the QA's who considered their job done when the report was sent out. The managers and project leads ignored all of the nonsense, thinking that it was only a power struggle between testers and Mr. A. When the user installed the software and found nothing wrong with it, he was happy and grateful. Later that day, however, the user brought the software home and showed it to his teenage computer wizard. Of course, after a while the kid ran into the rare situation that the QA’s had described because he was playing with software and was not thinking as his gullible father. The software failed at the first unorthodox trial.
Mr. B was a software developer in a very busy firm that provided services to broker companies. Mr. B was a professional in what he was doing. The company that he worked for fully depended on his software; without his programs all calculations would take ages to finish. Mr. B was proud of his applications even though they had glitches every now then. But his contention was that there is no perfect software in this world and his "baby" was a close to excellent as humanly possible. Whenever he had problem reports from the testing team, his answers often carried "in-house application” words. He was “too busy and too smart to fix little problems because he is working on the bigger stuff". So, the software mainly worked and did what it was supposed to do. But unfortunately, one day a client walked into the office to pick up his contract. He was talking to the business manager to get last minute details. The manager, to prove his point, opened his computer and wanted to show how precisely the client's problems were calculated. He hit one of the problem areas and the client was very disappointed.
Mr. C worked as a chief developer. His was responsible for many applications simultaneously and he did his coding between meetings. He understood that he did make mistakes in his code because he was distracted millions of time a day. His new module had many serious bugs and Mr. C completely relied on his QA team because he did not always have time or his brain was too overloaded to find where the problems were. He found that it was easier for him to wait for the QA’s report instead of looking for bugs himself. The QA team pinpointed problems and set necessary conditions for the program to fail so that Mr. C could find "bottle necks" and breaking spots in the application.
Mr. D was a software developer for a major bank. He was glad to work with the QA teams that were hired as consultants because they provided fresh views and different ways of looking at his programs. Mr. D also found that working with testers put his mind into an unusual state. He could locate problems that he never thought he overlooked. One day, while talking with one of the QA’s about an account profile settings, Mr. D found that the test internal account should not show in the main menu. The QA's were only allowed to work in the test environment and they would not possibly find the problem because Mr. D was the only one working on the real life database. Mr. D would not found the problem if QA's were not testing this part on his application.
Ms. E who was a web site designer found herself in the same situation. One of the QA's who worked with her on the problem web page found some broken links on a few pages. When Ms. E gave back her work for regression testing, she “walked” the QA’s over the changes she made and found that one of the pages should have been opened in a separate window according to business specifications. But the page was opening in the same browser’s window, which was totally against what business analysts wanted to see. Ms. E found the problem accidentally while she worked with the QA's on something else and she was very thankful to them because QA's did not know the specs and Ms. E's work would have had a error otherwise.
Mr. F holds a PhD in Computer Science from Stanford University. He had been developing software for more than 15 years. His task was to develop one of the most popular Internet communities for teenagers. His work was checked periodically by Ms. G's group of testers who knew nothing about the structure of the site or Unix platform or Perl code. They tested the site from an NT server using a copy of the site. Mr. F had no time or ability to explain what his methods were and all he did for the QA group was coping new versions of his code to the server. In the meantime, Ms. G and her group tested the site patiently hour after hour and wrote their bugs into the Defect Tracking system. They stayed after hours to finish up their reports and bug reproduction steps. There were many broken links were found and they reported them. But Mr. F argued with QA team and stated that the links were workable. He apologized for any inconvenience and for forgetting to let the QA team know about the changes. The testers were using an older copy of the site from the same server and that why they had problems accessing some pages. Nevertheless, Ms. G and her group felt that they were wasting their time and company’s money spending hours on the unnecessary testing because of the recklessness of the harebrained programmer.
Team J was a QA team of testers who came to the accounting company very late in the project process. The team had very little time to perform every test they would have liked to do because they found that the application had 'very large room for improvement', i.e. it had a great number of bugs. In addition to very obvious bugs, team J found some that they could not reproduce because of the time limits, but they knew that these intermittent bugs could cause serious damage. The QA team leader reported all these bugs during one of the technical meetings, but, nevertheless, his bug report was ignored. When the accounting application was shipped to the users, they bombarded the development team and management with complaints. Only then, the project manager did realize that team J's report should not have been ignored and should have been taken seriously.
Mr. K was a development manager in a firm that sold computer software for pharmaceutical companies. He could not imagine his work without the QA team, since his work had to be precise and accurate. His group of programmers worked very closely with testers who actively participated in the development process. They provided very clean software for every client and their company’s profits grew tremendously and its reputation was well known. When Mr. K was asked who he would take to a deserted island with him, he said one of the company’s QA's to check his water before he drank it and test the woods for wild animals.
Company X signed a contract with a very captious customer who insisted on strict specifications and a rigid schedule. During the course of development, the client made changes due to market redistributions and the programmers had to implement those corrections into the application. Nevertheless, the due dates were still the same. Even though making changes was a time consuming process and many modules of the program had to undergo tremendous revisions, management did not negotiate postponing the due dates. So, while the development process was taking more time, the QA’s had theirs shortened. Management disregarded the testers' complaints and ignored warnings that problems could occur without a proper testing time frame. The result was the following: the software was shipped to clients with bugs and the clients never dealt with company X again. Later company X folded.
Company Y was selling software for 10 years, but its work force had been changing all the time. Management knew that hiring good professionals was essential in order to stay afloat in this industry, but they seemed unable to keep them for long because management did not want to deal with personal problems within groups. Management established strict rules for the QA's and developers in order to avoid confrontations between teams without paying attention to what their needs were and what particular problems they had. Both teams had to follow rules to the letter and they had no room for improvement or individual opinions. The teams' further separation was established and people did not want to work for the company Y for long because of the atmosphere of dependency and rancor.
Company Z had an IT Manager, Mr. Q, who understood how important good relations between testers and programmers were for the development process. Mr. Q tried to resolve by himself every problem that arose between the two teams. He acted as a liaison between the teams, which established the dependency of both teams on management. This resulted in management becoming a dumping ground for problems. So, direct communication between teams was only possible through his office and when he was out, problems did not get resolved at all. Testers and developers refused to act on each other’s requests unless Mr. Q approved them as valid. The situation became worse as Company Z signed a huge contract for the software that required creativity and an intensive QA process. Mr. Q was dealing with every trivial issue, and his own work as IT Manager was pushed aside.
I took all the examples described above from real situations in which I was one of the participants and witnesses. Any tester who has been in the field for at least 3-4 years can draw every single test case similarly or describe exactly the same scenarios, and every tester can rightfully relate to them.
In spite of all that has been said above, there are several action steps that can be taken to improve the work and skills of the testers and developers, and, also, to expose either category of software personnel to each other’s ideas, education and traits. This can be done for several reasons and in a variety of ways. And, of course it must be done differently for testers and developers due to the discrepancy in their approaches, techniques and skills.
First, the education of testers is needed for the sole purpose of communication with developers in the same language. Of course, most good testers understand the basics of programming techniques and languages, but this is only an alphabet, only a very primitive approach. They need more than basics, but rather an intermediate understanding of the code. One could argue that this would bring a biased approach to testing, but I would not agree with that because testers do not code, they only report that the program misbehaves or has bugs. A decent knowledge of code can helps QA’s to pin point problems in the code, programs’ structures and definitions.
In February 1999, at the Software Management Conference during one of the general sessions, Tom DeMarco commented on training. He said, “Training is allowing the inexperienced person to do slowly what the experienced person does quickly.” This comment resonated for me throughout the entire year. The money, the planning, the communication involved in delivering training to a technical organization are all directed at arming employees for the competition in the business theatre of operations during 1999 preparations for Y2K. And these things are necessary. But I have not forgotten that they are merely the prelude to empowering the inexperienced to master new technology, to practice until they are perfect.
As far as my experience is concerned, I started without much knowledge of programming basics and techniques. Many times I have heard since then that testers do not require any knowledge of the program’s internal structure. That is limited truth. Playing “dumb user” while testing major functionalities of applications is only part of the job. This is a liberty of the immature, rookie tester. Junior QA’s do have the ability and right to judge someone else’s work. Nevertheless, today, I understand that my work would not be as integrated without understanding the coding structure of the program. Authors of the best selling QA book, Testing Computer Software, which won the Silicon Valley Award of Excellence, stress that they would not hire any tester if he/she could not write acceptable codes or at least provide a way of thinking where to start coding (9). In the 21st century world, white box testing, which is concerned with code handling, leaves desks of developers and finds its place in the QA departments. So, my point is testers must take development courses, attend two- three- day seminars and follow all programming innovations. This would take the dilettante labels from their heads. Developers would learn to respect testers as equals who provide assistance and help to hard coding rather than only “making educated guesses”. Testers who possess knowledge of the programming language that organization utilizes during the development bring tester-developer teams closer together since they understand each other from unspoken thoughts and not only words.
Secondly, the chances of speaking the same language and understanding what developers say without lengthy explanation of the basics may grow into discussions of the program in question. Developers are “obsessed fanatics” with their applications and their development language, in the good usage of words “obsession” and “fanaticism”. Application to them is a child they are raising; they mold, they nourish and nurse. So, conversation about their software is an excellent technique to goodwill developers to testers. People are always glad to talk about their children, and programmers are no exception. Such discussions can outreach office grounds and the next thing testers would observe is that developers take them for lunch or a drink. Following the course, friendship may be brought up on the fundamentals of differences, but this time, with mutual respect and interest. That is why many technical weekly meetings involve both groups of testers and developers since they work together on a daily basis and depend on each other. Also, I noticed, as a rule, at every company party, testers and developers sit together. Many times, I invite developers to lunch or to walk outside the office to discuss my ideas and get their feedback on my testing in the more relaxed atmosphere. Brown bag meetings in the lunch or conference room are always helpful and useful. They can be a substitute for technical meetings; business mixed up with pleasure provides unremarkable results. In addition, with the advice of my colleague, I adapted a very useful technique. When I need developers to make some changes that they think unessential or time consuming or just boring for them, I “bribe” them with candy. This works 3 times out of 5 and amazes me every time. Or I start a conversation about something totally different from work and interesting to the programmer and after five or seven minutes of discussion my opinion “drops from the sky” on the needed change. Usually, not always, developers have a harder time refusing my advances and make changes more willingly.
However, I believe testers are not the only people who should take steps towards combining efforts at the team level and understanding each other’s enrollment in the project. Both, testers and developers should participate in “cross training” and inter team activities.
Good testers realize that software testing can often be repetitive and that is the downside of testing because it brings boredom into the job. But QA’s learn to accept this. Unrecognizably, it is a challenge to do repetitive work. This is important and very often necessary. Good testers must be able to remain alert and attentive, even when applying the same test for the fourteenth time. Many developers hate repetition. They hate routine work. Programmers find ways to automate their processes and this provides them with other interesting research opportunities to write the code. Since testers should be required to learn programming languages, developers should learn testing tools and methodology.
Automated testing tolls such as well-known products of Segue, Mercury, Rational, Net Results and many others are fully integrational and skill-based software products that require programming attitude and knowledge. Seminars that are available for testers provide opportunities for testers as well as developers to learn new tool features and implementations. Developers can attend such meetings and find new languages that go with every tool – testing methodology language as well as variations of programming coding techniques. Later, they may get exposure to this language with their QA team who would be glad to explain what and why questionable techniques are implemented and what they are used for.
Of course, some developers may refuse to attend or expose themselves to the testing process. Their arguments could be very valid since they do test their own codes before they turned to the QA department. They realize that room for improvement is indefinite but going in that direction is not their job and they do not have the luxury of spending time on “what could be if…”. There is one negative parameter to their arguments – they do not realize that learning the way testers operate would bring their software creations to a different level due to a reduction of trivial changes and permission of production of more advanced features will allow more time (). I believe that management should require programmers to spend at least a couple of days a month as testers. During this time, under the supervision of advanced testers, developers must produce their own test plans on different parts of the applications under development. This will benefit teams, testers as well as developers. In addition, testers may get new ideas about how to channel their testing, and developers can feel how uneasy, difficult and interesting the job of a qualified tester is.
All solution proposals to unite and explore two worlds have only one purpose. That is to make QA’s and developers understand that what ever they do, what ever they argue about or debate winds up with the same goal: quality software development and production. Either team, regardless of how wrong or correct they are, must know that without each other nothing would be accomplished. Both teams fight for their places in the sun; they fight with mediocrity and repetition for excellence and recognition. Their finish line is the program that will be employed somewhere else and both teams are on the same side of the “barricade”. It is not enough for those involved in software development to simply perceive the test team’s value or development team value. There is a way to be able to see how good both teams are in black and white. Business analysts and end users will come to realize that they need both teams input to ensure that requirements are acceptable. Even business analysts will seek your reassurance that all major components are in the build. But most importantly, the project manager and other stakeholders will count on the hardcore teams to give the true and accurate picture of the risks and rewards of moving toward production. If the development team is successful in creating this “image of excellence”, then the test team will be strategically placed at the center of the software development universe. This will not occur in a self-serving kind of way, but in a way that seeks to illuminate the path to defect-free software products and deliverables.
Mutual teams work will enhance the productivity and quality of the product. Fighting in the rears of the “barricades” accomplishes nothing. There is only one way to rise above companies that do not understand such concepts: to learn each other’s ways and work symbiotically as one organism, as a team. Being exposed to each other’s ways of making things happen is the main solution to resolving some conflicts in tester-developer environments.
People learn to live together on the Planet Earth, so testers and developers can learn to live in friendly manner in the software production office. They also can learn to adapt to any conditions or groups. The lag learns to love his chains, but the software environment is not a prison camp. Learning to deal with a team’s rules and individual characters is part of the job one chooses. This makes everyone’s lives easier and more enjoyable. Every person, tester or developer, has his own character and ways in which he works. Taking into consideration someone else’s character is a valuable trait and may be learned without difficulty.
One of the techniques that help is to accept or deal with someone else’s strange behavior (of course, to the limit where it does not offend anyone) and at the same time learn when not to be offended. For example, I met one developer who had such a low and unpleasant voice when he explained what application under our test did. It was a real torture to listen to him, especially when his voice sounded like an old door hinge, regardless of his willingness to assist. Some testers just decided to give up asking him questions. But those of us who “masochistically” forced ourselves to listen him benefited in the long run because he had his help with understanding functionalities. Finally, after a while he understood his problem and tried to improve.
Good testers must not shy away from arguments. It is their job to report bad news – the messenger should not be punished. Bad news is not always taken well. A respected tester will usually identify where the problem is and usually provide a version and built identifier, record reproduction steps and be available to walk the developer step by step, condition by condition to how the problem was discovered and draw a picture of his process of thinking. Definitely, at lot of times it is hard to pin point the source of the error or bug or program’s misbehavior, but regardless of where the discrepancy comes from – it is the testers job to report it. Sometimes testers may go overboard, which may create different reactions as I pictured above. But good testers need to be the kind of people who are not afraid of other people’s reactions to bad news. Also, good testers want to avoid a situation in which they speculate as to who and what caused the problem. Letting developers acknowledge impartionality of the test process is the key to the message that testers should deliver to developers.
On the other hand, developers often need to avoid the emotional intensity that makes concentration and work difficult. Providing better and fuller information to others who are involved in the project production, especially to QA’s, is an essential part of their job. I have heard trillions of times that developers do not get program specifications themselves, that they get changes request from project managers or business people at water coolers or at the coffee machines. But, since they do write codes based on such minute statements, programmers implement some design and produce modules that are turned over to testers. While developers write their codes, their work is governed by some rules – these are the rules that QA’s require, these are the specifications testers crave; these rules reduce the number of “dumb” bugs by a substantial number and maximize tester-developer respect.
To summarize all that has been said above, appreciating differences is critical for productive teams. Separate and distinctive approaches aid in finding solutions, and mutual respect dramatically improves and accelerates group problem solving. Testers should not be judged according to developer criteria. Empirical thinking is a significant asset rather than an inability to think theoretically. A jack-of-all-trades, QA analyst or engineer should be appreciated rather than criticized for being a master of none. Many of the skills and attitudes that good testers demonstrate contrast with what management often looks for in developers. Productive teams with both programmers and testers need a diversity of skills, i.e. professional knowledge as well as patience and human nature understanding. This would benefit developers to program user-friendly codes and testers who use these codes to bring their judgments with improvements. Everyone on a well-defined team has respect and understanding of mutual goals. Walking in each other’s shoes is always a feasible solution for such groups. Nurturing the skills of developers and equally important skills of testers is a mammoth goal of management as well as each individual on the team. Cooperation between tester-developer teams and a willingness to provide each other with acceptable working conditions is what will allow computer software development teams to remain competitive in this industry.
- WWW Unleashed, John December, 4th Edition, Sam’s Net (1997)
- The Art of Software Testing, Glenford Myers, John Wiley Publishing House (1979)
- Software Testing In Ihe Real World, Edward Kit, Susannah Finzi 1st Edition, Addison-Wesley Publishing Company (1995)
- QA Methodology, American International Group (1998)
- Testing Computer Software, Cem Kaner, Jack Falk, Hung Quoc Nguten, 2nd Edition, International Thompson Computer Press (1993)
- Testing Client/Server Applications, Patricia A. Goglia, 2nd Edition, QED Publishing Group Computer Press (1993)
- Tips from the Training Tsarina, Anntoinette Gurvin, General Dynamics Information Systems (2000)
- The Indespensible Test Team: Gaining and Maintaining Value in 2000 and Beyond, Terrye Ashby, Pointe Technology