Fluent Essays

I updated two files about this chapter and one document about the writing requirements, you dont need to read the all content of the article. You can find 1-2 directions from the two files to discuss and describe your opinions from the chapter. Write the approximately 300 words of your opinions.The requirements of Individual Weekly AHA! Papers has been updated. individual_weekly_aha.docx cohen_et_al._2004_cacm_v47n1pp76_81.pdf lessonplan2.docx Unformatted Attachment Preview Individual Weekly AHA! Papers Hopefully throughout the semester, students will occasionally gain deeper learning/insights that they will find especially useful in their personal or professional lives. I call these kinds of insights “AHA’s!” because they often occur to us seemingly out of nowhere. These AHA’s! are not usually fact-based pieces of information, but are usually integrative ideas about how to apply IT in personal professional lives, how to interact with others, or perhaps to how to be more effective in your endeavors. To this end, every week or so (or more often if the student prefers), each student should think deeply (i.e., reflect) on their thoughts and sentiments as it relates to the course (e.g., principles discussed, technologies used in the course, online vs. traditional learning, personal experiences from the course or team project or extra readings or videos, etc.), and write down their thoughts that might be “AHA!-worthy.” Each AHA! paper should be approximately 300 words in length (minimum 250 words), have a meaningful title, and be uploaded as a single Microsoft Word document (.doc or .docx) to the “Dropbox” on the published due date. BY CYNTHIA F. COHEN, STANLEY J. BIRKIN, MONICA J. GARFIELD, AND HAROLD W. WEBB MANAGING CONFLICT IN SOFTWARE TESTING CONFLICT BETWEEN SOFTWARE TESTERS AND DEVELOPERS IS INEVITABLE, BUT MINDFUL MANAGERS MINIMIZE ITS EFFECT ON DEVELOPMENT PROJECTS THROUGH COMMUNICATION, MUTUAL RESPECT, EVEN SOCIAL INTERACTION. Software development involves many people, each focusing on some aspect of the overall process. Software testing is a crucial aspect of ensuring the quality of the end product. Although many tools and automated methods are available, the result ultimately depends on the interpersonal interactions of the people producing the software. However, they often don’t all share the same goals or mindset or necessarily feel compatible. Each such factor might thus contribute to conflict, an inevitable part of organizational life managers are constantly trying to resolve [6]. I L LU S T R AT I O N 76 January 2004/Vol. 47, No. 1 COMMUNICATIONS OF THE ACM BY O R E S T E Z E VO L A COMMUNICATIONS OF THE ACM January 2004/Vol. 47, No. 1 77 Conflicts arise in organizations for a variety of reasons, including scarce resources, interdependent work, differentiated work, competitive reward systems, perceptions of inequity, and asymmetrical distribution of power [4]. While conflict does not always produce negative results and can even enrich organizational outcomes [3], it can certainly disrupt work processes and contribute to poor performance. Software development, like any other work activity, involves many possible sources of conflict that can undermine efficiency. The potential for conflict among software developers and users has been identified [2, 8]. Similarly, conflict can occur within the software development group itself, particularly during the inherently adversarial software testing process. Because conflict often has the potential to interfere with work performance and product quality, it is important for both scholars and practitioners to identify its sources in software testing, understand how it affects work processes and outcomes, and determine ways to manage it better. In order to understand how best to accomplish these objectives, we conducted in-depth field interviews in 2002 with 10 software testing professionals from four different U.S. companies, two large, one mid-size, one small [1]. These interviews led us to categorize three basic conflict layers—process, people, and organization—and a set of actions available to managers for addressing each of them (see the figure here). Process (the scarce resource of time). The most frequently mentioned source of conflict by the testers and project managers we surveyed was the allocation of time between development and testing. This is not unique to software testing, as time is a persistent issue in all types of project management scenarios [7]. As organizations of all types strive to quickly get sophisticated, defect-free products to market, time inevitably becomes scarce and more valuable. Testing is often postponed and planned testing time reduced to stay on the delivery schedule. The result is conflict, as testers and developers compete for time to complete their tasks. The sequential nature of development and testing often results in testers being left with little time. One tester we interviewed said, “They [project managers] let the developers code up to the 11th hour. Then they expected it to be tested. It’s very frustrating knowing that once it goes into production there is not enough time to test because they [the developers] were being allowed to 78 January 2004/Vol. 47, No. 1 COMMUNICATIONS OF THE ACM develop up to the last minute. I mean literally the last minute—the night before.” Another tester said, “I think the developers look at that schedule and see their little piece of time. If it bleeds over, so what? Since they’re not at the tail end, they’re not the ones burning the CDs and sending them out the door. They don’t have the same sense of urgency as the people on the tail end of the project. As development slips, the sense of urgency increases, the stress goes up, and the tension between the two groups starts flying.” Process (user vs. technical requirements). Another source of conflict we identified is the kind of focus Organization developers and testers bring to their jobs. Testers and managers agreed that People testers were more focused on user requirements and developers more on the Software technical nuances of softTesting ware design. These Process equally valid but distinctly different views of the process can add value but also create problems. Developers flexing their Layers of conflict. intellectual muscles often look for novel ways to achieve results. This can lead to application goals incompatible with those of the testers. One example mentioned by a tester we interviewed was “Some of them [developers] embellish on the requirements. Like this one instance where a developer had buttons in his application. There was nothing wrong with the buttons; there was nothing wrong with the way they worked; nothing wrong with the way they looked. But he takes it upon himself, goes out and finds some new buttons, implements them, and they don’t end up working on the browser I’m using. Then he changes them back to the way they were because he realizes a lot of users are going to have my version of the browser. Doing that, he forgets about some of them. So there’s a couple that don’t work.” People (different strokes). Not only do testers and developers perceive the process of software development differently, they often have their own unique mental processes and personality attributes. A tester told us, “Developers think and write the app the way it should work. And they can’t understand why anybody would use it other than the way it should work. It’s an entirely different mindset as to what QA [quality assurance specialists] feels is an effective unit test and what development feels is an effective unit test.” A manager told us, “Our testers are geared toward testing; they have an understanding of the business, Organization (managers matter). Similarly, the not just from the software development standpoint manager’s role in setting the tone for the importance but from what occurs out there in real life and what of testing was also discussed by our interview subjects. needs to happen from a functional perspective.” One tester said, “I think it starts from the top; they Many testers described themselves as “compulsive” have to support QA. Developers see that QA is not and “very detailed” and the testing group as “cohe- getting the support and the leverage in the company, sive.” Developers were typically described by testers so they won’t, in turn, respect what you’re doing.” and managers as “very creative,” “temperamental,” Another tester said, “We have a QA manager whose and “individualistic.” While these characteristics often style is kind of adversarial. The first QA manager we mean individuals are well suited to their work, they got, she did a very good job of building a working can also lead to incompatibility when they work relationship [with] the developers. They brought in together. this new QA manager, and she basically severed all People (personalization of code). Many developers that relationship building.” Managers are often view their code as an brought into conflicts extension of themselves between testers and Sources of Managing Conflict Conflict and thus take it persondevelopers. This can be a Scarce resource Time management ally when someone finds treacherous process, leadof time Plan for schedule overruns Manage effect of schedule changes fault with it. Conflict Processes ing to results like the one Learn from project experience User vs. technical Common goals ensues as errors are reported by a tester who requirements Align individual goals with process metrics detected and communirecalled a situation where Value team more than individual success cated to developers. “the developers fired the Different strokes Team building Train in conflict resolution Most testers cited manager.” Sponsor group activities Support informal social contact developer reluctance to People Personalization Understanding one anothers point of view of code Design jobs to support mutual understanding The Conflict accept the existence of Involve testers in requirements planning Dynamic errors, saying, “DevelopPower and Structure for success Such candid comments ment wants you to show politics Co-locate teams Integrate development/testing functions yielded insight into the them six different ways it Organization Instill ownership Managers matter Involved leadership common sources of conshould or should not run Create collaborate atmosphere Model effective conflict management flict experienced by softa certain way” and ware testers. Conflict “That’s not my code; also adversely affects work clearly the test was broken.” One said, “There’s the Managing conflict at processes, the quality of work, usual resentment and the ego of it, that we’re beating the source. and the quality of work life. up their design or their code or whatever.” A more extreme reaction may result in personal attacks and Consequently, managers need to address the conflict the lodging of complaints against co-workers. One dynamic. Several ways in which conflict might be tester said, “I got dinged by one of the developers who managed better are suggested in our interview results thought, for whatever reason, I had something against (see the table here). Process (time management). Time itself is a requireher. She filed complaints with the manager about me. She said I wasn’t doing my job, that I was hindering ment for effective testing. Although a lack of time the whole development process. But the problem was might be an expectation for many testers, it still causes considerable stress and conflict. One tester said, entirely on her end.” Organization (power and politics). Though most “We’re told to hurry up and wait, wait, wait, wait. organizations recognize the need for high-quality And then you’re coming in here on Saturdays to test testers and their specialized skill set, testers still strug- because they [the developers] didn’t deliver until Frigle to win the respect they deserve. One manager told day. You’re being squeezed to the very end.” The loss us, “If you had a diagram with God at the top, the of testing time was interpreted to mean testing was engineers [developers] would put themselves above not highly valued. Managers need to schedule enough that.” Many testers feel they struggle to maintain their time for the testing process and refrain from canniplace relative to that of developers. Another tester balizing that time when developers miss their deadsaid, “We have to fight to keep ourselves equal; we are lines or when user requirements change. In planning continually doing things to make ourselves feel just as software projects, managers can take advantage of worthy.” The lack of status and support makes the lessons learned from past project management experitester’s job more difficult and time consuming, as the ence. One technique that might help with the identistruggle for recognition becomes part of the job itself. fication and resolution of time conflicts is called COMMUNICATIONS OF THE ACM January 2004/Vol. 47, No. 1 79 critical chain scheduling, which seeks to avoid the testers or managers we interviewed indicated that coneffects of Parkinson’s Law, whereby work expands to flict-resolution training was offered in their organizafill however much time is available. Instead, it empha- tions, formal training would clearly benefit work skills sizes the completion time of an entire project, rather for both groups. Better conflict-handling skills not than the individual activities along the project’s criti- only help resolve today’s problems more effectively, cal path. When time overruns occur, time must be they build better working relationships for the future. taken from the project buffer, a common pool of Conflict-resolution skill building should include com“delay time” used by all project activities. Continual munication skills, cooperative problem-solving techrequests for scarce buffer time not only raise aware- niques, and informal mediation techniques. ness of time estimation problems but maintain the Another way to manage differences is to foster relaintegrity of testing time; time overruns are taken from tionships between testers and developers. Testers and the buffer, not from testing time. developers who communicate only when problems Process (setting common goals). Conflict often results occur lack a robust social fabric with which to smooth when testers and developers do not share common the process. Several testers and managers we interwork goals. Group and individviewed indicated that social contact ual goals need to be clearly paved the way to better working defined, not only to release relationships with developers. One software in a timely fashion but manager said his company sponTHE LACK OF to ensure the release of highsored group social activities outside quality code. Performance meaof work specifically to improve relaSTATUS AND SUPPORT sures need to be reflected in tionships. Participants went to MAKES THE TESTER’S JOB each aspect. As an example of amusement parks and museums setting common goals, one and joined in other recreational MORE DIFFICULT AND manager told us that testers and activities. Benefits accrue from indiTIME CONSUMING, developers were “driven by the viduals becoming more comfortable excitement of seeing the hottest with one another and being able to AS THE STRUGGLE FOR network in the world with their use these back channels to manage RECOGNITION code running on it; they really problems productively, including want that. QA also wants to see informal gatherings after work and BECOMES PART OF it happen. So their mission is in common areas during work THE JOB ITSELF. shared, which I think really hours. works.” He added that when People (understanding one anothtesters found problems the er’s point of view). Conflict also developers would say, “I’ll fix it stems from the fact that developers right away” or “ I never thought of that. We need to and testers do not view the software process the same make sure the test covers that next time.” As this case way. More important, they don’t always realize that illustrates, the incidence of conflict is reduced when their perceptions don’t match. Structured work activfinding defects becomes a collaborative process with ities designed to acquaint developers and testers with the common goal of improving the software. the nature of each other’s work could help prevent Another way to align work performance for the some of these problems. Job rotation is one tool sucsake of meeting organizational goals is by selecting bet- cessfully applied to improving employees’ underter quantification measures of software testing standing of the various jobs within an organization. processes. Using such methodologies as the Software Although strict job rotation might not be appropriate Quality Metrics Methodology (IEEE Standard 1061- among software testing and development positions, 1998) [5], managers tailor a set of measures to evalu- some aspect of job design could still be used to gain ate development and testing activities aligned with similar benefits. Likewise, early and consistent software system requirements. Properly selected mea- involvement of testing in the requirements planning sures should motivate managers and employees alike phase may provide opportunities for joint underto achieve system requirements rather than focus nar- standing at a point in the process when both groups rowly on the products of their individual units. have the time to listen to one another and when there People (team building). Some testers seem to learn is less existing conflict to inhibit communication. (by trial and error) how to approach developers when Organization (structure for success). Our interviews experiencing conflict. It can be assumed that not all identified several structural concepts for addressing testers are equally adept at this. Although none of the conflict. The most popular among testers was physi80 January 2004/Vol. 47, No. 1 COMMUNICATIONS OF THE ACM cal co-location. When testers and developers worked in separate locations, communication, as well as personal relationships, was impaired, unlike when both groups worked in close proximity. One tester suggested the two groups should be made to work side by side, adding, “I don’t care if you’re an organization that has great email, network access, and everything else. If you don’t have that personal interaction where you can talk to somebody to resolve an issue, that 10minute issue turns into a full day.” The second structure is fully integrated teams of testers and developers, reducing the intellectual and physical distance between the groups and facilitating joint goal-setting. However, testers working in integrated teams cited many of the same conflict sources as testers in organizations where the functions were separated. This paradoxical outcome highlights the fact that conflict in software projects must be addressed at multiple levels. The testers did feel, however, they had closer relationships with and better access to developers than testers in nonintegrated structures. Another structural form shown to improve conflict management is the use of integrated teams vested with comprehensive product ownership. In it, team members follow their applications into the maintenance and enhancement portions of the product life cycle. As the manager of one such organization told us, the team receives the fruit of its labors. This sense of ownership helps establish a common focus for all team members because they know they are responsible for how the application works for end users. Organization (involved leadership). Finally, acknowledging that developers and testers alike take their cues from the behavior of their managers, managers must signal that testing is an important component of the software development process, not an unrelated activity. Managers must carefully implement performance metrics and goals and provide feedback to development and testing that is congruent with mutually compatible project goals. Managers also need to understand that conflict between testers and developers is a normal part of the work process. The most notable characteristic distinguishing effective from ineffective managem ... Purchase answer to see full attachment