Acceptance Criteria and How to QA (2024)

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.

Acceptance Criteria

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:

Mouse and keyboard input must be focused on the modal.
Closing the modal must function the same as cancel.
Window underneath the modal must look disabled.
Modal must be visible in all screen resolutions in all supported browser/OS combinations.

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:

How to QA

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:

Open the application.
In the first window, press the button in the center, marked Foo.

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.

Doesn’t Need:

Open the app and go through the first 6 windows the same way like you have for the past 6 months - this is understood already
Making sure Quantity times Price equals Total - this is a standard calculation and is pretty intuitive, so shouldn’t be necessary

Needs:

Open the app with this special model, preview, different URL, etc. - this is specific to testing the solution provided by the development work
Taxable Quantity times Price times Tax (which is different based on region) equals Total, plus Shipping (which may or may not be the same region as billing, but will differ based on region) - this is much more nuanced than the earlier, similar example

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!