Expert Tips on Reducing Documentation 

As a test manager, for many years, my life has revolved around paper... requirements, documents and reports. I even had the poster!

I must admit I found comfort in my templates and checklists but then came agile! In an agile world, the focus is on delivering working software quickly and efficiently.  Agile methodologies encourage collaboration and communication between team members, including End Users, Testers, Developers and Product Owners. One of the key principles of agile is to value working software over comprehensive documentation. 

For me, I struggled with the idea that ‘discussion’ was as valuable as ‘documentation’, however it was a case of ‘adapt and survive’. Here are a few of the strategies I have employed over the years to ensure that my team remained “fleet of foot” rather than “running wild” and that I was at peace with the process, even though the documentation was light...

Automated Tests

Automated tests are an effective way to minimise the need for test documentation. Automated tests (and particularly the use of static analysis tools) can be run quickly and reliably, providing Developers with immediate feedback on whether their code changes have introduced any regressions.  

For example, if we were working on a web application, we would use a tool like Selenium to automate our tests. We would create tests that checked the functionality of different pages and components of the application, such as forms, buttons and links. We used tools like Cypress and TestCafe to create end-to-end tests that simulated user interactions and to test the application. 

The great thing for me was the ability for everyone to see results near real-time and fix right away without the need to create a separate defect report.

Collaboration

Collaboration is another key principle of agile methodologies. By collaborating closely with Developers and Product Owners, Testers can ensure that they are testing the right things and that the software meets the business needs. 

On one project, we were fortunate to have a 1-to-1 Tester-to-Developer ratio. They worked together to identify and fix bugs even as the code was being written.  

On another project, where we had traditional Manual Testers and were using agile for the first time. In this case, the Testers would explain the tests they wanted to run and the Developers would create automated test scripts.

Exploratory Testing

Exploratory testing is a testing approach that involves exploring the software without a specific plan or test script. This approach can be useful in an agile environment, as it allows Testers to quickly identify issues and provide feedback to Developers. 

This approach has worked well for me where we have been de-platforming an existing application. A Tester could be tasked with testing a new feature that has been added to the software. The Tester could explore the feature and try to use it in different ways to identify any issues or edge cases. The Tester could then report their findings to the development team and work with them to resolve any issues. 

Test Charters

Test charters are a useful tool for minimising the need for test documentation. Test charters are a document that outlines at high-level, objectives and the scope of a test session. They can be created quickly and easily as it provides Testers with a clear focus for their testing. I love test charters for agile as it gives me the opportunity to meet with the Stakeholders and find out what is important for them. We would agree on the features to priorities, the testing objectives and any risks or assumptions. The Testers then use the test charter to guide their testing efforts and time.

Keep it Simple

When working in an agile environment, it is important to keep things simple. Test documentation should be kept to a minimum and only essential information should be included. Simple tests can be more effective than complex tests, as they are easier to run and less likely to contain errors. 

To keep things simple, Testers should focus on creating clear and concise test scenarios that cover the most critical parts of the system. They should also prioritise their testing activities based on the risks and business needs. In order to help me keep on track with regards to resisting the desire to create a new document, I created the following checklist:

1: Use automated tests to reduce the need for manual testing and test documentation:

• Are there unit tests in place for critical code paths?
• Are there integration tests in place to test how different components work together?
• Are there end-to-end tests in place to test the application as a whole?
• Are the automated tests reliable and maintainable?

2: Emphasise collaboration with Developers and Product Owners to ensure that testing efforts are focused on the most critical areas of the system:

• Have Testers participated in code reviews to identify potential test scenarios and provide feedback on the quality of the code?
• Have Testers used pair testing to test specific pieces of code with developers?
• Are Testers regularly communicating with Product Owners to ensure that testing efforts align with business needs?

3: Use exploratory testing to quickly identify issues and provide feedback to developers:

• Are Testers skilled in identifying potential issues and reporting them in a clear & concise manner?
• Do Testers have a good understanding of the system under test and its business requirements?
• Are Testers using exploratory testing to find edge cases and scenarios that might not be covered by automated tests? 

4: Create test charters to provide Testers with a clear focus for their testing activities:

• Have test charters been created for exploratory testing and regression testing activities?
• Do test charters include information about the system under test, testing objectives and any risks or assumptions?
• Are Testers using test charters to guide their testing activities and ensure that they are focusing on the most critical areas of the system? 
• Keep it simple by focusing on clear and concise test scenarios that cover the most critical parts of the system.
• Are tests prioritised based on risks and business needs?
• Are duplicate or unnecessary tests avoided to prevent confusion and maintainability issues?
• Are testing strategies adapted as needed to keep up with changing project needs? 

By following this checklist, Testers can minimise the need for test documentation while still ensuring that the software meets quality standards and business needs.

Download the full agile test tips here.