One question I am often asked is “Does testing add value?” Many people who ask this question are development or Q/A managers who are trying to figure out how testing fits within an agile environment. My simple answer is: “No, it does not.” 

Now, before you get all half-cocked, I am not saying we should ship a product that is hanging together by dental floss. I am definitely not saying let’s just throw in more and more features and leave less time and resources to maximizing quality. I mean quite the contrary.

When I say testing has no value, I mean the time it takes to test a product doesn't add value to the end customer. Value, by this definition is "something that takes the form, feature or function that the customer is willing to pay for." Customers don't want to pay for testing. They want to pay for a high-quality product. To illustrate, let’s look at two different ways to develop a product:

1. Big bang approach: Spend a lot of time building and ignoring defects along the way because they will be addressed in the 'Testing' phase. Defects pile up, get more and more complex and worse, get more and more buried. The engineers/developers then, need to go in and spend most of their time finding the defects before fixing them. This is a lot of time and cost that has to be built into the cost of the product. This doesn’t even take into consideration the inefficiencies of bouncing the defect between the Q/A group and development groups. Customers pay for this necessary step but it adds no value to them. A good amount of the cost and time of finding and fixing the defects could have been avoided.

2. Alternatively, a savvy organization will adopt practices to build integrity into the product and test as you go in small batches. In fact, they will develop requirements AS test cases. The developers build to those test cases, which are objectively measurable and testable as you go. In essence, the developers allow the testing to drive development, not the other way around. This, of course, is the philosophy of test-driven development. The idea here is to build small, high-quality slices of the product and then integrate it in as soon as possible. Part of this continuous integration involves testing the whole as you go. If defects appear, they will most likely be caused by the latest addition. If this latest piece is small, the defect can be found and resolved easily.

A further step would be to avoid creating as many defects as possible by using best practices and quality principles during development. One more tool would be to borrow the concept of a 'WIP Cap' from Lean. This means that if we reach a set number of open defects in our database during development (usually 5 or less), we all stop, fix them and move on. It is much more efficient to fix them now than later when the product is more complex.

The second approach exposes problems in hours and days, not months later when different components are completed independently and finally integrated. It will create a higher quality product with severely reduced time in the end and thus cost and time to market because teams don't have to find and fix all these hidden defects that were created by ignoring them along the way. This is more valuable to the customer because they are spending most of their money on creation of features, not on finding hidden defects. Of course, even this approach will not be a 100% bug-free but industry metrics have shown defects to drop as much as 80% in a development life-cycle.

So is testing valuable to the customer? Still no. Is it necessary? Absolutely. However, by using good quality practices to build integrity in, let testing drive development, integrate in small slices and test as you go, the time and effort to test will drastically reduce creating a much more efficient development group.

It is almost guaranteed that when I work with new organizations, one of the first questions that comes up is “How does the development organization work with the Q/A organization?” This question is a stinker. A seemingly simple question actually is pointing out much deeper organizational issues that go beyond testers to how we see all roles within an Agile environment.

That question usually indicates that most managers are trying to force-fit Agile methodologies into the old organizational structure. This is not just inefficient, it is detrimental. When thinking about moving to an Agile framework, an organization must consider what we are delivering and how. Practicing Agile means delivering small, vertical slices of the product every iteration. Vertical in this case means a slice that encompasses a feature from the customer-visible front-end to the back-end and everything in between. 

The key mental sound bite here is that a slice isn’t done until the customer sings (with joy and praise, that is). To be done with a vertical slice, it needs to be developed, integrated and the whole product (up to that point) tested. To say a slice is done, means it is usable by the customer and is as close to shippable condition as possible. (I will have future posts on how to use this model with mixed software and hardware development).

The most efficient way to accomplish this is to reform a team from component-based teams into vertical teams. A vertical team is made up of all resources I need to finish that vertical slice. This may mean a GUI developer, the business logic fellow, the database expert, the network security professional, etc. – whoever is needed to complete the feature in its entirety. This also means that a Q/A professional is a part of the team, working hand-in-hand to create a high-quality increment. Developing even a small chunk and then ‘throwing’ it over to a separate Q/A group will not yield the efficiencies that well-practiced Agile teams boast about.

With that said, keep in mind that the Q/A professional’s role changes within the team.  We don’t just want to put a tester with developers.  We don’t want to create a situation where developers throw completed items over a mini-wall to have tested.  Rather, the developers themselves will do as much of their own testing as possible.  The goal is to create a team that has powerful skills to deliver the highest quality product.  The Q/A professional will be responsible for ensuring all test cases for that iteration are defined, mentoring developers on building testing skills, including how to think about, write and execute test cases as well as helping the team automate as many test cases as possible.  Just as they teach the team how to test, the team will teach the tester how to do simple coding for the sake of test automation.

