Lessons I learned from my developers: A tester’s perspective [webinar recap]

 In Blog, Most Recent, Test Automation Webinars

Lessons I learned from my developers: A tester’s perspective [webinar recap]

The relationship between testers and developers can often feel like that of water and oil: separated at best, full of tension at its worst. The friction between testers and developers is a well-known obstacle to overcome at countless organizations, with developers often faulting testers for not keeping up with their release cycles.

Despite this challenge, testers and developers will need to continue working together in order to build a high-quality and reliable product. Therefore, managers and team members alike are always looking for new ways to improve communication between these two teams.

Two weeks ago, we had the exciting opportunity to discuss how testers and developers can work better together with Corina Pip of the “I’m a Little Tester” blog & comic series in a guest webinar. In her talk, she discussed some of the most important lessons she learned while working side-by-side with her developers, and how she applied those lessons to improve her skills as a tester.

Here is a brief summary of what Corina discussed in the webinar below, and you can also watch the full recording here.

Cross-learning between testers & developers is key

At the start of her webinar, Corina reiterated that it’s extremely important that testers and developers know how to communicate with one another. She reminded everyone in attendance that, tensions aside, testers and developers are ultimately working towards the same goal: delivering a high-quality product to their customers.

With that in mind, Corina noted how testers and developers think differently when it comes to delivering a high-quality product. She noted that developers usually work on a smaller part of the product, which means that they don’t always see the big picture or how their small line of code will impact the entire ecosystem. This gives developers the opportunity to learn from testers how the system under test works as a whole.

On the other hand, testers can learn a lot of insights from the code that developers write. Even if testers don’t know how to code themselves, there’s a lot to learn just by knowing the language and framework that the developers are using. This gives testers an opportunity to learn about different product dependencies and system components, as well as weak points in the system, which will ultimately inform the test scenarios they create in the future.

Where to learn from developers

Corina then offered a few tips of different times that can be especially useful for testers to learn more about and from their developers. By knowing when developers are discussing their strategies and viewpoints, testers will both know what to test and gain insight on how to tackle product issues at work.

Stand-ups

The first place where Corina advised testers to listen to their developers is at stand-ups. Many development teams at different companies offer stand-ups in the mornings, where developers have the chance to share what they tried implementing the previous day. They also share what did and did not work, and how that will inform their work moving forward.

Corina noted that she found stand-ups or other technical discussions like these to be valuable for two major reasons. The first reason is that these meetings helped structure her work throughout the day in order to be more aligned with the developers. Second, these meetings gave her a glimpse of what the system would look like after it’s developed, which gave her ideas for how to test it.

Pairing with developers when debugging software

Whether you’re looking to debug tests or code, Corina also advised that testers and developers pair together when working on debugging projects. While debugging, testers and developers can look at two sides of the same coin: they can either identify what data is flowing through the application at a specific point, or what code is executed in the application at a specific point. Either way, looking at issues through both of these lenses can help narrow down issues.

In Corina’s experience of pairing with developers, she found that she was able to identify three things more easily than if she working alone:

  • The reason for the test failure
  • The state of the system
  • The data that passed through different systems, whether they were endpoints or pages

Testers have in-depth knowledge of what should be input into the system and developers know how that input should be processed within the system. Having them work together will give a more holistic look at the system overall and resolve issues more quickly.

Analyze like a developer

From stand-ups to debugging and interacting with developers and general, testers can also gain certain analysis skills that can help with their testing in the long run. Corina first advises that testers should analyze the business requirements and build a strategy before they start testing the application. Aside from being a smart move in general, this also mimics how developers come up with a strategy before writing code.

Corina then suggested a few areas to focus on when analyzing requirements and building a test strategy. She first suggested that testers should visualize the user flows, and even creating diagrams to make what you’re trying to do even more understandable. From there, Corina urged those in attendance to identify common steps within these user flows.

With this information, testers can then create reusable test models that will help improve their overall testing efforts. Not only does it minimize workload, but having these visual, reusable test models also help everyone speak the same language. Therefore, if there are bugs at a later point, it will be easier to find them and mitigate the problem.

