Over the past two decades, I have seen many advances in technology and processes for software development. From the evolution of computers, storage, and programming languages, to new social, organizational and development models for businesses to consider. Of all these advances, I like how the Agile Manifesto returns the business focus to providing value quickly through human interaction and collaboration. Sometimes throwing more technology, processes, and tools at the problem won’t help you develop better solutions.
Quality requires a whole-team approach. Everyone tests, all the time. You may have some specialists on your team with testing expertise, but they aren’t the only ones allowed to ask good questions and provide actionable information on quality. Contrary to what some vendors may lead you to believe, a whole-team approach to quality doesn’t require a lot of complex, integrated tools and services to achieve. You can do some good testing with readily available, low-tech tools.
The best, most widely available, and disappointingly least-often-used tool in testing is, of course, your brain. If you aren’t thinking, you aren’t testing. If you aren’t testing, you aren’t paying attention to what you are developing. If you aren’t paying attention to what you are developing, you aren’t being agile, because you aren’t really sure of what value you are providing.
When you use your brain in testing, things like creativity, models, and deduction can help boost your effectiveness to a new level. You may discover that you don’t have to go high-tech to do a great job. Keeping in line with the agile spirit, my top three most commonly used low-tech tools in my agile and exploratory testing toolkit are whiteboards, Sneakernet, and paint applications.
As a visual learner, I find that whiteboards to be invaluable tools. I use them to brainstorm, share information, track risks, and radiate project information.
I haven’t used a test plan document in almost a decade. People don’t read them, teams don’t use or maintain them, and you aren’t being agile if you use them to communicate important information. Note that I am not against capturing records or artifacts of the work performed on projects. Documents are records, not conversations. You don’t build relationships or develop an understanding between stakeholders or project team members when you use a document to relay important information.
By comparison, whiteboards let everyone on the team know what’s going on in the team members’ heads. Ideas, observations, explanatory diagrams, schedule milestones, progress charts, and more, are exposed and not buried in documents where they are less likely to be noticed, if at all. You never know when a piece of information will be critical to someone else’s understanding of the project or system. Put the information up on a board and leave it there for a while; anyone can come along and learn from or add to the information shown.
Whiteboards located in high-traffic areas, or where we gather for meetings, are prime candidates to use as information radiators.  There are many types of information radiators to help communicate different views of development progress. For testing purposes, I sometimes use a testing dashboard.  This allows you to organize descriptions of the testing status, effort, and quality in a table format so that all team members can quickly understand what’s going on at any given moment without having to ask questions. Depending on the project, I may customize the dashboard with additional or different information, or I may not use one at all. Whiteboards are where brainpowers meet team powers.
When I train developers and testers in agile and exploratory testing practices, one of