This is my blog in the series “Why am I Context-driven”. In this series every member of DEWT writes a personal story on why he or she is context-driven.
Officially, I started with testing in 1997. Looking back to my career, I can say I started with testing when I started my professional career back in the eighties. All the jobs I did before 1997, I had to deal with some serious test work. I only did not realize I was doing that. That period perhaps made me the tester I’m today. I always look for problem situations, look for situations where things could go wrong, how the system did behave at that moment.
I learned testing from 1997 to 2003 by just using common sense. Next to looking where things are okay, I looked for problem situations. In that period I was working for a large telecom network systems provider and we were testing network systems and network solutions. We always had to introduce errors in the environment and look how the solution reacted, responded. We found some serious problems in these days.
I kept on going with this mindset for all my test assignments with other companies. The time I started as an independent tester, I needed to take care of my own education. I decided to go to conferences. There I came in contact with people like Michael Bolton, James and Jon Bach at STAR East in 2007. What they were talking about got me interested. Perhaps this was the push in the ‘right’ direction.
I got in touch with CDT when I registered for the CAST 2011 conference. This conference was organized James and Jon Bach with the theme “Context Driven Testing” and it was an epic event. Some of the presentations given there were great. Markus Gärtner gave a presentation about self learning that really triggered me to do more with my test career. I was already working on improving my testers skills, but that were certificate focused classes instead of skill training. From the moment I left the conference, I said to my self: “I want to be a context driven tester. What do I need to do?”
I joined Twitter to follow the stories of other testers. I started reading blogs and books. I tried to find means to use CDT at my work. That was not easy sometimes as I worked in an environment with classical trained people focused on processes with pre–scripted test cases and pass/fail graphs. Luckily, the projects I did, I was able focus on what was really important in the context of my stakeholders.
Let me give an example of a project I did some time ago. It was a replacement project. The development team wanted to built software using SCRUM. There was only one strange thing they wanted. They wanted to deliver the software to my acceptance test team in three big deliveries. My reaction to this was as follows:
“If you want to do Scrum as a development approach and you deliver the SW in three big deliveries to me, each containing 8 features (i.e. data streams for billing and fraud systems), why are you doing Scrum? I want for every feature a separate, dedicated delivery plan.”
The next question I got from the project team was, “what is your test plan, how many test cases do you have?” After some discussion I told them, “I have one test case. I want to see that the data stream on the test environment produces the same output compared to the production environment.”
By having this attitude, I convinced my stakeholders I was serving them well.
As a tester I look for solutions which serve my stakeholders. I learn new practices which are useful at that moment risking I will never use them again. That is a risk I’m willing to take.
Further, I share my experiences with people I meet at conferences and/or via my blog.
I like to end with a few lines some of you probably recognize (if you are a Trekkie).
Space, the final frontier
These are the sessions of the context driven tester
Its unchartered missions
To explore undiscovered areas
To seek out for bugs and new information
To boldly test where no one has tested before
I hope you will join me on my journey.