One Team - Developers and QA

All too often, it seems natural causes encourage an antagonistic or "us" vs "them" relationship between traditional development and QA teams. This is quite unfortunate, in that the roles and responsibilities of these groups can and should present a much more symbiotic relationship. It's good news that the Agile movement is beginning to break down barriers and encourage more cooperation and team work.

Even in environments that cling to more traditional software methods, however, there is significant opportunity to produce better software more quickly and efficiently by encouraging tighter collaboration between these disciplines. Let's consider just two of these techniques with hopes of compelling additional creative energy.

The two techniques I'd like to call out are in the area of automated unit testing. Unit testing is, of course, a topic worthy of its own treatment, so we'll save the nitty-gritty for another day and just hit the relevant highlights now. In this focus on unit testing, I'll make the case that Developers need their QA partners and QA needs Developers. Specifically, Developers won't produce the most effective unit testing capabilities without participation from QA, and QA won't provide the most valuable assessment of product quality without participating in the creation of a unit testing capability and fully leveraging the capability in the overall assessment strategy.

First, let's look at the necessity of unit testing in the Development group. All too often, I'm asked questions such as, "Isn't it QA's job to do the testing," or "How can Development afford the time to write all those tests." Once you take this apart a little, you find that Development MUST create "all those tests" - its critical to their success. As I mentioned earlier, we'll talk more about the breadth and depth of unit testing another time. For right now, I hope one straightforward concept will drive this point home. I always respond by politely asking someone to explain how, absent automated unit tests, the Developer knows when the task is complete. I won't belabor this point, but consider how to respond to the question "How does the developer know he's done coding?" Invariably, the answer reflects the necessity that the developer do some degree of testing to ensure their work is behaving as expected. Unfortunately, this testing is all too often done in a completely ad hoc fashion, requiring spontaneous development of test cases and supporting test data. In this effort, corner cases are missed, forgotten business requirements are overlooked, important code paths are bypassed, etc. And let's not forget this work is often repeated from scratch the next time someone goes in to modify the same code, thus wasting effort and repeating the same mistakes. I'll assert that the developer only knows when he's done when all his tests pass... when the light is green.

So, if these automated unit tests are a requirement, and the developer doesn't know he's done until they all pass, how does he ensure the tests are produced reliably and efficiently? They must be produced as part of product delivery. They must be written along side the product code - developed just as the product itself is developed. The developer must write the tests and keep them up to date every time the code changes. When a new bug is found, the tests must be updated so the developer can always rely on the "green light" representing success... representing a completed task. But, here's where we get into a little trouble. How good are Developers at recognizing potential problems or identifying failure scenarios? Granted, there are plenty of exceptions, but generally speaking the QA minds are much more adept at this sort of thing than the Developer minds. By engaging QA in the definition of the automated unit tests, Developers produce much more thorough and effective unit tests and come closer to the goal of the unit testing capability - completely surrounding every component with automated unit tests that immediately, consistently, and efficiently validate component behavior... and let the Developer know when he's done!

But the Developer is not the only one that gets something out of this. As I have the pleasure of doing training for various audiences, including those from the QA profession, I will frequently ask the question, "Do you in QA test every possible scenario or code path before releasing a software product?" These smart folks always immediately answer with something like, "Of course not!" As we know, an effective QA strategy involves careful risk assessment and prioritization of testing efforts to ensure focus and energy on the product areas most likely to introduce defects and those where defects would lead to the most severe impact. So here's where we get to the "symbiotic" part of the relationship. While QA involvement in the test development helped improve the unit test effectiveness leading to better code output (QA helped the Developer), now the awareness of test coverage represented by the automated unit tests leads directly to better risk assessment and an ability for the QA team to focus their energy on higher-value activities associated with overall product quality assessment (Developers helped QA). By working on bigger picture, value-add assessment activities, the QA team is able to ensure higher overall product quality.

