Engineers write code.  QA tests that code.  In the past, this baton model has been derived from extensive functional specifications and use case documents that break down the core, extension, and exception cases so that both the tests and software can be clearly defined.  In a waterfall model, this was functional as it mirrored the sequence of SDLC.  But SCRUM and most Agile processes really shun this kind of thinking and instead target flat teams that collectively own the deliverable.  As in a recent experience of mine, maintaining that same handoff creates all sorts of problems.  Acceptance and rejection of delivered stories occurs late in the game, QA is always in a rush to execute their tests, and product teams and development see QA as a bottleneck.  It’s tempting for management to look at this and begin to turn SCRUM into a series of miniature waterfalls.  But this is wrong. Instead, as with all things in SCRUM, the search for a solution needs to answer a few questions to make the possible actions palatable:

1. Will the solution eliminate dependencies my team has?
2. Does this solution change the value that one set of skills adds to my team, or does it distribute it?
3. Will this solution be responsive to change?
4. Will this solution require extensive infrastructure to implement?

Heroes Kent Beck and Martin Fowler will tell you that the best solution is to strive for full, automated testing.  I couldn’t agree more.  Manual testing, as Fowler recently said, should be considered “a human rights violation.”  It’s error prone, difficult to repeat, and handles regression poorly.  That said, there are some battles simply not worth fighting.  In larger, more established teams – this type of shift is glacial, largely because of the risk incurred by such a change in paradigm.  Pragmatism dictates that the value of your QA team be repurposed to continue to add value, though potentially in a different way.

If we can concede the anecdotal thought that most engineers are substandard at QA, then we can see a glaring gap on a SCRUM team.  Even full automated testing with xUnits and CI is going to relinquish some level of code coverage, particularly in legacy software that wasn’t designed to be tested 10 years ago.  It should be mandated in teams in this type of pickle that all future code adopt the best practices of TDD – even to the extent that older, less TDD-friendly technologies and architectures be phased out.  But as we engage a group of engineers in a methodology in which they may never have been educated, hired, or trained for – on the sidelines we have a group of people who have been identifying failure and success scenarios their entire careers – even if they aren’t engineers.  A QA team can be indispensible in this situation.

In your new, SCRUM-based project – QA no longer are the gatekeepers.  We can’t have multiple gatekeepers in SCRUM.  Instead we focus on delivery and acceptance, creating one gatekeeper – a single keeper of the truth: the product owner.  That role is intended to be their exclusive domain.  They are the most intimate with the domain, the most intimate with the user story, and the most knowledgeable of where value lies.  To vest these judgmental by proxy in a serial part of the development cycle only leads to confusion.  Who is really assessing value?  Who is ultimately going to decide whether or not a story can be delivered?  Who should decide whether it should be accepted?  The demographics of a SCRUM project exist to solve this very question.  Eroding the clarity of role simply detracts value.

So what does this mean?  QA can’t be relegated to the role of testing system.  They cannot be an analogue for some sort of software framework.  Our goal should be to migrate to full automation, even if that takes time.  This means that the role of QA changes to an engineering role.  Not in the software sense, but in developing the cases which need to be tested.  These will arise from:

1. Conversational contributions to the story, noting and documenting constraints by guiding the product owner through different user experiences.  These can come out of user flows or non-functional prototypes.  But QA can add extensive value simply by contributing their ability to identify edge and corner cases that may not have been considered.  These may well not end up in our confirmation of the story, and it’s important for QA to recognize, just like with an engineer – that the value of a contribution in the conversation is to help shape the conversation, and not set requirements in the stead of the product owner.
2. Test cases derived from the constraints outlined in the conversation.  Take this user story:

   A user must be able to provide a credit card for payment of their order.  Each credit card must be validated with the issuer, and we will only accept credit cards from Visa and MasterCard.

   Try it with Discover card.
   Try it with American Express.
   Try it with an invalid billing address.

   This is the way that the product owner will ultimately accept the story.  The QA resource working on this story may write several test cases that test the edge and corner cases of the acceptance criteria, but they need to maintain an open conversation with the team to ensure they aren’t incidentally increasing scope by applying tests that go outside of the criteria.  So while the following test case is very likely to be something we’ll want to test:

   Try a billing address where the street name is provided in all capital letters but matches the address on file which is entirely in lower case.  This is expected to be a positive case, with the validation succeeding.

   This test would likely be considered an expansion of scope or otherwise invalid:

   Try charging the card and ensure that we put a $5 hold on the card until the transaction is complete.

