Best practices for QA testing can be a lot to take in. There are bug reports, test cases, and many other steps involved for both manual testing and automated testing. Anyone who’s been in the QA field for awhile (or Engineering in general!) is familiar with the Agile QA process in software development.

However, it’s always a good idea to review best practices for QA Testing, whether you’re on day one or year ten of a QA career. Some of these tips may sound obvious, but others just might help you up your game.

Document Everything

Screenshots, video grabs, version info, and communication in general. If a picture is worth a thousand words, a screenshot is worth avoiding a thousand back-and-forth questions about a bug that a developer isn’t able to reproduce. If you can get a video showing the flow of the behavior, that’s even better.

It’s also important to proactively include info about the software version/OS/etc. For example, if you’re reporting a bug with a mobile app, instead of just saying “it’s happening on Android,” you can include the build version, Android OS version, type of Android device, and more. If you have time to go back and check the previous build, that’s helpful as well. Continue reading →

When getting started with any type of QA testing, it’s always helpful to have test cases. But what are QA test cases, and why are they important? Read on to learn how they work, and how to write test cases.

What Should A Test Case Contain?

Well written test cases should contain the following aspects:

• Title or ID (ie: “LOG-1”)
• An association with a section of the site/app (ie: “Login”)
• Notes on any setup needed (for example, “access to a staging build” or “admin credentials”)
• Steps to follow to perform the test
• Expected results

Why Are Test Cases Important?

Having a suite of test cases makes the whole Agile QA process more efficient. In fact, test cases can even show new colleagues how the app or site is supposed to work — right down to the smallest details.

Most importantly, having test cases that all team members can review ensures two crucial details:

1. There are no gaps in test coverage. Let’s say that QA hasn’t been informed about a particular feature or requirement. By reviewing test cases, other team members can immediately determine if there’s missing test coverage.
2. Everyone is on the same page. Sometimes there are misunderstandings about how a feature is supposed to work. Any misconceptions can be identified faster and more easily when a developer or product manager can review test cases. Continue reading →

QA estimates are an important part of the Agile software development life cycle. Without reliable QA testing estimation techniques, there’s no way to know which features will fit into a release timeline.

As a result, it’s nearly impossible to have a successful sprint without estimates. And while many people think of estimates as something that only developers provide, it’s crucial to get estimates from the QA team as well.

QA Testing Estimation Techniques

When getting started, it can be difficult to get the hang of estimates. Many new QA testers wonder how they can possibly guess the number of hours ahead of time. Fortunately, a handful of pretty simple factors can help you get the hang of providing QA estimates.

Some aspects to consider when working on QA estimates include:

• The reliability of the team’s Agile process
• The skill of the developer(s)
• Devices that need testing
• The complexity of the feature or bug fix

QA Estimation Techniques in Agile

QA vs. Dev Estimates

Some companies use a set method for QA estimates. One example of this is using a percentage of the developers’ estimates. For example, let’s say that engineers estimate 40 hours to complete a given feature. If a company used the above strategy, with 25% for QA, they would automatically enter a QA estimate of 10 hours.

While it’s a popular strategy, this “one size fits all” approach can cause problems. In practice, it often results in teams over-promising and under-delivering on quality. Getting custom estimates directly from QA testers can be the difference between a late, buggy version and a successful release.

Do the Jira Stories Have What You Need for QA Estimates?

In order to give a good estimate, QA needs to know the details of the feature being developed. A vague overview won’t usually provide enough information for a good estimate. As a general rule of thumb, acceptance criteria should always be provided. QA should also feel empowered to ask clarifying questions and offer suggestions on user experience.

For example, say there’s a new video player being developed. Imagine the user story including details like “closed captioning, allowing users to save where they left off, next/previous buttons,” etc. With this information, QA would be able to give a much more accurate estimate than if the ticket simply said “video player.”

To learn more about optimizing Jira for QA, see our article on the Jira QA Workflow and Best Practices.
Continue reading →