May 30

Developer Communication (picture depicts two programmers discussing information in an office)

5 Reasons Developers Shouldn’t Be Blamed for Bugs

When problems appear in an app or website, for some people the first move is to blame the developer(s). Sure, it’s true that the developers wrote the code. But the reality is that bugs are rarely the fault of any one person or group. There are many reasons why developers shouldn’t always be blamed for bugs. A developer’s build could have a bug for many different reasons, including:

Vague or incomplete acceptance criteria
A regression (when a fix or new feature causes problems with older code – learn more in our guide to regression testing)
Issues with specific devices or browsers based on new updates (learn more about cross browser testing)
Rushed timelines in an Agile process

Between these explanations and the reasons below, it’s a good idea to think twice before defaulting blame to developers.

Why Developers Shouldn’t Always Be Blamed for Bugs

1. It’s counter-productive.

Adding extra pressure is only going to make bugs more likely, as insecurity and nervousness interfere with focus. Of course, having some level of accountability is usually helpful (and reasonable). But there’s a difference between asking someone why certain bugs made it through vs. interrogating them with negative assumptions. Continue reading →

Apr 21

Wes Silverstein

Featured / QA Process

Jira QA Workflow and Best Practices

SDLC Planning (ticket racking board with three people holding cards up against it)

Jira QA Workflow and Best Practices

When starting a new software development project, many companies choose to use Jira as their project tracking tool. If you’re reading this, chances are you’re familiar with it. While Jira can be a helpful tool for tracking progress, it’s beneficial to have best practices in place to pack the most punch. Find out how to optimize your Jira QA workflow below.

Jira QA Workflow

Jira board column types aren’t a one-size-fits-all approach. Different teams might find that different conventions work for them. (To learn more, see our article on the Agile QA process.) However, the options below show the typical range of columns followed in almost any Jira testing workflow.

Here are some examples of Jira columns:

Group 1 – the “All the Columns!” Approach

Backlog / Ready for Development / In Progress / Ready for Staging / Ready for Testing / In Testing / Reopened / Ready for Production / On Production / Testing on Production / Done

Group 2 – the Basic Approach

New / In Progress / Ready for Testing / Done

As long as each column serves an effective purpose, it’s often helpful to lean towards the side of more columns. The more specific each column is, the easier it is for anyone on the team to immediately get a high-level status report with a quick glance at the Kanban board.

If you compare the groups above, you can see how the options in Group 1 provide a much clearer view into how far along a task is, versus the more bare bones approach of Group 2.

While it may seem overwhelming, it’s helpful to remember that tickets can be moved between columns with a quick drag of the mouse. As long as the team is disciplined about updating ticket statuses, detailed columns can be a huge asset to your Jira QA process.

Continue reading →

Apr 8

Wes Silverstein

About Mindful QA

Mindful QA Joins the Carbon Neutral Business Movement

Carbon Neutral Business (cartoon showing a giant sun with clouds and leaves behind it, and solar panels in front of it. Crtoon men and women in business casual are talking in front of the solar panels and pointing at the sun)

Mindful QA Joins the Carbon Neutral Business Movement

We’re excited to announce that Mindful QA is officially a carbon neutral business! We purchased carbon offsets to balance our expected annual carbon emissions (and a little extra, to be safe).

In case you’re interested, we thought we’d share some details below about what carbon offsets are. We’ve also included information on how you can become a carbon neutral business, or buy carbon offset credits for yourself as an individual.

Why Did Mindful QA Decide to Become a Carbon Neutral Business?

When we started Mindful QA, we knew we wanted our business to be a force for good as much as possible. While companies exist to make money, we believe there’s room for spreading good along the way.

How Can Businesses Reduce Their Carbon Footprint?

Luckily, there are many options for businesses to be more environmentally friendly! If you’re curious, here are some of the other actions a business can take to help (or at least avoid harming) the environment:

Letting your staff work from home. Okay, so this is considered a pretty big ask by many companies. We get it. But if you have reliable, communicative workers, productivity can be even higher than in an office. (See our article on 10 Advantages of Hiring Remote Workers.) With tools like Slack and Zoom, it can feel like your workers are within 100 feet even if they’re really 1,000 miles away. And avoiding commute-related pollution can make a huge dent in your business’s carbon footprint.
Getting energy-efficient web servers. Data centers now cause even more greenhouse gas emissions than airplanes. If you have your own data center, you can read some tips on making it more eco-friendly here. Otherwise, you can research web hosts that offer greener server options and see what feels right for you.
Conserving electricity in the office. There are many little (and big) things you can do to reduce your office’s electricity use. For example, this comprehensive list offers dozens of options. On top of being better for the environment, making some of these changes will also save you money!
Donating to environmental organizations. We donate 10% of our profits to non-profits and causes, including organizations focused on environmental conservation.

What Are Carbon Offsets?

Carbon offsets go towards projects that reduce greenhouse gas emissions. Continue reading →

Jan 22

Wes Silverstein

QA Engineering

What is User Experience?

What is User Experience?

