This is the second 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.
“There are many possible answers to questions you might have and the best answer is not immediately or easily available. It is a situation that is complex enough to require the assignment of a specialist…(engineer, developer, architect, software tester, etc.)…to assess the question and organize recourses as necessary to find an answer”. Software exploration
Several years before the turn of the century my role as a user required me to take a closer look at evaluating software that was to be “Euro giro” ready. Looking back now it was then that the foundation for my software testing mind-set was initially formed. At first I was being a typical unconsciously incompetent user and thought testing is actually nothing more than doing what I always do but only on new software. Nicely following Dunning-Kruger’s initial success made me feel I was on the right track. After a while the IT project manager nicely added some perspective to this by having me execute some ‘real’ test cases which all miserably failed on some features that I before had found acceptable. Now being consciously incompetent I took some time to study a few software testing practices and got some advice from in-house software testers. Soon I was able to deliver nicely scripted test cases, report on coverage and test results against acceptance criteria. For a user I was doing nicely and since most other users disliked the extra activity next to their regular work I was happy being the departments’ acceptance tester on and off for a number years.
In 2004 the department I was working for faced a major reorganisation and I was told that I was among the 40% of people eventually either re-assigned or laid off at some point in the next 24 months. I chose not to wait for someone to tell me how my future would be but contacted HR myself and requested to participate in a job reassessment program. Around a third into the program I realised that the software testing part of my work was probably what I had liked the most in my current work so why not do that as an actual career. Luckily for me right then and there an opening to become a software tester at our IT department was available and three interviews and an assessment later there I was ready to step into my new career.
Learning traditional testing
I started with a four-week master class which included getting TMap and (eventually) ISTQB certified, learning testing techniques, test management and real testing of Tax Office software. Being primed I felt that now being consciously competent I was ready to take on any software that would come my way. Boy was I in for a number of quick disappointments. First applying test techniques to actual documents and software was much more difficult than applying it to any training material I encountered until then. Second I was spending a large amount of time on writing about testing and not actually doing any testing. Doing a Product Risk Analysis still seemed pretty useful but making a 50+ pages Master Test Plan, Functional Acceptance Test Detailed Test Plan, Integration Testing Detailed Test Plan and User Acceptance Test Detailed Test Plan, Test Stage Reports, Final Test Report and a Release Advice absorbed at least as much time as testing the product. I could, and still do, to some extend understand that you want to assure that no steps are missed or lightly discarded but every document turned out to become a copy paste ritualistic window dressing exercise without much added value. I still loved the software testing and started looking for ways to cut corners on documentation and still tell what the stakeholders wanted to know. I moved towards more agile projects and enjoyed the more active approach of working together with developers, business analysts and users and appreciated the shorter feedback loop. Even so I was still searching to find a better way to test software.
Becoming a software tester
October 2009 marked a turning point with Immune IT organizing a Cem Kaner Week. I participated at the last presentation in which Cem spoke about Exploratory Test Automation and afterwards gave away signed copies of Lessons Learned in Software Testing – A Context-Driven Approach. This got me thinking. Software testing is not a separate activity in software development. Software testing is an part of software development and by bringing skilled testers into the mix it can help to produce better software on the one side and deliver meaningful information about the quality of the software on the other side. Yes you may identify different roles, skill sets and specialisms but only the complete set of activities joined, executed concurrently and in awareness of socio cultural and behavioural dynamics delivers a potentially successful software solution to a business problem. To me this means that I do not only need to know how to apply testing techniques, to understand software but I also need to understand how personal and business needs and wants translate into explicit and implicit requirements. How participants in software development use and translate these requirements. What the choice of development approach means. How software interacts with people. How they make decisions. How to convey information, etc., etc… In my opinion the only holistic approach to software testing that takes this whole diversity of attitudes and environments into account is the approach as described in by Context-Driven Testing and the fast amount of articles and presentations of its followers.
More than a practice
Context-Driven Testing is more than just another practice. To some part it is a paradigm, a school of testing. To a larger part it is an approach to software testing, of how to do your work and finally, at least to me, to the largest part it is a community of testing practitioners sharing experiences, ideas, problems, and solutions through blogs, (peer) conferences, workshops and by challenging each other on their views.