Communicating with developers to uncover information when building software
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
- It’s very easy to limit the testing to the parts of the application that we know will be affected. We should be thinking about what else relies on the bit of code that will be changed. For example, the story you are kicking off is about the login feature, as the code could be touching authentication, do you need to consider parts of the application that are behind authentication? This also helps to gain a deeper understanding of the complexities of the code which will enable you to write better test cases. A tester who understands the code base better will be in a great position to look for troublesome spots and areas of potential breakage.
- It’s also worth considering if there is other work in the backlog or currently in flight that may touch similar areas/overlap with what you are going to be working on. If that is the case, it may be worth getting those developers involved in some conversations around the implementation.
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:
- If we change auth, will the customer be logged out when the changes get released?
- If the contract between the API and mobile app has been changed, will old versions of the mobile app still function as expected?
- Similarly, if the contract between 2 services has been changed, is the change localised to them or will it have knock-on effects to other APIs/services?
- Are we going to release the changes altogether or release in increments? (think about value added for the end user and faster feedback loops)
- How do we know if this change has had a positive impact on our users?
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.