Last but certainly not least, an essential part of the vertical team is the Customer – or at least the best representation of the customer that we have internally, usually a Product Owner. Unlike someone who furnished a book of requirements, expects delivery many months later and wants no communication in-between, a Product owner works with the team(s) on requirements, is essential in breaking them down vertically and works side-by-side with the team during the iteration planning and reviews. Product Owners may not necessarily be co-located but will answer any questions asked by the team in a matter of hours, not days or weeks.

To be truly agile, you need to plan, think, build on a feature-by-feature basis. To accomplish this most efficiently and effectively, the team needs to be vertical – have all the resources that are necessary to complete the features within the team. This includes, developers, Q/A personnel, Product Owners, documentation, etc. Pets, however, are optional.

All projects have at least one thing in common at inception: uncertainty. This may be uncertainty over how best to use a new technology, how to design a new feature, how to learn a new development language or even how to create a new process that will work better for us. Throughout planning, we may be able to identify many of these points of uncertainty but one thing is for certain: these points of uncertainty are some of the main causes of risk within a product development life-cycle.   

The best way to mitigate risk is to take uncertainty out of play. However, the way this is accomplished may mean the difference between a successful project or a gigantic failure. When faced with uncertainty, it is incredibly easy and tempting to fall back to the traditional methods of dealing with that uncertainty:

1.  Make unfounded assumptions and forge ahead confidently, never looking back.

2.   Deny the uncertainty and forge ahead confidently, never looking back.

3.  Brow beat your developers until they say they have a solution (which is all you need to hear as a Manager) and forge ahead confidently, never looking back.

Please comment if any of these methods ever consistently worked for anyone. I’d love to hear from you. 

These methods all center around getting some plan down on paper after some small initial discussions, set it in stone and forge ahead assuming nothing will change. This path is almost certainly ineffective because we have not understood the problem and have no strategy to find the answers to those uncertainties. Why do we do this? Haven’t we learned from the past? Unfortunately, learning from past experiences would mean going against  certain aspects of many organizations’ development culture and uttering the three most appalling, dreadful and hideous words that a developer can say: “I don’t know.” 

We as developers have a stigma around those words. In some organizational cultures, they are taken as a sign of intellectual weakness among peers. In others, it is an expectation from the management that if you are a subject-matter expert, you know what you need to.  The fear for most is hearing those three words thrown back in your face at the dreaded performance review.   If you have other reasons, please let me know.

The truth is that some of the smartest developers I know, the ones I most respect, often say those words and say it proudly. In a true Agile culture, it is not only OK to say those words, it is expected.  It is a sign of greater intelligence. Better to establish we don’t understand the right path than pull something out of thin air (or some other, more undesirable place – use your imagination), even if you are almost certain to be wrong, just so you can appease your peers or manager.

With that said, simply stating “I don’t know” isn’t good enough. It should be followed by “Let’s conduct an experiment.” An experiment in its simplest form is the process of answering a question. “Is design A better than design B?” “Should we build it or buy it?” “Should we use this form of visual management over our previous one?” Whatever needs to be done to answer your question will be your experiment.  It does not have to be long, complicated or over-analyzed. It just has to be enough to either get you to an answer or to unveil the next step toward the answer.

The only way to mitigate or eliminate risks is through gaining knowledge. One of the best ways to gain knowledge is through experimentation. An experiment is simply a way to an answer to our unknowns. Those answers could mean the difference between project success and failure.

I would love to hear more on and discuss more about experiments you have conducted to overcome uncertainty. Please feel free to post in the comments.

And a brave new one it is!  We at Agile Ethos would like to proudly announce the launch of our blog!  It is our outlet to share our knowledge, talk about our beliefs and just vent once in a while.  We are trainers and coaches who believe in what we do – transform organizations to have the highest quality, value to the customer, efficiency and by the way, be a great place to work!  And yes, it is possible!  We’ve seen it happen many times.

We hope to use this blog to share our experiences and insights on what it takes to transform an organization, including leadership, organizational structure, process, culture and technical skills.  Expect many blogs to share and test new and innovative ideas with you.  We hope you’ll comment one way or another.  Expect other blogs to share key learnings that every leader and change agent needs to know.  Expect some blogs to ask you questions and hopefully hear back a few answers and finally, expect a few to just keep you up to date with what’s going on with us lately. 

Our associates have decades of industry experience and have seen, heard and battled much in our professional lives.  Thought our experiences, we hope you will learn, grow and interact with us.   Feel free to post examples and pictures on topics that resonate with you or challenge us respectfully on those issues you don’t agree with so we can dialog about them.  Please let us know which topics would interest you and we’ll do our best to cover them.  Ask us questions you’d like us to answer and we will do our best to respond.  

You can follow AgileEthos on Twitter for tweets about new blogs, subscribe to the RSS feed or simply check back with us every 1 – 2 days for new posts.   Whichever way you follow, we’d like to hear from you.