Tag Archives: relationships

Edible versions – Tips for implementation

Estimated Reading Time: 1 minute

So you read my Edible versions post and want to get the good stuff on how to make it happen in your organization. Well, to be honest, its not that difficult once all the parties sit together, talk about their expectations and design the protocols between the groups. See my earlier post for some general pointers.

Having said that – Maybe I CAN provide some tips that I saw working in the past:

  • Ensure all content in a delivery is tracked as a change request (bug/feature/other) in an issue tracker.
  • Provide an “Impact Level” for each change, so QA can easily focus on the high impact changes first.
  • For complex changes or large builds get used to hold delivery meetings where the DEV and QA discuss the changes and exchange ideas on how to proceed with covering this build. Be effective – know when the changes are small and the process can be lighter.
  • Try to establish an environment which automatically generates release notes for a version. At a minimum, as a report on whatever the issue tracker says. If possible, it should be based on actual deliveries to the SCM system. Use something like the integration between JIRA and Quickbuild/LuntBuild

Edible versions

Estimated Reading Time: 1 minute

All you QA people out there –

  • How often does your QA group “choke” on versions delivered by the development group?
  • Are you used to “unedible” versions which just don’t taste right?
  • How about versions which simply come as a blackbox where you have no idea what changed, therefore no idea what to do with the version, what to expect of it?

Now all of you DEV people – think about the times where you installed 3rd party products/updates which caused you the same digestion problems…

Those unedible deliveries cause a variety of problems. Lets start with the fact that whoever gets the delivery wastes a lost of time chewing it up, in the meantime not only delaying coverage of the new delivery but also NOT making progress on previous deliveries (the classic question of when to commit your QA organization to a new build delivered by R&D; and risk coverage progress for the earlier but known build. Especially tasteful when delivered to your plate a few hours before the weekend)

When the contents are unclear, QA people can only do general coverage, and the time it takes to verify regression concerns and make sure whatever we intended to fix was indeed fixed grows longer.

What is the point here? same as a sane person would refuse to swallow unmarked pills coming from unmarked bottles, refuse to take a version/build/delivery that is not documented sufficiently. I’m not aware of many good reasons not to mandate Internal release notes.

And DEV guys – consider some dogfooding on each delivery, even if its “just” to the friendly QA people next door. Lots of work you say? Well then, time to introduce Continuous Integration and Smoke Testing…

QA/DEV Protocols – Calling developers to the lab

Estimated Reading Time: 3 minutes

I’m going to dedicate a couple of posts to the relationships between QA and Development (DEV) organizations.

Anyone who’s ever been in either of those organizations knows that sometimes there seems to be a conflict of interest between QA and DEV, which can lead to friction between the groups and the people. Obviously when both organizations are running under the same roof, there must be some joint interest/goal, but the challenge is to identify the expectations of each group in order to work toward their goal and accomplish their mission effectively.

The difficult cases are those that put more strain on one party, in order to optimize the effectiveness of another. Example – developers are asked to unit/integrate/system test their software before handing over a build to QA. Some developers might say that this is work that can be done by QA, and their time is better spent developing software. The QA engineers will say that they need to recieve stable input from the DEVs in order to streamline the coverage progression, and that the sooner issues are found, the lower the cost to fix them.

One way to look at these “protocols” between the groups is via the glasses of TOC (Theory of Constraints), identify the bottlenecks of the overall system/process, and fine-tune the protocol to relieve the bottleneck. People in those groups, and especially the leaders, should be mature enough to know that sometimes doing the “right thing” might be to take on more work, sometimes even not native work for their group.

One example is the issue of when to ask DEV guys to see problems the QA engineers have discovered.
Reasons for calling DEV might be:

  • Wish to reopen a bug
  • Bug was reproduced and a developer was interested to see the reproduction.
  • New severe bug

There are a couple of forces affecting this issue:

  • QA wishes to finish the context of the specific problem/defect, open the bug, and get on with their work.
  • DEV wishes to finish the context of their specific task, and wish to avoid the “context switch” of looking at the QA issue.
  • In general, both QA and DEV have learned to wave the “Context Switching Overhead” flag quite effectively. (A more pragmatic conclusion is that some context switching overhead is unavoidable, and sometimes the alternative is more expensive…)
  • In some cases, “saving” the state of the problem for asynchronous later processing by DEV is difficult or takes too many resources to be a practical alternative.

A possible compromise between all those forces is to define some sort of SLA between the groups, stating the expected service provided by DEV to QA according to the specific situation (Reopen, Reproduced, New Severe, etc.). This SLA can provide QA a scope of time they can expect answers in, without feeling they are asking for personal favours or “bothering” the DEVs. The developers get some reasonable time to finish up the context they were in without feeling they are “avoiding” QA. The SLA can also cover the expected actions to be taken by QA before calling in the DEV, or in parallel to waiting for them. This maximizes the effectiveness of the DEV person when he does free up for looking at the issue, while better utilizing the time of the QA while waiting. (for example – fill the bug description, look for existing similar bugs, provide the connectivity information into the test environment, log excerpts/screenshots, etc.)

Another question is who to call on when QA needs help. The options here depend on the way the DEV group/teams share responsibility on the different modules of the system.

  • In case there are strict “owners” for each module, and they are the only ones capable of effectively assisting QA, the only reasonable choice is to call on them… this requires everyone to always be available at some level.
    I have to say though that I strongly advise against such an ownership mode. Look at code stewardship for a better alternative (in my oppinion) and see below how it looks better for this use case and in general…
  • In case there is a group of people that can look at each issue, one alternative is to have an “on call” cycle where people know they have QA duty for a day/week. In this case there will be issues which will require some learning on their part, and perhaps assistance from the expert on a specific area. This incurs overhead, but is worth its price in gold, when the time comes and you need to support that area in real time, need to send the DEVs to the field to survive on their own, or when the owner/expert moves on…

To sum up, like in many h2h (human-to-human) protocols, understanding the forces affecting both sides of the transaction is key to create a win-win solution. A pragmatic view trying to minimize the prices paid and showing the advantages of the solution to both sides and to the overall organization can solve some hard problems, as long as people are willing to openly discuss their issues and differences. I’ve seen this work in my organization, hopefully it helps others as well.