Author Archive

I did like Michael Bolton did…

After talking to Micheal Bolton over a really nice dinner together with some of my closes test colleagues and reading his blog post ( I did the same thing as him, for lets call her “Maria”.

Maria is frustrated over the frequent deliveries that they do. The test team have to do the same things over and over again for every release; prepare for test run, update environments, run a set up of automated test suits and manual suits as regression test. This doesn’t leave a lot of time for Exploratory testing, good bug investigation or deep testing to find new bugs. It’s also kind of boring with such a repetitive way of working. To get a good overview, a grid like the one Michael Bolton wrote about was used and then another one showing what it could look like if the cycles were every second week instead of every day.

   M = Meetings
   Div = Misc
   P = Preparation
   S = Set up test environment 
   T = Execute scripted tests, incl bug investigation
   ET = Exploratory testing
   R = Test report


What a typical month looks like today, with daily deliveries (1 square = 1 hour):

Over one week is spent every month to just update environments!

And almost 2 weeks are spent to test the same things over and over again… and we all know that regression test isn’t the best way of catching bugs.


This is what it could look like with delivery every second week:

This sure looks like a more fun way of working for a tester.

I’m not saying the daily deliveries are wrong. There are reasons for why organizations do that. I’m also not saying the testing is bad. The testing is done risk based and the most critical issues are caught. My point is that by making it more visual it can be easier to understand the price for doing frequent deliveries. One may reconsider this decision when it’s so obvious what the cost is. I would also like to add that the best solution might not be to stop doing frequent deliveries but to automate the whole testing process (including update test environment).


This is a very easy way of visualizing what you spend your time on. It only takes a couple of minutes to do and it only takes a couple of seconds for your stakeholders to understand.



I have a dream…


”I have a dream where people look beyond waterfall steps and agile manifests.
I have a dream where scripted testers and exploratory testers are living together in harmony.
I have a dream where testers stand up proudly and talk about their job and progress.”

From “The Supertester – A Slightly True Story”


The last couple of years, I’ve experienced two sides within the test world being formed. One side that is for scripted testing and ISTQB and then there are those who are against ISTQB and completely into exploratory testing. On test conferences and seminars I’ve heard test guru insult “the other side”. Those who are for ISTQB are narrow-minded academics that spends way too much time on statistics and administration, which is a completely waste of time and of no use at all. What is a certification about anyway? Is it really a proof of a skilled tester? The others, the ones that are into exploratory testing, they are fuzzy, unstructured and count on gut feeling way too much and they just laugh science in the face. But, who is right?

I don’t know who’s right but I know what I think. No one! Those who’s right, according to me, are the ones not taking sides, but sees the advantages of both approaches, pick the cherries and uses a little from both sides.

Below we can see a fairly typical picture for describing scripted testing and exploratory testing. The picture shows a scale where one can do more or less of the two ways of testing.

At previous workplaces of mine and also as a consultant I have had the privilege to see different organizations and projects and it is only at one single occasion that I’ve seen pure scripted testing. There where one person who was responsible for designing and writing new test cases but also updating them. The test team consisted of a couple of testers which only task was to execute test cases and report bugs. We ran a complete function test every week. It’s the same with the other side of the scale. I only experiences 100% exploratory testing once. We worked according to Scrum and all new development was tested with exploratory testing. The regression tests, on the other hand, were a kind of scripted test (the test steps were not that limited, especially when it came to test data). At all other projects and organizations I’ve been to, testing have been a mix of techniques and approaches. The test cases are completed parallel with execution, some test cases are very detailed and others invite creativity to take full advantage of the testers’ experience. Do I then feel that the tests have been better or worse at some particular place? The organizations that succeeded to pick the best parts out of several methods and found a harmonious mix, are the ones I think have had the best quality, the best control over their work and orderliness. They also had the most satisfied test team, which was proud about their work and gladly embarked on new bug hunting adventures every day. The places I feel didn’t work well at all, are those where management had to nag about some particular method/process every week and they had to force the team to use this process or some fancy tool, but all these stuff didn’t fit the products worked on or the personality of the team members. These organizations spent a lot of energy discussing why/why not to use this particular method and this steals a lot of focus from the day to day work and no one gets any peace or inspiration to perform some really good work.

Another aspect that I have been thinking about is the testers’ personality. Not everyone is suitable as exploratory testers. I think most people agree that they don’t, but is it then right to limit the title “Tester” to solely creative and imaginative persons? No, I don’t think we should do that. We are all different and that’s something we should take as much advantage of as possible. There are people that love documentation, accuracy and that manages, well even enjoy, repetitive tasks and possesses the ability to keep the same focus and commitment the first time they run a test cases as the fiftieth time. Both personalities are worth a lot so why not use them both.

Just think of Thorkil Sonne and his “Testspecialisterne” (test consultants diagnosed with autism). Here it just doesn’t work with exploratory testing. So, don’t they do a great job then? Sure they do! In the right situation, with suitable tasks, they do hundred times better work than most of us should have done. They are needed. But everyone can’t be like them, then a lot of test scenarios would be missed, where exploratory testing might be the only way to find them. One part of testing is about predicting situations and then imagination and exploratory mindset is very valuable. Without that our tests would be limited to requirements and documentation and then we probably would miss serious bugs and issues.

No, both sides are needed! Stop fighting and do something really good together!


” All those easily charmed project managers who try all new cool methods and tend to forget everything they ever learnt in school or in previous projects. All scrum fan boys who read the agile manifest saying that no one ever more needs to document or follow a boring process! All administration nerds that documents for months and months in their  waterfall projects with all the dead fish floating down the waterfall with them and all those theoretical brain heads that memorized all the answers to the ISTQB-certification. And still no one has a clue.”

From “The Supertester – A Slightly True Story” by Linda & Anna Hoff