A new feature has been designed and developed, and has been submitted to Quality Assurance (QA) to be tested. Years ago, it was sometimes acceptable to simply “throw it over the wall” to be tested. Today’s software development processes that incorporate iteration and continuous feedback require a bit more than that. At a minimum, specifying Acceptance Criteria and How To QA in tickets that are given to QA are required for testers to be able to do their job.
For QA, Acceptance Criteria defines the scope of what is needed to be tested. It tells QA what is supposed to be tested, and what is not supposed to be tested. It describes what functionality is being implemented by the ticket. It describes any deviations in the current design. Let’s consider a ticket for a very simple new modal dialog in an application. Here’s an example of some straightforward Acceptance Criteria for a new modal dialog for an application:
Clearly an over-simplified example, but with this criteria, QA will need to verify that each of these items work. And here’s what these criteria tell me I DON’T need to test:
Those are pretty big items here that QA is going to ignore, but may be appropriate. Especially when a brand new app is being implemented.
This section has also been called How to Review, How to Test, and other names. It is a series of steps in order to check the implementation of a particular ticket. Using the example above, it might look like this:
And again, this is an over-simplified example. But QA needs a roadmap, especially for newly implemented features, and certainly for features that are especially complex. How do I get there from here? Navigation. The How To QA section answers that question.
But isn’t this all obvious?
Yes and no. There are some things QA needs, and some QA does not.
Over time, the right level of detail to give QA becomes much more obvious as the working relationship develops. When in doubt, include more and QA can instruct when to cut back.
A new feature has been designed and developed, and has been submitted to Quality Assurance (QA) to be tested. In olden times it was sometimes acceptable to simply “throw it over the wall” to be tested. Today’s software development processes that incorporate iteration and continuous feedback require a bit more than that. At a minimum, specifying Acceptance Criteria and How to QA in tickets that are given to QA are required for testers to do their job well. These should both be included in every ticket, every time.
As you can see, quality is a cornerstone of the work we do here at FullStack Labs. When working for a software development consultancy, having clear and concise communication from developers speeds up the testing process and helps to ensure high-quality solutions. If the topic of this blog post has piqued your interest, please feel free to contact us - we look forward to hearing from you!
We’d love to learn more about your project.
Engagements start at $50,000.