In this straightforward scenario, we see two disciplines cooperating with one another - working as ONE TEAM. Each discipline contributes their unique strengths, resulting in higher quality software delivered more reliably and more efficiently.

Projectecture

Seems like every time I turned around today, I was reminded of the close tie between the role of the Project Manager and that of the Architect. Not just the obvious and important relationship and dependencies between these roles in project work, but also the similarity in characteristics of the roles themselves.

In fact, as I think about it, I'm inclined to distill it down to a single characteristic that is universally present in the most effective practitioners of these distinct disciplines. When I think about the "A-Team" of Project Managers and Architects I've been fortunate enough to work with over the last couple decades, and consider the brilliant successes I've witnessed from each of them, a common theme seems to percolate. Example after example come to mind where vast confusion, ambiguity, and amorphous objectives were quickly digested, translated, and modeled in some way as to bring clarity, structure, and focus to the masses. In order to rapidly coalesce information into a meaningful form, these capable folks routinely recognize the patterns, consistencies, relationships, and key/distinct characteristics of the topic at hand and almost instinctively harvest the true essence of the concern.

In their book "Now Discover Your Strengths", Marcus Buckingham and Donald O. Clifton call this the Strategic strength and describe it this way... "People strong in the Strategic theme create alternative ways to proceed. Faced with any given scenario, they can quickly spot the relevant patterns and issues." (http://www.amazon.com/Discover-Your-Strengths-Marcus-Buckingham/dp/0743201140)

Whether Project Manager or Architect (each with their individual interests and scope of influence), people who can "quickly spot the relevant patterns and issues" are frequently the key difference between glowing success and less favorable results - in the most extreme cases, project failure. I make it a point to surround myself with a good dose of "Strategic" people.

Recipe for Guaranteed Disaster

Perusing the SEI Architecture site today (http://www.sei.cmu.edu/architecture) and stumbled into an essay that I found interesting. But along the way, also snagged the following quote that seemed to aggregate several important aspects of our discipline:

"Software architecture forms the backbone for any successful software-intensive system. An architecture is the primary carrier of a software system's quality attributes such as performance or reliability. The right architecture - correctly designed to meet its quality attribute requirements, clearly documented, and conscientiously evaluated - is the linchpin for software project success. The wrong one is a recipe for guaranteed disaster."

Now let's get cooking... onto the essay...

"Architecture Paradox", by Dr. Subrahmanyam Allamaraju, gives a fascinating treatment of the discipline of software architecture and the conflicting forces that architects naturally attempt to balance (http://www.sei.cmu.edu/architecture/essays.html#paradox).

"The purpose of this article is to discuss "Architecture Paradox" and bring out the conflicting forces that influence the architecture over the life-time of software products and applications. This paper also presents some early ideas on how to build software systems that defy the architecture paradox."

Dr. Allamaraju goes on to setup a stark competition between Survival vs Evolution in the architecture of a typical software-intensive system and goes right at the question, "Why is it difficult to protect software architectures?" The answer, he asserts, lies in several universal principles/practices...

"How to build resilient architectures that are not trapped in the architecture paradox? The answer may be summarized in four points:

1. A software system can defy the architecture paradox, only if the structure of the software can accommodate changes.
2. Since anticipated changes are not to be implemented in the software right away, it is necessary to abstract these as a set of architecture goals.
3. To realize these goals, it is necessary to devise a set of principles.
4. To remove the human factor in enforcing these principles, integrate the principles into the architecture, such that the architecture poses the necessary constraints to protect itself."
   

And then the kicker...

"It is necessary to reemphasize that this is a creative activity and can not be driven by any process."

Architecture... The Art of Engineering.

World Tour 2007

Just returning from the great World Tour 2007. This adventure took me and my good friend Mike Cottmeyer out to India to visit our Infosys partners and provide a few days of training on the Rational Unified Process. On the way back, our wives joined us in London where we enjoyed kicking back and wandering aimlessly in London and Paris for more than a week. We tried our best to leave everything in Europe just as we found it... but I make no promises ;-)