“User acceptance testing” can have several meanings. There’s the technical definition – and then there’s the way that the phrase is commonly used. But when teams use the same term to refer to different processes, things can get confusing.

Fortunately, both types of user acceptance testing are pretty simple to understand. They also have aspects in common, including many of the same goals.

What is User Acceptance Testing?

User acceptance testing verifies that the software’s user experience is acceptable for launch. Also known as UAT, it’s part of every website or app QA process in some way, shape, or form. However, there are a few different ways of doing it. The biggest difference? Whether the UAT is done by professional QA testers or real customers. Continue reading →

When working in Agile software development, you’ll often see references to acceptance criteria. While the phrase may sound unnecessarily confusing, it’s actually pretty simple. And while not every team uses it, it can be crucial to a successful launch. So what is acceptance criteria?

Acceptance Criteria Definition

The technical definition of acceptance criteria is, “the conditions that a software product must satisfy to be accepted by a user, customer, or in the case of system level functionality, the consuming system.“

Put more simply, acceptance criteria is a list of details (also known as requirements) about how a new software feature should work/look. This ensures that:

• The feature is designed well. Otherwise, an important or helpful aspect might be left out – without anyone noticing until the very end.
• It works the way it was intended. If the description is vague, developers might have to make assumptions about how each area should work. With acceptance criteria, developers know exactly what design and functionality is expected.
• QA knows what to expect during testing. Even if a feature doesn’t feel broken, it might not work the way the product managers wanted it to. If there’s no acceptance criteria, testers can’t report these kinds of issues.

Continue reading →

If you work in or with QA, you’ve likely heard the phrase “regression testing.” For most apps and websites, regression testing is done before every new release. In an Agile QA process, it’s a regular part of the QA testing vocabulary. But what is regression testing, and how do you do it?

The Definition of Regression Testing

To put it simply, regression testing means testing virtually everything in the software. Not just a new feature, and not just each general section – but every button, flow, and interaction in the app or website.

The official definition of the word “regression” is:

a return to a former or less developed state

In software, a “regression” is a bug in an area of the app or website that was previously working. Continue reading →

QA testing can be confusing to anyone who doesn’t work in tech – and even many who do. For those who are unaware of what QA testing entails, the vague concept might be “looking for problems in a website or app.” But there are many different phases of QA testing. Some of them happen before a product is even ready to test!

Read on to find out more about the different phases of manual QA testing.

The Design Phase

One of the first steps that QA can help with is the design phase. This might seem surprising, as QA testers aren’t exactly known for being graphic designers. But testers can provide valuable insight into user experience issues with design.

If QA can anticipate design and user interface issues before development begins, the team will save money, time, and effort. Continue reading →