This blog post is based on a 99 second talk I gave on 17th July 2019 at the Birmingham #MidsTest meetup.
Once, a change had to be made to the software. This particular change was something that could not be controlled via the user interface. It was also not possible to observe the change via the user interface.
When we think about the testability, if something cannot be observed or controlled via the User Interface, this would mean that this change was untestable – right?
There are other ways.
Don’t rely on the User Interface
Sometimes a change might be made to the application that isn’t user facing. It might be something that the user should not change or view for safety or confidentiality reasons.
From a usability and user experience point of view, being able to see and interact with the user interface is essential. However, there is much more happening beneath the surface that the user never sees. There is likely to come a time where this needs to be tested.
Contrary to popular belief, developers and testers should not be enemies. They can help each other. A Whole Team Testing approach is being discussed throughout the testing community. Testers can help developers and developers can help testers.
When there is a new work item or change request, encouraging testers and developers to discuss the requirements early on can avoid any misunderstandings later on. A failed test because either the developer or tester did not understand the requirements wastes time.
Making an application testable, making a defect fixable
Communication can also be used so both tester and developer fully understands what is required to complete a work item. A work item should not be complete until it has passed testing by a tester.
If something is not easily testable, then the developer needs to make it testable. To do this, the developer needs to know what the tester needs.
If a defect is found while testing, then the tester needs to provide enough information for the developer to fix the defect. To do this, the tester needs to know what information the developer needs.
Introducing extra logging
When told a change had to be made to the application that could not be controlled or observed via the user interface, I started out by talking with the developer.
We discussed the requirements to make sure we both understood the change and why it was needed.
We then discussed what we needed to fully implement this change. We decided that adding some additional logging would help with testing. We discussed what and when information was required.
Extra logging helps both the developer and the tester. Both can benefit for the information it provides. The tester benefits by having a better understanding of what is happening beneath the user interface. The developer can also use this information to help fix any defects found.
By speaking to the developer before the change was implemented, we were able to reach a mutual understanding. We both agreed on the requirements and what was needed to make the the change testable.
Agreeing on requirements early on can reduce delays later on. Making sure that something is testable improves the quality of the application. Working together improves the efficiency of the entire development process.