Coping with Quality Assurance Issues
Costa Rica is becoming the haven for agency-like companies. We have very talented creatives, front-end developers along with highly skilled back-end developers. This talent, along with other attractive traits this small country offers, makes many U.S. agencies to outsource their entire development effort to Costa Rica.
In this post I want to present some challenges that affect the software development life cycle in agency like companies in general. I’ll also present some action items that can be followed in order to start overcoming those challenges.
The root of the following challenges may be a bad approach to the quality assurance put in place, if any.
Requirement specifications nightmare
Quality is measurable compliance of what is specified in what is delivered. To have a clear understanding of what the client wants, we can use some traditional artifacts to specify requirements visually: Wireframes and Visual Design Guides.
There are pros and cons about their use, but let’s assume you use them to specify User Stories.
The most commons problems I’ve seen in many companies using this approach are:
- There is not a behavior-focused artifact for specifying requirements. Developers’ assumptions regarding workflow aspects inevitably creep in. This is a Quality hole.
- No visual specification artifact gets its sign-off from client before development starts mainly because the client has a lot of unprioritized requirements, and wants wireframes for all of them. Each wireframe follows an endless cycle of review and reword. Because the clock is clicking, developers commit to unclear requirements whose specifications change while it is developed. Developers never get sure of what the client really wants. The Development Team is penalized for this delay. [Bottlenecks in the value stream: 1) Too many kanban cards in the same stage, 2) a kanban card moves to next stage without being ready for that]
Quality Assurance pays the consequences
The biggest mistake I see is confusing Quality Control with Quality Assurance. Many companies only do Quality Control, and some do it poorly:
- Control quality of new features is unintentional: There is no any track system of new features to test and to add to the regression test pool. Every time estimates are given for new features, the final control quality effort is not analyzed; instead, an arbitrary constant amount of time for QA is assumed.
- Test cases a not automated at all: It takes several days to execute a full regression test.
- There is no explicit limit in the capacity to solve ongoing client bugs along the Sprints. There is not a well-known agreement on how many bugs can be solved weekly. Not setting this limit kills predictability and cadence in the overall quality control workflow.
- The testing team feels forced leave behind the essential part of “Quality Assurance”, focused entirely in quality control and not doing preventing tasks like helping to create and automate up-front Acceptance tests for developers.
- If the client has a testing team to certify that what is delivered is what was asked, against what are they certifying quality? Are they using the same artifacts that development is using to create the new functionality?
Suggested Action Items that have worked for me
- Set a Work In Progress Limit to the specification stage, focusing in finishing (I mean: getting sign-off from client) one specification artifact at a time. Only completed wireframes and visual designs guides set the signal for starting the development stage. Prioritize knowing your Work in Progress Limit!!
- Use a BDD tool for specification of application features and user scenarios like Cucumber, which has the happy nature of being potentially executable.
- Include testing effort in future estimates for new functionality.
- Set an upper limit to client bug management effort.
- Deliver to client the specification artifacts that the development team used to create the new functionality.
- Start efforts in automating some parts of the regression test, a good way to start is create and support the execution of Cucumber specs.
Some extra advice
Do a constant and merciless hunting of bottlenecks in your value stream.
Put your foot down and say: “We can’t start developing User Stories if they are not fully understood and agreed by every party”.
Avoid Analysis Paralysis: You don’t need have to have fully specified every User Story in the Product Backlog; you only need such detail for the User Stories to be implemented in the next Sprint. Acknowledge the fact that the rest of the Product Backlog will inevitably change, so don’t waste time in defining details that will be thrown away.
Specification artifacts are conversation enablers, not conversation substitutes. Keep talking with your client to refine and handle unexpected details that will appear during Sprint.
Quality Assurance is a team responsibility; the major merit of it is preventing bugs.
Watch closely your code quality through Sprints.
People who looked at this item also looked at…
Related items
posted in estimation, Quality, Sprints |
