Cookies Preferences
Close Cookie Popup
Cookie Consent
By clicking “Accept All Cookies”, you agree to the storage of cookies on your device to enhance site navigation, analyze site usage and assist in our marketing efforts. Meer informatie
Modern software development is a multidisciplinary field where various competencies contribute to delivering high-quality software. However, some roles and stakeholders such as product owners, business owners, customer support and many others are often overlooked when it comes to testing. People can potentially uncover valuable information if they have easy access to test environments and a simple way to report found issues.
An example from a web application illustrates this point well. A new version of a specific part of the product had been developed with a refreshed user interface and workflow. While technically working, a domain expert discovered that it took eight clicks to perform a certain action in the new workflow compared to only two in the previous version. This might not be an issue if used sporadically but for end-users performing this action hundreds of times daily it could potentially be a big problem. This type of issues can be missed by developers and testers, and therefore it is important to access all knowledge in an organisation to increase the possibility of these issues being found at an earlier stage.
In this post, I will share why it's crucial to make the software under development accessible to everyone and share some personal stories from my experience.
In my role as test manager, one of the things I focus on is making the latest software accessible to everyone. In the following stories, I'll share how I've increased accessibility so more people in the organization can provide feedback on software under development.
This story takes place in a 500-person software development organization where I was the test coordinator. We were developing a web application with a four-month release cycle. Every four months, we gained a good understanding of the software status due to our release testing.
The main issue was the time between releases. Many stakeholders didn't interact with the software until release time because setting it up was cumbersome. This meant that some issues where the software technically worked but didn't suit end-users might not have been discovered until several months after code was considered "done."
Example of such issues where our recurring problem with the language support for Japanese. Every four months, we'd brought in a person from another part of the organisation with in-depth knowledge about the language to test an environment we had set up. Every time we were surprised with issues in the language implementation that were consistently uncovered just before release, requiring last-minute, high-effort remedies. With earlier knowledge about these problems, we would have avoided a lot of stress towards the release. Since there was no test environment for our Japanese expert to test in between the releases there was no way of finding the issues earlier.
To address this challenge and tap into the knowledge of various stakeholders and roles earlier, my colleagues and I started deploying the latest versions weekly. We then sent out invitations to the whole organization to log in and review the new software and mail us if they found issues.
This simple action eliminated the need to wait for major releases before stakeholders could provide feedback. Here are some highlights from the outcome:
We reduced the potential feedback loop from up to four months down to one week by providing a test environment accessible to everyone. My colleagues later took it further by setting up big touchscreens around the building where a browser was running the latest deployed versions. This meant that everyone in the building could walk up to a touchscreen and test out the latest software version, effectively making the potential feedback loop almost instantaneous.
This story takes place in a smaller development organization with two development teams. Simplified we were developing a hardware product that moved a mechanical arm from point A to point B based on sensor inputs and user configurations, controlled by software and configurable using a mobile phone. There was an office were the development team sat, and we had a test lab with different hardware configurations. The product lived and died by fulfilling industry standards and I was developing the test automation system. When I joined the team, there was a small Continuous Integration (CI) pipeline setup for unit testing new code on controller boards.
There was significant time wasted manually hooking up USB-dongles to laptops and flashing the software to be tested on the hardware. Issues such as software versions were wrong, cables incorrectly connected, or new code had completely broken rudimentary functionality could take a long time to resolve. If domain experts needed a specific version set up for testing, it could take half a day to find the right developer, flash the correct version, and get the expert started.
My goal was simple: Make it as fast as possible for anyone to test out new code on the hardware while ensuring that at least basic functionality was working. Step by step, I expanded on the CI pipeline:
Anyone could now choose a software version and configuration to test, then grab a cup of coffee. Upon returning to the test lab with their warm drink, they'd find the software correctly flashed on the right controller boards, with rudimentary functionality checked to be working. If there was a problem with the software, they'd be notified without needing additional investigation.
This change made it very easy for domain experts to test new functionality and verify if it fulfilled the important standards. Simple tests that could take a day to perform due to manual steps could now be done within half an hour (including coffee time).
Additionally, I placed the office test-hardware in the line of sight of the project lead which allowed him to see when code was broken because of the arm moving in interesting and artistic ways instead of the correct but boring movement. It also made it simple for him to walk up to the test door and get a feel for how the software was progressing, thus making it possible for him to provide feedback.
There are some simple points you can keep in mind in your development project:
A practical tip: If you are working in an Agile way, use your Definition of Done. State that a new feature should be deployed to an accessible test environment after sprint demonstration and send out release notes to the organization. In other words, if not everyone can test out the new software, then it is not done yet.
The idea is simple yet powerful: Focus on making it easy to automatically deploy new code to test environments that non-developer roles can access. By doing so, you empower more of your organization and tap into previously untapped knowledge. This enables faster feedback about issues and challenges that developers and testers might miss.