So, in the cycle of the development of the story, the test cases serve as the outline for the engineer – as they should.  The engineer uses the tests to validate their code – or more effectively, runs their code against an automated test that implements the test case as defined by the QA specialist.  This helps improve quality and minimize risk by taking those decisions which we earlier agreed that engineers are poor at, out of their hands.  The test cases serve now as the same direction that the rest of the story does.  For those tests which remain manual for whatever reason, the effort to complete those tests can now be load balanced across the team, rather than vested in the hands of one point of failure in delivery.

Ultimately, this is what is so enjoyable about an Agile project.  Because it suggests solutions through it’s objectives, it’s possible to solve any execution concern by referring back to the principles that make Agile delivery successful.  Being able to respond to change, emphasize people and interactions, and prefer generalization over specialization is the guidance we can use to look at the role of the heroic QA team in a different light – a somewhat specialized engineering team that delivers artifacts that infuse delivery with the value that it may not be realizing in engineering, and not acting as a secondary source of truth for the team.

“I have been outsourcing and modifying an Open Source project. There is about 50-100hrs of scoped development. Let me know your availability and rate.”

Jobs like this one are poison that really puts all of the burden on your shoulders.  I’ve been a consultant for several firms, and have lead delivery of many large and small projects.  Here are a few tips to make it so that you maximize the shared risk in a project, maximize your revenue, and ensure the highest possible customer satisfaction.

Always Price on Your Own Estimates

You’re the one doing the work, and you know how long it might take you to complete a given project.  If a potential client hands you an amount of scope and a timeline (like the real-world example above), I would always request to assess the scope yourself and provide your own estimate before committing to anything.  If the prospect is amenable to this, then it serves you well to give them a good faith estimate and some solutions in the case that your estimate is different.  If the prospect is time sensitive, then work with them on adjusting the scope.  If the scope is driving the project, then encourage them to consider an additional investment of time to ensure the completion of the full scope.  Be willing to make concessions on your rate in these cases – flexibility from the client should be greeted mutually with your ability to discount your own rate.

If the client is not going to be flexible, then your best bet is to walk away or mitigate your risk through a more premium rate.  Likely even in the latter case, a less saavy contractor will underbid you and find themselves in trouble.  Better them than you.

Avoid Fixed Price/Fixed Time Projects

Clients love fixed price/fixed time projects.  It removes almost all of their risk in the project and places you in the position of likely pulling quite a few late nights and reducing your hourly rate.  Large consulting shops, particularly offshore ones – have the ability to enter into these arrangements and blend their rate accordingly to account for the need for additional resources in the case that the project falls behind schedule.  For them, the cost of working a project beyond the deadline is significantly higher than it is to simply add more horsepower.  Project management and technical oversight adds overhead in the project, and vendors are more than happy to not keep them on an engagement any longer than they need to.

That said, time and materials (hourly) arrangements are the best for the independent contractor.  They place all of the burden to manage scope upon the client, and the client has to trust the vendor to report hours accordingly and honestly.  Always aim for these projects, but do be honest with your client about hours and estimates around the cost of the engagement to them.  Be willing to discount when your estimates are inaccurate.

Another option is a middle ground called target cost, but these types of projects are typically the result of significant trust between client and vendor.  Simply put, you bill at your hourly rate for the agreed upon scope and any additional scope, and a discounted rate for defects and enhancements.  This typically keeps both parties honest.  Clients look to control scope for the same reasons they do in T&M, and it’s in your interest to finish on time as to avoid continuing work at a discounted rate (when you could be taking on new projects at your standard rate).

Request Right of First Refusal

Clients are fickle.  No matter how good your work is, when times are tight (as they are now), they will search for less expensive options.  Many times when negotiating with clients, I have asked for right of first refusal in whatever contract we agree to as to ensure exclusivity.  This makes you the preferred vendor and allows you to take all work that you are interested in before it is made available to competing contractors.  Often times, this will require that you discount your rate.  Additionally, this is usually only received well once you have established a track record of delivery with a client.  But if you can negotiate this clause, it can go a long way to ensure you a consistent revenue stream and source of work.

At the end of the day, your client’s satisfaction will be the best way to maintain business and build a stable relationship built on trust.  Be open and flexible, but protect your position and never take on more risk than is neccessary, regardless of how desperately you want to land a gig.