Things you can do while waiting for a testable product

A project manager gets most nervous on the moment a product (part) is about to be released to testing. Finally someone will tell them something about the quality of the product that will be delivered. In the time before the big moment arrives, they want you to carefully prepare, doing useful things like for example

• Prepare (preferably thousands of) detailed test scripts based on functional designs 
• Deliver a detailed (re)planning of all test activities over different phases and environments 

There are however, other useful things you can do while waiting for a product to be released.
Those might not be directly required by your PM, but you'll benefit from them later on the critical path.
This list is not exhaustive as exhaustive lists would be exhausting.

• Talk to business users and analysts. Ask them about what they think is important, ask them how business works. Create your high level business End to End test scenario's in a workshop. Compare those End to End scenario's with functional designs and requirements and deliver your first gap analysis results. Explain your test approach to business users and analysts. The end to end flows can give you a nice way later on to report back to business on your test progress in a way they will all understand. I'll come back to this later on in a specific blogpost. 
• Talk to developers. Ask them about the programming issues and re-used components. This can save you some time later on. There is a reason why development will deliver late... Agree with them about the defect template and the procedure... that you want to keep as pragmatic as possible. 
• Read trough the analysis documents and identify high level test cases. Make note of inconsistencies and communicate about them on a regular base. These are very likely places where bugs can be found if not taken into account. It's perfectly sane behavior for a tester to make some commotion if you're not listened to during this moment in time. 
• Challenge the Architectural picture with what you learned from the business users and developers and read in the documentation. Make again note of inconsistencies and communicate them. 
• Create a high level overview of all test activities that need to take place. Agree with all parties that will take part in testing and find inter-dependencies over the available test environments. Find out which test activities can be run in parallel. Find out when, most likely, data resets will be required. Verify when other test activities in the environments are planned. Get to know your testing neighbors. 
• Define your reporting structure and agree with your PM and business. Use some visible examples. Make sure everyone understands that metrics are not the only thing they want to receive. Try to be creative and present visual, simple reports and arrange the possibility to have meeting to explain your status. 
• Train your BA's and other non-testers who will be joining in testing at some moment in time. Your mission is to make them become better testers. Tell them why writing all possible variations for a field validation test is an endless activity. A tester will have endless amounts of test cases to test one field but might only execute some for which the product will likely manifest bugs. You could tell them something about Boundary value analysis, data combination, paths, about focussing and defocussing, the tea-test and the shoe-test. 
• Make sure you obtain access to the test environment(s) with the correct user roles and assess if all infrastructural components, required to start testing, are in place. 
• Test the test data backup and restore process. If you have the possibility, make a proof of concept. 
• Prepare your assessment on entry criteria if required and give your development team a heads up on where they are in function of your entry criteria. In this way they won't be surprised when you need to give them a no-go to deploy in the test environment. 
• Test the deployment and release procedures. 
• Implement required test tools. 
• Reassure the PM, they are nervous and need some support.

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.