User experience. You’ve probably heard the term many times, but it’s often used in different ways. Whether you’ve worked in tech for 20 years or just downloaded your first mobile app, user experience (or “UX”) can have a big impact on your day-to-day life. Let’s talk about what exactly “user experience” is, with some real world examples.

What is user experience? It’s actually pretty simple:

The overall experience of a person using a website or app, especially in terms of how easy or pleasing it is to use.

As you may have guessed, some aspects of user experience can be subjective. Maybe you think hamburger menu icons are elegant and helpful, while others find them inconvenient. Perhaps you find it annoying when sites require complex passwords, while others might appreciate the added security. Continue reading →

Dec 18

Wes Silverstein

QA Engineering / QA Process

Best Practices for QA Testing

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 a while (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 →

Nov 30

Wes Silverstein

QA Process

7 Traits You Need to Work From Home

7 Traits You Need to Work From Home

Not everyone wants to work from home. Some prefer to work in an office, surrounded by coworkers. (Extroverts, anyone?) But many people do their best work from home, or would like to give remote work a go. Do you have the right set of skills and home environment to excel at telecommuting? Find out if you have the traits you need to work from home.

What Traits Do You Need to Work From Home?

1. Being a self-starter. When you’re the only one in your “office,” you’re in charge of time management. Managers can still have a high degree of oversight via Slack, emails, and calls, but it’s up to you to supply the motivation for jumping into the right task at the right time.

2. Communication skills. Further, proactive communication skills, and knowing how to find the right balance. When you work remotely, communication is more important than ever. While everyone needs some “heads down” time to focus on getting work done, it’s important for clients and coworkers to be able to reach you in a timely manner.

It’s also important for you, as the remote worker, to proactively provide updates. You’ll want to take into account the needs of your client or company culture and adjust messaging accordingly. When you have a well-oiled process, it can be just as – if not more – smooth as an on-site team. Out of all the traits you need to work from home, communication is at the top of the list. Continue reading →

Nov 30

Wes Silverstein

QA Engineering / QA Process

What Are QA Test Cases?

What Are QA Test Cases?

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:

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.
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 →

Nov 15

Wes Silverstein

Company Culture

Mindful QA Joins the Business for Trans Equality Statement

Business for Trans Equality Statement (image shows transgender pride flag)

Mindful QA Joins the Business for Trans Equality Statement

We’re proud to announce that we’ve joined companies like Apple and Lyft in cosigning the Business Statement for Transgender Equality. We support trans people, in or out of the workplace, and believe in increasing diversity in tech. Read on to see the full Business for Trans Equality statement. (You can also view the official website here.)

The undersigned businesses stand with the millions of people in America who identify as transgender or gender non-binary, or who are intersex, and call for all such people to be treated with the respect and dignity everyone deserves.

We oppose any administrative and legislative efforts to erase transgender protections through reinterpretation of existing laws and regulations. We also fundamentally oppose any policy or regulation that violates the privacy rights of those who are transgender, non-binary, or intersex.

In the last two decades, dozens of federal courts have affirmed the rights and identities of transgender people.

Cognizant of growing medical and scientific consensus, courts have recognized that policies that force people into a binary gender definition determined by birth anatomy fail to reflect the complex realities of gender identity and human biology.

Diversity and inclusion are good for business, and that discrimination imposes enormous productivity costs (and exerts undue burdens). As a result, hundreds of companies, including the undersigned, have continued to expand inclusion for transgender people across corporate America. Currently more than 80 percent of the Fortune 500 have clear gender identity protections. In addition, two-thirds have transgender-inclusive healthcare coverage. Hundreds also have LGBTQ+ and Allies business resource groups and internal training efforts.

Transgender, gender non-binary, and intersex people are our beloved family members and friends, and our valued team members. What harms them harms our companies.

We call for respect and transparency in policy-making, and for equality under the law for transgender, gender non-binary, and intersex people.

Continue reading →

Nov 13

Wes Silverstein

Automated Testing / Manual Testing / QA Engineering / QA Process

Manual Testing vs. Automated Testing

Manual Testing vs. Automated Testing

For the field of software testing, manual testing vs. automated testing has become a hot debate. In recent years, automated testing has become more and more in demand. In fact, a quick search of QA jobs on sites like Indeed, LinkedIn, etc. will show that the majority of these jobs now require automation experience with a language like Java, Python, etc.

This can prove daunting for testers with a background in manual testing, who typically leave the coding to developers. It can also be confusing to employers. Many managers aren’t sure how much automated testing they need, and whether it can replace manual testing completely.

Some companies use 100% manual testing to great success. Others have attempted to do 100% automation, and had to re-think their strategy — so the reality isn’t always as black and white as it may appear.

The ideal combination is having both manual and automated testing. The amount of each depends on your exact product/service and what your company’s Agile QA process is like. For example, if you’re constantly adding new features, you’ll need very rigorous manual testers. Of course, ideally you’ll also have automated regression tests set up, to make sure that the new features being introduced aren’t breaking old features. Even choosing 5 test cases to automate can make a big difference. Continue reading →

Oct 28

Wes Silverstein

QA Engineering / QA Process

QA Testing Estimation Techniques

QA Testing Estimation Techniques

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 →