How to deliver a qualitative product

The mind-map I'm posting, has been created by looking back on different projects and consulting different colleagues, including my wife, the best Business Analyst I've ever seen. It is most probably not complete. But I think it is ready to start sharing it.

The idea behind this mind-map is to focus on key aspects required to deliver a qualitative software product of considerable size and how testers can contribute to obtain a higher level of quality of the product to be delivered.

If a tester wants to contribute to quality, they can do more than testing a product when it is delivered. Testers have many other duties during software development. They know the product and project in- and outputs and are aware of their risks. They understand the changing business needs and their explicit and implicit requirements. They challenge the architecture and analysis, coach developers and acceptants to check their delivered product effectively on standards. They facilitate in environment and data preparation. A tester understands and contributes to the release and deployment mechanisms. 

Planning & Control

It is the testers job to:

• Take part in the project planning and approach; challenge the planning
• Look into the processes and challenge them in function of quality delivery
• Find dependencies and flag them up to project/programme management
• Understand the test requirements and build a log of them
• Advise on test tool selection in function of the budget, timeline, experience and test requirements.

 Design

It is the testers job to:

• Understand the product needs and rationale behind the project
• Test the designs and architectural models and point to their weaknesses
• Find and report flaws in communication patterns and stakeholder involvement
• Coach acceptants in the definition of E2E prototyping test cases; lead them and help them in the  E2E test preparation. 

Delivery

It is the testers job to:

• Test, test, test, and automate tests
• Coach developers in checking against standards
• Contribute to and cooperate closely with deployment and release management
• Coordinate proper and clean bug reporting and the bug life cycle 
• Provide and manage the required test infrastructure.

Acceptance

It is the testers job to:

• Coach the acceptants in their verification and testing process
• Analyze and report test results in simple and understandable language
• Provide release advise
• Coordinate E2E test execution.

Communication

A tester is a great communicator. They understand the business needs, reason with analysts, challenge architects and managers and coach users and developers.

The Kick-off

Dear Reader,



Kick-starting myself into the world of possible readers, I find myself ready to write on what I think software testing is absolutely not about, definitely should be about and share how I experience my attempts to contribute to change. It’s time for the era of better software-testing.

As a kid I started testing on my first assignment with the TMap® and later the TMap NEXT® at my side. I wanted to learn all about the black box of software development and as a good boy, I absorbed, without a lot of questioning. Moreover, how could I think about questioning when being taught by Michiel Vroon and Rob Baarda themselves? I was genuinely impressed and learned mostly about the test design techniques and test phases.

It all made perfect sense to me: First there are requirements which get broken down into specifications. In a very good project they will even be broken down into a technical design. When this is all done, coding can start and then everything gets tested in different test levels, each of them having their test cases designed according to the documents available. When the testing phases are over, we go live... Doesn’t that sound like a V-model? (http://www.waterfall-model.com/v-model-waterfall-model/)

It’s like building a house, in fact. First you come up with a plan, the architect makes a blue print, the master builder makes a plan and the house is built in phases, starting with the foundations…

… but wait a minute… when is the house tested? After the last construction part is done? Actually while building a house, testing takes place within every development phase. For example, the foundation is verified when walls are being build. Then why do testers only test when it’s actually too late? And what if the living room didn’t really look like we hoped it to look like during construction? What if we, living in France, bought cheaper power plugs in UK, who will notice and when? … You know where I’m getting at, I suppose. Software development is not like building a house, nor it is like building a car, it’s mostly like software.

Things are often not as easy as they look like. Therefore the V-model, like any other model has disadvantages

• In the V-model requirements don’t change within the development life cycle – Unfortunately even if they don’t change, our language is still too primitive to formulate an unambiguous complete requirement that is understood in a perfectly similar way by all stakeholders and involved parties. Or in other words, let’s accept we’re human.
• Mistakes are only found when all development is already done – No requirements or any other spec is verified up until the moment that all development is done and a go for testing is given. That's too late.

Now, unless you work in the army or for the public sector, the currently most recognized documented best practices and methodologies for testing are difficult to put to actual use. That is mostly because in your project you don’t have a complete industrialized process and/or an immense budget available. The V-model doesn’t really offer the possibility to change your mind or make mistakes during the development lifecycle and requires high discipline on top of that.


I do have to recon on the other hand that it’s easy to plan a test phase 3 months in advance, hire 15 testers to write test cases. Most Project or Program Managers understand that those test cases always go straight to the recycle bin before they actually get executed. They do however like a pro-forma report with execution rates, preferably linked to the amount reopened defects of priority 1, to go to the developers and show them, having the proof in hands that their development is crap and that they are buying time.


Now I hope to all find you nodding heads, agreeing with what I’m saying, but guess what, lots of us are testing in this kind of structure that really does not make sense.
So why do lots of us work in projects that are run like this?
- I know: Because people want things that make sense, that are easy to explain.
Then why does this non-sense make sense?
- It doesn’t. What makes sense is that a V-model makes a complex world look easy and people want easy things
So what can we do make this testing (and project) world a better place?
- Find a way to test that is easy to explain and understand, does make sense and, most of all, really works.


In this blog, mostly, for now, I will describe my frustrations of testing in the European Hemisphere, my inventions and ideas to improve testing and relate with other professions in the project development landscape.
And most of all, I will try to contribute to the common sense in testing.