NVH’s Blog

http://www.microsoft.com/downloads/details.aspx?familyid=daf69de7-dd1a-4369-b1c1-5ca32f6a6ae5&displaylang=en

How to End Wars Between Testers and Programmers
by Scott Berkun, author of The Art of Project Management
07/08/2005
There’s a natural conflict between testers and programmers because of the difference in perspective each role has. In the simple view, programmers are centered on creation: they make things that didn’t exist before. Like most creators, programmers have a natural optimism about making new things and solving problems. (The programmer’s motto: “Given enough time, I can build anything!”)

On the other hand, testers are centered on inquiry and skepticism. Testers have doubts about all engineered things. They use their knowledge to bring light to the dark corners of decisions others are ignorant of or in denial about. (The tester’s motto: “Everything has flaws and I can prove it!”)

While it’s possible to bring these two forces, optimism and skepticism, together and create a synergy of talents that makes for better software, it’s rare that this happens. Often individuals stay polarized in a narrow programmer/tester, optimist/pessimist mindset, never stepping back to consider the advantages of using both points of view. The code becomes the victim of the team’s politics and is thrown back and forth over the dividing wall. By the time the project is over, the team has spent more time arguing over how to do the work than actually doing it.

The best way to end struggles between programmers and testers is to redefine the goals of the work so that their roles can be collaborative, not adversarial. While it’s true there are many different ways to organize programming teams, including some where there are no dedicated testers (some argue that a true software engineer is a master of quality assurance), this article assumes that you fall into the majority of mid- and large-sized development teams with some kind of dedicated test or quality assurance role.

Matching Responsibility with Authority
Related Reading

The Art of Project Management
By Scott Berkun

Table of Contents
Index
Sample Chapter

Read Online–Safari Search this book on Safari:

Only This Book All of Safari
Code Fragments only
One challenge for testers, or quality assurance types, is that they are often held accountable for the quality of what is made, despite having little influence over how the software was designed. In the worst cases, the programming team is several weeks ahead of the test team, writing much code before the test team is able to get involved. Instead of quality assurance, something that implies confidence (”I assure you the quality will be high”), they are really doing quality patchwork (”I’ll get the quality as high as I can given what you’ve handed to me”). Bringing testing in late with few resources makes quality assurance, in the true definition of the term, impossible.

The simplest way to minimize strife between test and development is to match the test team with enough authority to live up to its job title. Either they should be granted enough power to participate in, or give feedback on, the early design of the software, or the limits of their role should be acknowledged openly. But if you keep a test team stuck in between, with high responsibility but little or no power, they are bound to fail in ways that disrupt the entire project. I’m not advocating that testers should rule the world. I’m simply saying their responsibility should be roughly equivalent to their authority.

The best development teams I’ve ever seen figured out their roles early on. Testers, programmers, and anyone else spoke up early about what they felt was important for the project and how their expertise should be used. If the team had good leaders, they’d negotiate agreements about which kinds of issues would tend to be decided by programmers, which ones would tend to be decided by testers, and which would be decided collaboratively by both (or more) parties.

Early Partnerships
If you want people to work collaboratively, you must provide time for them to build relationships with each other. It’s impossible to share important things with people you don’t know very well. (Imagine trying to explain to your mailman your deepest, darkest secret fears. It doesn’t work. And worse, you might stop getting your mail.) Given this fact of human nature, it’s not surprising that many programmers resent the involvement of testers. If, a month into a project, a tester shows up looking for flaws, they will meet resistance. The source of the programmer’s pride, the quality of their code, is being challenged by a complete outsider and the tester will be treated as a threat, not an ally.

Instead, programmers and testers should be matched from day one. They’ll meet and discuss what they expect from each other, and what activities they each expect the other to do. They’ll use any project goals or work item lists to prioritize their efforts and help make decisions that impact each other. There will be every opportunity for the programmer to see the tester as a way to help improve the quality of their work on a daily basis, and increase their pride. The tester won’t be an outsider looking for flaws and handing out demerits. (”Bad programmer, bad!”) Instead, they’ll be an insider, a collaborator, intimate enough with the programmer’s work to help in ways no one else can.

And perhaps most important of all, building programmer/tester relationships early creates the bonds needed for the project to survive tough times. When problems arise late in the project and stress is high, people will have a history of trust in each other. They will respond to pressure and new challenges by looking for solutions instead of pointing fingers.

Pages: 1, 2

Print
Email Discuss
Add to Project
Trackbacks
Blog this

Tags: programming testing development management software
Bookmark with del.icio.us

How to End Wars Between Testers and Programmers
Pages: 1, 2