Example of a TestCraft reusable test model

Example of a TestCraft reusable test model

How to report issues to developers

Another common issue that Corina discussed in her talk is how to report problems to developers, as this is an obvious source of tension and strain. She gave a few tips to help testers do this as smoothly as possible.

Reproduce the issue properly

Corina’s first piece of advice she gave when reporting issues to developers is to make sure that you reproduce the problem properly before raising it. Oftentimes testers approach developers letting them know that there is an issue, but give a vague description of what they did without clear direction.

Since all actions are translated into code, it’s important to them to know exactly what you were doing in order to effectively investigate the issue. This will also give the developer the confidence that you as a tester know what you are talking about, making them more willing to work on the bug instead of another pressing issue that may have come up earlier.

Produce evidence with logs and screenshots

Echoing this first piece of advice, Corian suggested that testers approach developers with logs and screenshots to help explain the issue that occurred more clearly. Not only will this help the developer retrace your steps more easily, but this will also give testers a clue into what’s going on and which developer to speak with about the problem.

Reading logs can be a useful tool for testers. When certain errors occur, especially ones that seem like exceptions at first glance, the tester will be able to see who or what triggered it and find the right person to speak with about the issue. With more information, both the tester and the developer can resolve the issue more quickly.

Sample TestCraft report

Sample TestCraft report

Remember that errors are rarely random

Finally, Corina reminded everyone at the webinar that when you are clear about explaining an issue, you will soon realize that things are often not as random as they seem. A certain user flow corresponds to a certain execution flow; when the tester is clear about the former, the developer can be clear about the latter.

Questions about the tester-developer relationship from the audience

At the end of the webinar, Corina reiterated that even with these new communication skills, testers should also have the confidence to help themselves when they’re confronted with a problem. Not only can testers fix issues as well, especially small issues like typos and small bugs, but testers can also keep up with tools that the development team is using and what is going on in new releases. The more information you have as a tester, the better equipped you are to either resolve issues yourself or get the right help from your developers in the process.

Corina then concluded by answering questions from the audience. For your convenience, you can read the questions and her answers below:

How would you recommend getting the best insight from developers when working remotely?

Have regular catchup sessions with your developers. There are so many different channels of communication. Try to speak w them once a day, or schedule regular discussions if once a day is too much. Always have an open door and sync up with them regularly. Standups are still done now virtually, so this is also a great opportunity to kick off discussions or ask a developer for help with an issue later on.

How would you go about defining the scope of testing without clear business requirements?

If you need to implement something, why shouldn’t you have business requirements? Even if overall business requirements aren’t formal, testers need some sort of guidelines. Either go to the product owner or a business analyst and try to clarify what is needed.

Sometimes product owners or analysts don’t know what’s needed, but they can also ask stakeholders in the future. Sometimes features that you’re working on as a tester are based on customer experience or feedback, so you can also see what’s required there. Ultimately, there needs to be some sort of requirement to give you direction for what to do.

You can also try to address the requirements yourself. You can request to implement certain features based on your feeling that the user experience isn’t good. You can do this by creating tasks in JIRA (or your other preferred tool of choice) and discuss them further at groomings. If it’s accessibility-related, then show whoever is creating the requirements what the issue is so they will know how a lack of accessibility may impact the customer.

How do you recommend introducing this culture to the team? Both developers and QAs?

Sneakily, without them knowing. Whenever I have a question, I will ask it; I can’t just keep my doubts to myself. I suggest you always go and talk to someone, whether it’s formal or not. Try to be relaxed and engage them in a friendly, but informative way. That way, it will be much easier to make a change.

Can you describe how the team handles an important missed bug in production with the product owner?

When it comes to a bug, it doesn’t necessarily go to the product owner. It depends on the gravity of the problem. If it’s something serious, then the team will need to address it quickly with an emergency release.

The product owner should be aware of the issue, even though s/he may judge and ask why you didn’t find it before production. Even if it may be unpleasant at first, the way to deal with this is by taking measures to make sure this situation doesn’t happen again in the future.

 

Book free consultation session

Strengthen the QA process through the CI/CD pipeline webinar recap