Working With Your Product Owner

I didn’t understand the importance of Product Owners until I created my own web app. It was such a simple app (you can see it at https://thinking-tester-contact-list.herokuapp.com), but I had to figure out how to get from one page to another, and how to make sure a user never gets stuck at a dead end. This was harder than I thought it would be. Then I understood that the work that Product Owners do is about more than just designing pages! It’s about making sure that the user has a great experience doing what they need to do in your application.

Testers share the desire of making users happy, so it’s a great idea for them to work with Product Owners to achieve that goal! Below are four steps for working with your Product Owner.

Step One: Attend planning meetings
I will freely admit that planning meetings are not my favorite meetings. I like to have a list of things to do and attack that list, and often planning meetings are a free-form exchange of ideas. But it’s important to attend these meetings, because seeing new features take shape can get you started with thinking how to test them. Also, because you interact with your application so often, you may have more knowledge about its features than your Product Owner does, especially if they are new to your company. You can use that knowledge to point out potential problems with a plan. For example, at one company where I worked the Product Owner and developers were redesigning their reporting tool. During a planning meeting I was able to remind the group that the tool needed to work with an existing assignment engine.

Step Two: Have 3 Amigos meetings
A 3 Amigos meeting is a meeting with you, a developer on your team, and your Product Owner. This is where discussions take place about how the feature will be built and what the Acceptance Criteria will be. You are critical to this meeting because you will be able to ask questions about how the feature will work that the Product Owner and the developer might not have thought of. You can also help write the Acceptance Criteria to reflect important negative cases. For example, if your team is building a new SMS feature, you could suggest that one of the Acceptance Criteria should be that the system handles cases where the user hasn’t added a phone number.

Step Three: Test above and beyond the Acceptance Criteria
Even though you helped create the Acceptance Criteria, there are probably many more things to test beyond those AC! You’ll want to test on a variety of different browsers and devices, you’ll want to test how the new feature works with other features, and you’ll want to discover what happens in rare edge cases, such as clicking the back button several times or losing your internet connection during a transaction. When you discover anything that could be a potential problem, discuss it with both the developer and the Product Owner to see if it’s important to fix before the release.

Step Four: Have your Product Owner do Acceptance Testing
You’ve now tested the feature extensively, and you’re feeling good about it. Because you attended the planning meetings, you probably also understand very well how the feature will be used. But before you release the feature, it’s important to have the Product Owner do some testing to make sure they are really getting what they want. Once I was testing a new email feature, and the emails being sent were not formatted in the way the Product Owner was expecting. The developer on the team was then able to re-format the email so that it looked much more professional before the feature was released.

One of the great things about working on a software team is that all the team members have different skills. As a tester, you know the application really well and you can think of great edge cases to test. Your Product Owner understands the business needs of your application and how to craft user journeys. Working together, the two of you can make sure that your users have a great experience using your software!