Skip to Main Content

QA’s Guide to Effective Communication With Development

Communication With Development
Ashley David, QA Analyst

Communication With Development.  I’ve been lucky enough to have a great team of developers who are passionate about the quality of their applications as much as I am. This blog post will introduce a few simple ideas that I have found to be effective in facilitating a productive relationship with development. At Accusoft, we have adopted a Quality Assistance mindset towards testing, similar to Atlassian’s. For the purposes of this blog post, QA will refer to Quality Assistance.

 

Ask Questions

This may seem obvious, however, I notice it is often neglected. Furthermore, asking the right questions gives the developer an opportunity to explain their thought process and fully think through their solution. Talking out any solution to a problem gives the listener a better understanding, as well as the speaker. I can’t tell you how many times I have had a developer explain a piece of code, or test, and they went, “oh wait… that’s a problem” or “this isn’t going to work… I didn’t account for x”. It’s up to us, as Quality Assistants, to ask the right questions that expose the areas at high risk for failure or lacking test coverage.

Some examples of questions I typically ask are:

  • What are you trying to test?
  • Will this affect x?
  • Can you explain what this piece does?
  • I saw you did this over there but not here. Why?
  • How did you come up with that solution?
  • What would happen if this piece fails?
  • How would this affect a user?
  • Let’s say x happened, how would this account for y?
  • Star Wars or Star Trek?

Be selective in your questions. Sometimes one good question can address two issues you are seeing. This also may seem obvious, but these questions should never be condescending. This is a collaborative effort to ensure quality. I’ve had the experience where many of my questions were answered, by a developer, with very eloquent solutions and almost all edge cases considered. These situations can happen when you have a very quality conscious developer and that’s okay! It doesn’t mean you are going to lose your job, it means you are doing your job right!

Be prepared to answer questions as well. A developer may come back asking why you asked that question and you’ll have to explain your thought process. Don’t be afraid to explain your thinking. Collaboration is all about perspective. Many times people get stuck and just need another person to provide some new eyes to arrive at a solution. As QA, you have the perspective of the business and a user—this is valuable to a developer.

 

Provide Scope

The functional definition of scope varies across groups. A developer may consider scope as affected services and libraries; whereas, a product owner may consider scope as target demographics. From the perspective of QA, scope is domain knowledge of our company’s products, what other teams are working on, and technical and business goals.

Domain knowledge is the key to our success as quality assistants. We have to know how the product works as a whole. This knowledge will help when it comes to planning a new project. If there’s a small change to one part of the application that may affect another, we have to be able to provide this knowledge. We will also need to explain how our customers use our products. I typically like to go through future projects and look at what we’re going to be working on and try to gain as much general knowledge of that product or application. I find when I obtain this knowledge, I can help fill in the gaps of missing information for the team during planning. Obviously we are not super humans and we will miss some things. Along the way as we learn more about the product (perhaps through exploratory testing), we will continue to assist the team in filling in more holes and answering more questions. The end goal from both the QA and developer perspective is the same thing: the person “buying” this solution considers it valuable.

Knowing what other teams are working on can help your team during your planning meetings to set realistic expectations on outside dependencies. Let’s say the business wants to add a new feature. However, it’s affected by another part being worked on by another team. We need to communicate this dependency/relationship. Having the opportunity to test, and use most of Accusoft’s products, has given me the knowledge to prepare my team for external dependencies. If another team develops something new, and I don’t have a lot of knowledge of it, I take the opportunity to learn this new item. To do so, I first find and read any documentation. Then, I may download the product and try it out myself. Sometimes I’ll ask the QA member or developer on the team about the new item. Once armed with this new knowledge, I will share it with my team. My reasoning for sharing is to provide better visibility on what solutions and features the rest of the company is working on.

Having a good relationship with your business is important. Knowing why you are working on a project can provide insight on what problem you are really trying to solve. Sometimes the business has your team work on a solution to a problem but never actually communicates what the problem is in the first place. Once again, asking the right questions can solve a lot of this. I combat this by looking at an upcoming project and point these issues out early. I will ask our Product Owner questions like “What are we trying to accomplish with this?” or “What is our ultimate goal with this new feature?” Many times just knowing and communicating the overall goal can save your developers from a lot headache.

 

Show an Impact and Risk Assessment

Risk and impact analysis is extremely beneficial to developers in giving visibility into the risk of failure and impact of change to an application. This affects the decisions your developers make when planning a new project and gives perspective on what type of test coverage a particular product needs. A risk and impact matrix (like the one below) conveys the severity of a particular area of an application to your developers.

 

For example, let’s say you have an application that is very fragile and has high impact. You can provide an analysis, using the matrix above, to support that this application may need better automated test coverage or need to be redesigned to reduce complexities. This matrix helps support the claims of where your application is doing very well or where it could use some work. There is a lot more to risk and impact analysis than a matrix, but maybe that will be covered in a future blog.

 

Communicate Testing Strategy

At Accusoft, we have adopted the Quality Assistance mindset but are still transitioning from the traditional Quality Assurance mindset when it comes to testing. We are slowly transitioning our developers to write and perform tests. However, our QA Analysts and Leads still handle a fair portion of the testing.

If the developers are creating tests, QA and development have a collaboration session where we talk about edge cases, risk, test coverage, and any other scenarios that need to be covered. I find that the developers who have these session early on tend to close out tasks faster and deliver higher quality code. In my experience many developers like this method, since they don’t have to deploy code several times and wait for it to be reviewed. I also find developers typically want to collaborate as often as possible once they see the benefit.

If QA is creating the tests, we make sure the developers are aware of the testing criteria. We will share edge cases, areas of high risk, and scenarios that need to be addressed. I share my test cases with the developers so they can see exactly what steps my test will be executing. Now some people in the QA community will say that’s cheating, but I believe it is transparency. We don’t need to keep our tests a secret; We aren’t trying to trick our developers or show how superior QA is. They need to know what scenarios need handling and the proper way to fail. We should assist our developers as much as possible, and that means providing them with enough knowledge to produce high quality software.

 

In Closing

These are all simple approaches on what and how to communicate with development. I have tried these and can attest that they work. The important thing to remember is that developers are people too (even if they seem scary and weird sometimes). They can make mistakes and learn new things. As much as they can learn from us, we can always learn from them too. Some of the best testers I have ever met have been developers. Be open to discussions that will help you better assist your developers. We want our teams to succeed in producing amazing, quality software and that can only be possible when we effectively communicate.


Ashley has been a QA Analyst at Accusoft for a year. She is relatively new to the industry. However, in the short time she has been at Accusoft, she has implemented some of the first automated tests on her team, increased quality of deliverables, and helped release an internal CRM system successfully. Outside of work, Ashley plays piccolo and flute with the Wind Symphony of St. Petersburg College. She loves theme parks and visits them regularly.