Context Driven Testing: A Different Context of Words, Words, Words…

Words are dangerous things. We think we know what they mean, but really I know what a word means to me. I don’t know what it means to you, and therein lies the problem. So many misunderstandings can arise, because I mean one thing, but what I say or write means something different to other people. In this case I want to talk about context in testing and why it matters.

Let me give a couple of examples. In our company we were recently having a discussion about discrepancies (the form that we use to raise a question or report a problem or instigate a change – in itself a possible source of confusion). One person wanted a new discrepancy type to be created for “observations”. In my context, this meant “something that had been seen that was wrong, but then couldn’t be reproduced” – maybe not the first thing that springs to mind, but it’s what it has come to mean for me. However, what this person meant by “observations” was something they had seen and were suggesting should be changed in a particular way. So the same word, same general meaning, but two very different particular meanings.

Context in Testing

In a previous company, the word “firmware” meant the code (usually VHDL) on a FPGA or similar device (don’t worry if you’re not familiar with these terms – it’s basically a language used for programming a type of integrated circuit). So when asked in an interview if I had done firmware testing, my immediate response was no. However, what the interviewer meant by “firmware” was what I called embedded software, the very thing that I had been testing for the previous five years.

context driven testing

Context Driven Testing…Sort of

So the meaning of words depends on the context from which we are using them, and how they are understood depends on the context from which they are read or heard from. Particularly if we are trying to communicate across contexts, we need to be very careful that our definitions of a word are in agreement. Even if words are written from a strict dictionary defined meaning, we cannot be sure that the reader will not have their own specialised meaning, that they impose on top of the dictionary meaning and so end up with an unintended result. Perhaps this is true of what I have said here – I can’t be sure!

About the Author


I graduated in 1984 with a degree in electronic engineering, but specialising in software engineering (there were few, if any, specific courses in those days). I then worked for 25 years in the defence/aerospace industry, for most of that time as a software developer, writing embedded real-time code in Pascal, ADA and C++. During that time, the software testing was done by the developer on their own code. In the last 5 years there I moved onto testing other developer's code, alongside other areas such as looking into software obsolescence. After being made redundant, I found that employers were not interested in my software development skills, as I had not been actively developing for over 2 years, so I applied for jobs in software testing. I started with a contracting post, again in the defence industry, testing code that had already been delivered! I then got a permanent post at my current company, where I have been for the last 5 years. Here I lead a team of 3 testers testing embedded real-time code on bespoke commercial devices dealing with RF, GSM, and GPS technologies.
Find out more about @mike-picken