Programming with Quality in Mind
Often, programmers and testers have very different ideas of what quality means. They’re not alone. People have been arguing about quality for hundreds of years and haven’t gotten very far (see Pirsig’s Zen and the Art of Motorcycle Maintenance). The solution isn’t in finding a specific answer for all time, which is impossible. Quality is highly subjective and means something different from project to project. Instead of seeking out a single answer, leaders have to drive for collective agreement on quality for the current project, and avoid philosophical debates.

Smart teams work on defining quality early. Since they know that towards the end of the project they’ll need test cases to find bugs and evaluate progress, they decide not to wait to the end to sort those things out. Decisions about quality can be made early on.

Test-driven development (TDD), a popular approach for bringing quality into the process earlier, makes testing and quality assurance an integral part of every function and feature design. Before the code is written, test cases–conditions that the software must satisfy before it can be released–are created that define the conditions the code is to achieve. Just as you’d be foolish to start driving your car without knowing where you’re going, why write code before you have a goal in mind? (Unless of course you enjoy wandering around highways and code bases.)

The spirit of TDD applies to all types of work. If you define the characteristics of the end results early, and communicate them to others, the odds of success always go up. It separates the ends from the means, freeing everyone to use whatever skills they have to help the project achieve its goals.

Only Leaders Start and End Wars
In the history of warfare, one thing is clear. It’s those in power that create the conditions that lead to war. Whether it’s acting out of fear or refusing to compromise, leaders have the power to start and end conflicts. Testers and programmers are no different. If there’s strife in the programming trenches, look to the leaders for the causes.

The relationship between the most senior programmer and most senior tester sets the tone for the rest of the organization. If they ignore, ridicule, or patronize the other, others will follow. Leaders define a model for behavior–both in terms of how work in that role should be done and in how people in other roles should be treated. This also applies to group managers. The behavior of person managing all of the programmers and testers will define the rules of behavior for everyone else in the organization.

To improve on relationships between testers and programmers, the respective leaders need to take responsibility for the situation, prioritizing it well against more technical kinds of work. Forwarding articles like this one around can help bring light to the problems. But real improvement can only come when leaders step forward, openly acknowledge the problem, and bring people in from both sides to create a collaborative plan for how things must change.

Scott Berkun is the author of The Art of Project Management. He currently works as an independent consultant in project management and product design, and runs the pmclinic, a friendly discussion forum on project management issues at www.scottberkun.com.

——————————————————————————–

Next Page

Print
Email Add to Project
Trackbacks
Blog this

Bookmark with del.icio.us

Aw, Gee, Mom, Do I Have to Test My Code?
by Steven Feuerstein
06/01/2000
Introduction
Resources

• Documentation
• Software
• Register

I love to create new things, and that is one of the reasons I so enjoy writing software. I love to take an interesting idea or challenge, and then come up with a way using the PL/SQL language (since at this point in my life it is the only computer language I know) to meet that challenge.

I have to admit, though, that I don’t really like to have to take the time to test my software (nor do I like to write documentation for it). I do it, but I don’t ever really do enough of it. And I have this funny feeling that I am not alone. The overwhelming reality is that developers generally perform an inadequate number of inadequate tests and figure that if the users don’t find a bug, there is no bug. Why does this happen? Let me count the ways…

The psychology of success and failure. We are so focused on getting our code to work correctly, that we generally shy away from bad news, from even wanting to take the chance of getting bad news. Better to do some cursory testing, confirm that it seems to be working OK, and then wait for others to find bugs, if there are any (as if there were any doubt).
Deadline pressures. Hey, it’s Internet time! Time to market determines all. We need everything yesterday, so let’s be just like Microsoft and Netscape: release pre-beta software as production and let our users test/suffer through our applications.
Management’s lack of understanding. IT management is notorious for not really understanding the software development process. If we are not given the time and authority to write (in the broadest sense, including testing, documentation, refinement, etc.) our own code properly, we will always end up with buggy junk that no one wants to admit ownership of.
Overhead of setting up and running tests. If it’s a big deal to write and run tests, they won’t get done. I don’t have time, there is always something else to work on. One consequence of this point is that more and more of the testing is handed over to the QA department, if there is one. That transfer of responsibility is, on the one hand, positive. Professional quality assurance professionals can have a tremendous impact on application quality. Yet developers must take and exercise responsibility for unit testing of their own code, otherwise the testing/QA process is much more frustrating and extended.
The bottom line is that our code almost universally needs more testing. I have recently spent a fair amount of time thinking about how to improve my testing procedures. I have also studied test “frameworks” developed by other programmers, who work primarily with object oriented languages. An obsessive coder, I then proceeded to construct my own framework for unit testing PL/SQL programs. I call it utPLSQL. I have teamed up with O’Reilly & Associates and PLNet, a brand-new PL/SQL open source repository, to make this framework (set of packages and procedures for using them) available to all PL/SQL developers.

