Communicating with developers to uncover information when building software

Photo by Christina Morillo from Pexels

How to communicate with developers to uncover information

I recently watched a video on how to help developers be better testers but the main message I took from it was how you can communicate with developers to uncover information about testing software.

There are loads of great questions you can ask developers as part of the refinement process of a work item. An example of this is during kickoffs/3 amigos sessions. The reason why this works really well is because by this time, you should have a story complete with acceptance criteria so you have a pretty good idea of what needs to be developed (most of the time!).

Here are a few examples of questions you could ask:

Ask them about code dependencies

Ask them to do some pairing when they pick up a piece of work

This not only encourages collaboration between developers and testers, it gives you the opportunity to share knowledge with each other. You get a better understanding of the inner workings of the application and the developer gets a better understanding of what you would look out for when testing the software, we should be sharing out testing techniques with developers, not keeping them for ourselves as this will help to build a better quality product. A developer who understands how you test will give them ideas on how to write better tests which will lead to an application with better code.

Ask developers to demo some of their work to you

This has worked really well for me in the past. Before a developer merges their code, ask them to run you through the feature they have been working on, at different parts of development. Not only does this encourage collaboration, but you’re able to give developers earlier feedback on ambiguities and identify areas for improvement. Why wait for a formal build to give such feedback?

What does rollout look like?

Far too often do we think about building a piece of functionality and forget to consider how we will roll this out/release until after it has been developed! For example, how will our users be impacted by this change:

Be curious

What is worrying you about this feature?

This question is great as it gets them to present the concerns they have around developing a piece of functionality and you can use this information to form a better understanding of which parts could need more attention than others during the exploratory phase of testing.

What do you think is going to break?

Not necessarily related to code dependencies. It could be that the part of the codebase they are working in is using legacy code that isn’t very well tested/fragile. This then presents an additional benefit, you could enhance your automated test coverage so the next time a developer is working in that part of the code, it’s less fragile and they can deliver better quality code, faster. So, when you are collaboratively writing your test cases, you have a gauge of how fragile the system is to help inform the test approach

Are there any parts that could be difficult to test?

For a mobile application, as part of an incremental piece of work, are there any issues with testing the piece of functionality that will be developed? It’s not always as simple as validating a change to the UI or a network call being made to an API. It could be that the application is storing some information locally based on some inputted info. In order to test this, you could ask a developer to add a popup indicating when/where this data has been stored. One thing to bear in mind is that each story that we deliver needs to be testable (unless of course it’s a technical task) otherwise, how can you be sure that it behaves as expected?

Are we introducing any tech debt?

It can be quite easy to not discuss tech debt until it gets to the point where developing becomes very difficult because of it! In some cases, what developers understand is important (from a technical perspective), might not match with that of the product team. For example, developers may want to reduce the debt of deployment, but this might come at the cost of neglecting something which makes the product managers life more difficult. By asking this question early on, we can promote more communication between product and development that could encourage improving the quality of the application by identifying opportunities to clear the technical debt.

Are the system boundaries clearly defined?

For work you are doing with the API, what services do you get the information from and how is this information presented in the API response? If we are making any assumptions, we should discuss them and validate them. The job of a good engineer or coach is to ensure that the quality of the product and developer experience remains high even after some time has passed and when new developers come into the fold.

This is by no means an exhaustive list but hopefully you can use some of this to help you foster relationships with developers and gets them thinking about testing before and during coding. Reach out to me on LinkedIn if you’d like to continue the conversation.

Currently a Senior QA @ Babylon Health. I enjoy blogging and talking about all things software testing! In particular how we can shift testing in all directions

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store