Agile Zone is brought to you in partnership with:

Anne Botha entered the IT industry while studying at university by starting her own company, doing software development and business support. After completing her degree she worked at UCT, lecturing web development. After two years, she joined a software development company as a quality assurance engineer. She gained valuable exposure to industries ranging from retail, recruitment, financial, property and document management solutions. She has worked with both proprietary and open source technologies. She developed and managed quality assurance practice within the company and built up the test team, whose work coverage runs over 15 different projects with both local and international clients. Anne has posted 5 posts at DZone. View Full User Profile

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

  • submit to reddit
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.
Published at DZone with permission of its author, Anne Botha.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Paul Cox replied on Mon, 2008/07/21 - 1:59pm


This stuff is music to my ears. How many "chapters" are you preparing?

Anne Botha replied on Mon, 2008/07/21 - 6:49pm in response to: Paul Cox



This stuff is music to my ears. How many "chapters" are you preparing?



Thank you! I am glad that you enjoyed the read. I have 10 chapters in mind with a particular theme for each.  

James Imber replied on Tue, 2008/07/22 - 9:30am

Great stuff.

May be people don't take these meeting seriously. May be they don't understand its purpose and think that, in the end, if they don't like the software, they'll ask it to be changed later on...

Alex(JAlexoid) ... replied on Tue, 2008/07/22 - 4:01pm in response to: Anne Botha

A really nice "log from the other side". I was a bit dissapointed at the end of the first one. Because I thought it was unfinished, but since you are wriing 10 of them, it puts everything into a whole new perspective.

Anne Botha replied on Tue, 2008/07/22 - 9:49pm in response to: James Imber

[quote=im-james]Great stuff.

May be people don't take these meeting seriously. May be they don't understand its purpose and think that, in the end, if they don't like the software, they'll ask it to be changed later on...[/quote]

Sometimes the business user get squeezed between the challenges and workload that they need to deal with each day and what happens is that when the user review meeting comes along, it tends to take second place. I have more than once walked into the office of the planners and they complained that they just didn't have time.  What concerned me was that I got the impression that the time in those sessions aren't accounted for when performance review is done. I.e. No compensation is given for the time that they in fact loose when it comes to reporting back on work deliverables. 

Slava Imeshev replied on Wed, 2008/07/23 - 1:26am in response to: Anne Botha


These are all good points. No meeting is better than an ill-prepared meeting. The good news is that conducting efficient meetings is a teacheable art:



Slava Imeshev

Cacheonix: Distributed Cache for Java



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.