Why I love testing on projects derived from prototypes

Ok. Over years I've noted that Testers rarely blog about projects they really enjoyed and more importantly why that was so. Yet when I look back and analyse some of the common characteristics in my project history, it has come to my attention that those which applied prototype development are right up there as some of my best.

My definition of prototype development is probably not what you'll find in a textbook, and I'm sure my readers will differ in their opinions. However for me, it's a trial run (sometimes to production). It's having something which has look and feel, something which demonstrates concepts, something which illustrates functionality, and something which has already gauged an active community as to it's usefulness and effectiveness. As a Tester, I cannot think of a better basis for gathering knowledge, defining risks, gaining high level understanding of scenarios, and setting the foundations for genuinely understanding requirements as they are being specified.

In a previous blog I've mentioned how I would much prefer to commence early learning about a system in development rather than to await documentation. I'm like a kid in a candy shop when a Developer trusts me enough to do this, which is mostly the case other than when the working environment just doesnt get it and spoils the party (that's for another blog!)

For a switched on Tester, getting a free pass to a Developer's sandpit is an awakening that genuine engagement in QA has commenced. It's an early insight into the building process and a real-time specification of the roots of what will eventually be a final Production version. It's an empowering activity which allows all key stakeholders to partake in validating objects, fonts, colours, workflows, speed, integration, and so on. It's collaboration in its' most effective form, and one which draws on a Tester's creative side to explore boundaries, conduct ad-hoc experimentation, gather notes, and contribute to requirements elicitation. I'm a non believer that a detailed specification must always follow a business requirement (full stop). Instead, I'm a big believer that an in-progress specification (ie prototype) can follow a business need which then applies back to an improved need (ie to the ultimate requirement). In other words, we're talking about a flexible, continuous, improving process (some might call this Agile :) ).

In promoting the above methods, perhaps I have presented a somewhat negative view for waterfall styled, formal process which requires Testers to wait for official documentation. However that's not my aim. I'm simply highlighting that it was in these types of projects where my biggest attributes as a Tester emerged. It was where I gained expertise earlier and so I found problems earlier and built up my value to the team earlier. However these projects also resulted in delays from their original deadline, required multiple releases to production, and created headaches for management looking after budgets, schedules, and resources across multiple projects. Hence I must concede that I view my success in a project not by whether it goes in on time and on budget, but whether I was influential on the end user needs being met to the utmost quality. I also concede that in referring to the "User" need versus the "Business" need I'm neglecting the importance of those aspects which are crucial to management.

I truly wish I could break protocol and share with my readers details about which projects I succeeded in based on these principles, and which ones I didn't. At least this would let me settle the air with those who have managed and are managing me. It will give them another opening to this brain of mine! 

A lot of related thoughts have also come to mind on this topic which are probably blogs in their own rights. For example:

1) Prototyping can get really messy when Testers are not involved

2) Testers will fail if they rely solely on a prototype and not on the emerging product encompassing endorsed documentation.

3) Moving towards a more Agile SDLC is no coincidence - it's what works (when done properly) and it's what Development and Business prefer.

4) Prototyping when the team is not located in the same building or when there are third parties involved is dangerous.

5) Prototyping or making a project Agile so that documentation does not have to occur is also dangerous!

Well this was my 5th blog, I hope you enjoyed it. I'm getting a few hits out there now so don't be shy with your feedback. :)