Cloud docs for test documentation

Recently my consulting company migrated all our email accounts to google apps. Even if the main reason was to get the emails on a new platform, this was a good step for our entire infrastructure, where I found a good and easy-to-use tool for my testing and note taking.

To be straight about the use of it regarding project information, any information that can be stored in our emails, is in my perspective also something that is allowed to be stored in the google docs. I have gotten permission for the usage I am explaining in this post. The reason I want to state this is because my first search on using cloud docs for testing got me to this forum thread, where the poor lady is nailed into the wall with questions asking if she is really allowed to use spreadsheets in the cloud for sensitive information. The second question I read about is what I am going to explain myself in this post. Its about why one would want to use spreadsheets despite all the excellent test management tools out there with all these cool features. Duh! Instead of just keeping a reasonable dialog for her context. Here are some bullets within my context.

So why do I want to use docs in the cloud?

1. Same document can be edited from multiple computers by myself

   Since the application under test is reached from a desktop in a restricted network with limited internet access, I am still able to paste log entries and test data from there into the notes. At the same time, I can have my consultants laptop for reference and primary note-taking device. Before cloud docs I had notes on both computers that were not completely in sync. This is actually my killer feature for using cloud docs.

2. Easy sharing without unnecessary obstacles

   The need to share steps for reproducing bugs, bug analysis, logs etc. is a piece of cake. And while anyone can use the information from testing, I can still keep it up to date when more findings arrive. And to get back on the suggestion in the forum thread, name ONE developer that wants to open the QA management tool to help you investigate a bug or look at a log file that you don’t understand.

3. Multiple people sharing

   Could have been included in the previous bullet, but for me its important to have transparency with information, so being able to get many peoples attention is in some cases necessary.

4. Different kinds of docs

   I am able to create different kinds of documents for different purposes. I have mostly used the text document and spreadsheets, but the addition of drawings added extra value of being able to illustrate state flows etc. With the easy sharing possibilities I have also explored sharing screen shots and log files using the upload and share with many functionality.

5. Meeting notes

   When attending meetings, I really like to fire up a fresh text document and immediately share it with the meeting participants. If there are more laptops in the meeting I will not have to write everything myself, and the of collaboration in the note-taking gives a completely new dimension of the shared responsibility for the output of the meeting.

6. Supports my way of executing Thread based testing

   Will bring this up in my next post, coming up very soon. The two posts were actually first one big, but grew apart because of the mess it created.

7. Linking

   I know that there are very good tools for this as well, but this is actually something that needed to be there for me to be effective using cloud docs for note taking. There are features missing for the overview if many threads are open etc. I will also touch this in my next post. As a sneak peak, go read Christines post on freemind, and think about the knots that could be knit together with my cloud docs.

And how good are my notes?

Well, I try to keep the notes on a good enough basis. As a measurement on good enough, I would like to say that you should be able to read the notes and understand what type of testing was done, and if you are familiar with the environment be able to recreate most of it. Although during my one year of creating notes like this, I have been asked twice to look back at notes, on what was tested, and never further back in time than a couple of weeks. I would like to say that thread notes are something that has to be fresh at the moment, but since the software is subject to change there is no point in reusing it from longer in time than necessary.
This does however not imply that all others required artifacts are just good enough. Some threads have actually ended up with me creating some reference documentation on how the products actually work, since it did not exist. The same goes for the “Test specifications” that are required output artifacts from my testing in my current project.

What do my notes look like?

When talking about just test thread notes, they usually look something like this. What is important for me is some traceability to easily see dates, missions and status. When document is opened I see the most important properties of that mission in the top, like who tested, versions and a summary. The summary is something I realized I needed after having testing threads spanning many pages, and needed the summary to tie the knots and tell which loose ends were thrown away. Summary is usually subject to change after picking up the thread again. I will get back to the thread testing in a later post.