Acceptance Criteria and How to QA

Written by
Last updated on:
October 1, 2025
Written by
Last updated on:
October 1, 2025

Why are Acceptance Criteria and How-to-QA sections of a Jira ticket important to Quality Assurance?

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:

  • Any links, menus, input boxes, or controls are functional.
  • This modal must match an existing design.
  • Whether or not this modal makes any changes in the application.

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.

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!

Learn more

Frequently Asked Questions

Acceptance criteria define the scope of what needs to be tested in a feature or ticket. They describe the expected functionality, design considerations, and any specific deviations from the current implementation. For example, in a ticket for a new modal, acceptance criteria might include verifying keyboard focus, ensuring the modal closes properly, and confirming it works across all supported browsers and screen resolutions.

‍

Acceptance criteria give QA engineers clear guidelines on what to test and what to ignore. Without them, testers risk spending time on irrelevant functionality or missing critical requirements. Well-written criteria help QA focus on validating the correct behavior of a feature, improving both testing efficiency and product quality.

The “How to QA” section provides a step-by-step roadmap for testing a feature. It includes instructions on navigating the application and verifying functionality, especially for new or complex features. For example, it might specify how to open the app with a special model, which button to click, or what data to input. Without these details, QA may miss important paths or test the feature incorrectly.

It depends on the complexity of the feature. Standard, intuitive workflows usually don’t need extensive explanations—QA can handle familiar paths without detailed guidance. However, for features involving special conditions, like region-based tax calculations, shipping differences, or alternate URLs, you should include specific instructions. When in doubt, provide more detail, and QA can decide if simplification is appropriate.

Including both sections in every ticket creates clear communication between developers and QA engineers. It ensures everyone understands the intended functionality, reduces back-and-forth questions, speeds up testing, and improves the overall quality of the product. Over time, this leads to a more efficient workflow and stronger alignment between development and testing teams.