Nobody reads my test documentation

I see it as my duty to make test documentation. I’m a consultant, the only current tester on my project, and can leave (or be asked to leave) whenever. In that situation I don’t want to leave behind a project that have to start at square one with a new tester who doesn’t know anything. The project is huge. It took me 6 months to get to a place where I felt pretty confident in some of the systems. A new tester would probably need even more time, as I had the luxury of joining the project at a time where there were 2 other testers.
So I document everything very neatly. That means I have an extensive collection of test documentation. It’s everything I’ve worked with during the last 1½ year on the project. As of today there are 204 pages, and I update it every week with new information.
In my collection I have technical drawings, guides on how to do different things in the different systems, how you setup the different programs, a word list of every single word that is related to the project, tips for using the database and most-used java scripts for SoapUI… There’s everything you’d ever need to know.
And nobody ever reads it.
Look at this! This is 204 pages of pure documentation-magnificence!
Except for me. I use the notes all the time. That makes it okay. I’m just curious about why my colleagues don’t want to read my notes. They’re really good. I hate reading lines and lines of text, so I’ve done my best to make them good. These notes are seriously a treasure chamber of easily digested, easily searched through, interlinked, visual communication.

“The answer to that exact question is right here in this guide!” – *Still no interest*

My test leader asked me to make a smaller version of my notes into a guide for SoapUI. It describes how other projects in the company can benefit from testing like we do in my current project. There’s a step-by-step setup guide with pictures, arrows and explanatory boxes, links to good places to read more, and there’s a troubleshooting guide with solutions to every single error message I ever got.
This year, many other projects have started up, and they want to use SoapUI as well. I’ve sent them the guide several times. I even put it online on the company’s sharepoint site in the Test department, so everyone can either search on the intranet for it, or go to the Test department sharepoint site. They have it. It’s right there.
Despite this, I’ve spent many days mailing, chatting and walking to different rooms to help other testers and developers get started using SoapUI. A while ago I met this comment:

There’s some kind of security issue.. Is it in the guide? Oh it is… Could you come by anyhow?

And of course I can come by. I’d love to help. It just left me sitting in my chair during the afternoon, wondering why this person still didn’t want to read my already-established-awesome notes. It led me to the conclusion that:

No one wants to read your test documentation. Take it as a compliment.

So why won’t anyone read my test documentation? Here’s why.

It’s a chaotic format: My colleagues don’t know where to start. To me, the test documentation makes perfect sense. I’ve set up the notes it in a perfect, logical system. And that’s the thing. It’s logical. To me. Not to everybody else. I’ve seen plenty of documentation in my time, and even when the person in charge has gone to great lengths to make it an easy read, it’s still chaotic. It’s still hard to understand. Because when you cram enormous amounts of data into a very little space, it takes time to chew your way through the data.

Ain’t nobody got time for that: People have loads of things to do. They don’t have time to sit down and read 204 (albeit nice) pages about a boring system in the hope that they accidentally stumble upon the thing they were looking for.

It’s boring: Even if I was J.R.R. Tolkien, I couldn’t think of anyone who would feel very strongly about reading my guide on how to distinguish between the pension ensurer and the pension ensuree. Even if it has nice pictures (It has). Sure, documentation is important and I read a lot of it. Is the experience as gratifying as that time I read the book “Don’t Make Me Think”? No.

Talking trumps reading: I’m right here at my desk! I can walk over to other testers’ desks and give them a personal troubleshooting session. It’s just way easier to talk to me.

…unless they really have to

It’s not until that fateful day, where I’ve left the building and the shit hits the fan, that my current colleagues will start reading my test documentation.
Till then, I will do my very best to let people know that my notes exist. I will brag about my collection to every single person I talk to about testing in my project. I will send the notes to anyone who asks about something that is in the notes. I’ll remind my test leader several times that the notes exist, so he can be reminded in a couple of years. When I’m done with the project, I will upload every single page to the intranet. Hopefully there are more like me, who use the search functionality on the intranet, and they will stumble upon the sparkly, hidden chamber of knowledge I’ve left behind.
…
When that glorious day come, I hope they’ll like the pictures.

You may also like

I’ve only recently gotten to know databases. How they work, SQL and the different scripts you can use. I love it. I think it’s so much fun going into different databases when testing, viewing, comparing, joining and editing them. Even though the amount of trouble you can cause in there is immense.

I’ve made a series of test stories from my favorite test runs. This 2-days user experience test run is without a doubt the most extensive test I ever did in the smallest amount of time. These were not average 8-hour workdays, these were meticulously planned sessions that fit into my timetable with great precision and lasted from morning to evening.

Stage 5. Got fit! I decided that I had to get that stress out of my body. And the best way to do that, is to exercise. I would also benefit from having a daily goal, something I had to do, now that I couldn’t go to work every day.