You will find in the remainder of this article a look at the all-too-typical way we test our code. You will find on this site all the information you need to learn how to leverage utPLSQL in your environment.

Today, thinking “Outside the Box” is not enough. Companies have to live “Outside the Box” in order to create meaningful business change. For example, instead of holding a strategic planning meeting at the home office or in a local hotel, take the entire team to an inspirational and unusual location, Bora-Bora for example. Why? Because your team will think much differently in Bora-Bora than they will in the same familiar surroundings. When one�s entire being is immersed in a different culture, people can�t help but think more creatively and with greater passion.

If planning meetings are continually held in the office, the company will likely get the same thoughts and ideas they have always received. Companies that seek innovation and creativity from their people first set the scene. They hold important meetings, such as strategic planning, team building and problem-solving meetings in a destination and manner that inspires the participants. The result is a shift in perspective, which often produces solutions that were previously not considered. That�s part of living “Outside the Box.

Inventiveness and change are the by-products of seeing things differently. When this happens, possibilities begin to flow. Suddenly new ideas of what companies (or people) want and how to get there reveal themselves. A shift in business perspective can open many doors. Once the door is open, the hard work has been done. Then the risk of stepping through it doesn�t seem quite as scary.

The Facilitator

To maximize contributions and creativity, it�s important for the CEO or top management executives to participate in, but not dominate, the meeting. Why? If the CEO is the facilitator, participants tend to echo the leader�s ideas, and the CEO may unconsciously push his or her own ideas. That format doesn�t encourage living “Outside the Box”. In addition, facilitation is a skill that most leaders don�t possess. The facilitator needs to be able to push the meeting forward and free up the CEO to add creativity, not leadership. What�s the alternative? Hire a pro to run your meeting. Trained facilitators or change management experts help people open their minds to new ideas and new methods that may feel uneasy at first, but are necessary to birth change. In other words, they help meeting participants see things differently and create new and better ideas/goals.

Overcoming Limitations

“The Box” is really a comfort zone. It is where people feel at ease, where they feel safe. There is nothing wrong with feeling comfortable and safe. However, if you look at the accomplishments of great thinkers, business leaders, performers, athletes and artists, you will see they reach the pinnacle of success in their respective fields because they choose to move beyond what was comfortable, what is known. They begin to think differently, which leads them to see things differently and, in turn, to DO things differently. They all have taken risks and stepped out of their comfort zone in order to achieve their goals.

For example, Edison never slept. Instead he took naps, with a rock in his hand! He did this because when he fell from the dream state, where he got his ideas, into deep sleep, the rock would fall and wake him up. He was then able to remember his dreams, and that is how he got the ideas for his many inventions.

Innovation requires high-risk challenges to business. Successful entrepreneurs take risks, and step out of their comfort zones. Whatever the greatest fear, they face it and find ways to walk through it. Consulting with a mentor or a high-level executive coach can help jump that hurtle. Most importantly remember that while there is risk in trying something new, no matter what the outcome, there is no failure. And don�t expect to do it all or right the first time. Even for the most successful, risk taking and tolerance are learned skills. Great leaders don�t prepare to fail, but accept not achieving all their dreams at once, and they never give up. Winston Churchill said, “Success is going from failure to failure without loss of enthusiasm.”

When people are the first to do something new in life, whether it�s a first job, or creating a new product, it usually takes a long time. That also applies to any new venture, whether it is opening a business, selling a company or retiring. New territory is definitely outside the comfort zone even if it�s a lifelong dream. Once navigated, the terrain of a new process becomes familiar and doing it again will become much easier.

Repetition can ease the anxiety of a difficult task. For example, after growing and selling a first business, there is much less anxiety starting and growing the second. The same principle holds true when beginning to think differently. Most successful executives find whatever challenge they accept, they may feel awful and awkward the first time. Yet, the second time they do it, they have more command of the situation. There�s no question that it is uncomfortable venturing into unknown waters. Yet, it is crucial in order to reach new levels in one�s professional and personal life. Remember, the only people who are wrong are those who say, “It can�t be done”.

The Idea Zone

In today�s marketplace, a willingness to stretch and to grow is essential. The world is changing rapidly, and a new approach to business and management is necessary to meet the demands of these changing times. Accept the challenge. Go beyond the fray. Step out of your comfort zone, and see the limitless possibilities that exist.

By conquering the very things that terrify people the most, the boundaries literally melt away. Obstacles that have held people back all their lives become steppingstones to a new vision. As people develop new, shared visions, others will follow because of the convictions proponents have. That�s when people experience the exhilaration, freedom and power of the zone outside the box. They are living in the IDEA ZONE. This is where joy, success, creativity and personal power reside.