Acceptance Criteria and How to QA

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!