The Undercover Adventure (Part 2): I want to know what you mean. What you meant. What you will mean. Everytime.

I am a really strong believer in validating assumptions and clearly communicating your decisions with your team before you choose to take a path in front of you. If due diligence isn't followed certain things do tend to go awry. Software development can be a complicated mess of misplaced structure put there via good intentions (no wonder dealing with bad software sometimes feels so much like being in hell).

I came to this thought via a particular Thursday while I was attending a test/user acceptance/software status update meeting. Now, as strange as this may sound I do have a deep and passionate interest in testing. I believe it is a critical piece of the whole software development effort and not merely just a step to be avoided when crises strikes. It was incredibly insightful to be there listening and observing. I noted something that I want to discuss here.

There was a severe lack of relevant documentation (electronic or otherwise). There was no test pack, no bug list and specification present on the table, nor any meeting notes or agenda. This would've have been so usual in a small test with only 3 people working together each team and the meeting being a 15 minute check in session. However, this was the formal weekly review meeting to determine the status of the application to handle all the administration and facilitation of work that falls within maintenance.

After all the people had checked out, the meeting started. What I found strange immediately was that people, who were attached to the meeting via conference call, didn't have RDP or VNC access to the test application which was being demonstrated. However, they were required to answer on particular issues that were coming up. The person who was doing the walk through seemed to be reasonably knowledgeable about the system until she got lost and then things seemed to derail somewhat. The business user present, who is meant to be the final critic and bearer of bad news in this moment didn't say much. After the somewhat disconnected walkthrough was stopped by confusion of why something wasn't working and the tester being unable to find the next part, the meeting concluded and everyone went about their way.

Strange still I saw notes being made on a piece of paper and no summation was given at the end of the meeting to ascertain if everything had been covered. My preference, where possible, is that a bug list is made on a laptop connected to a projector so that everyone can see what has been recorded for that meeting. When you don't measure (mark down) what you do, there is no way that you can manage it or be able to field questions that enquire your status and progress to date.

I was somewhat taken back by the whole experience. For me, I expect a tester/test analyst to have intimate knowledge of the system, to understand its structure, navigation, data and security. I expect the tester/test analyst to come prepared to a meeting with the following: the assigned test pack that is meant to be discussed for that meeting, a list detailing the functionality that is meant to be signed off (or at least agreed to) and finally a bug list (at minimum to addition to having a clear agenda and outlined expectation of end result). In a formal organization with a large application you cannot afford to make notes on the back of a page and be sure that what you have written is actually accurate.

After I walked out of the meeting, something else struck me as being rather odd. In all my wanderings from meeting to meeting, discussion to discussion I had yet to run across any specifications. I have been on a project before where requirements (and general documentation) were wafer thin and that the only artifact I received into testing was the application and a brief "walk over water description of the business" document.

While being wafer thin is a marketable quality for a potato chip, the dynamic does not play out so well here. Where there is a lack of clarity people tend to make assumptions about the potential reality of things. In addition, people tend to assume without seeking to validate their assumptions. In my experience, when a project starts lean and mean, it always ends up like drunken spider trying to make a web. Short circuited effort to pull together all the thoughts and decisions to manage too many legs that end up heading in every direction and any effectiveness on achieving a beautiful balanced structure is beyond its grasp. What happens then is that the process of software development happens in reverse (something I will cover in more detail in next week's post).

Software development is a complicated effort that requires form and context accuracy when creating anything that adds/changes input or output to/into the project. Form being the structure and content of what you create and context being the surrounding environment that places demands on the form. It is key is to have communication transparency expressed through accurate and complete form in every place where a note is made, a piece of code is written, a meeting is held, an issue is marked down. When I speak of transparency I am referring to a person not needing the full context of your experiences to encapsulate enough information to understand what they happen to be reading. In essence, they are not clouded by the lack of context and misshapen form.

The transparency is critical because it functions on the assumption that code Never Dies, but people do (somewhat morbid, but you get my point). Somewhere along the line you will move on and someone else will have to pick up what you do. Even in a project itself, where work is handed from person to person, whether that be developer to tester or business analyst to developer, the same rules apply. You can never certain that you will remain somewhere forever. Also, you can never be certain that you will always retain the depth of context that you held at that moment that the note was originally taken.

Due the size of big and complicated software projects, I believe that as people we soon reach our input limit when it comes to absorbing things everyday. We need to be diligent about how we place context around the forms we create everyday. The lack of this transparency erodes the structure of a project and acts essentially like a fungus. I have felt that slightly squishy and uncomfortable sensation at my fingertips each time I have come across a bug where the tag line was Error: 0 and the description was empty knowing that the developer who logged it has since left.