Context-Driven Testing

People wonder what context-driven testing is, so I figured I’d liberate the text directly from the Context-Driven Testing website and lay it out below followed by a little contextual commentary from yours truly:

The Seven Basic Principles of the Context-Driven School

  1. The value of any practice depends on its context.
  2. There are good practices in context, but there are no best practices.
  3. People, working together, are the most important part of any project’s context.
  4. Projects unfold over time in ways that are often not predictable.
  5. The product is a solution. If the problem isn’t solved, the product doesn’t work.
  6. Good software testing is a challenging intellectual process.
  7. Only through judgment and skill, exercised cooperatively throughout the entire project, are we able to do the right things at the right times to effectively test our products.

I am of the firm opinion that there are no magic bullets.  “Best practise” in one case is not best practice in another, in much the same way as there no universal Truths or “One Truth Way™”.

Even though I am an introvert, I enjoy working in teams with fellow focused, often geeky individuals who also enjoy their job as much as I do. Anyone who has worked on even one IT project of any description (or watched one from the sidelines) will know that unpredictability is a common hallmark of them.

Coming from a science background I’m all for asking questions, seeking answers, drawing conclusions, testing them out and challenging myself and others. If you don’t find software testing to be an intellectual process you’re probably Doing It Wrong™.

Judgement, skill, careful thought and effort are all part and parcel of the process of shedding blood, sweat and tears that make up life in general, work in particular and testing quite specifically.

Who can test my site?

The above question appeared on Quora, a question-and-answer site that I’ve come to love over the last few months. Now given that I love testing stuff, I couldn’t possibly pass this one by, so here is my answer, reproduced below for posterity. I’ve tweaked it a little bit here and there, but it’s essentially the same answer.



Short answer: Me! I’ve worked as a Software Tester for years, mostly on websites, web applications and the occasional mobile app.

Longer answer: Define “test”.

My own definition is that:

“Testing is a process to gather as much useful information as possible for the stakeholders.”

So, by asking me to “test your site” do you want to know:

  • That it functions as intended?
  • Everything that it can do? (This is not necessarily the same as the above)
  • That it is usable?
  • That it is accessible to those with disabilities, be they mental, physical or both?
  • That it works equally well across different web browsers? (Some handle JavaScript better than others, HTML5 is less of an issue now.)
  • That it is equally usable across different web browsers?
  • That it looks the same across different web browsers?
  • That it functions well and looks good on a range of different mobile devices?
  • That any APIs in use function as they are supposed to?
  • That any information gathered, stored or transferred is secure and complies with relevant data security and privacy legislation (such as the Data Protection Act)?
  • That any databases connected to the site are secure, well designed and appropriately normalised?
  • That Cookies are delivered to users and behave as expected and intended?
  • That the site performs any functions quickly enough?
  • That the site can withstand increased loads of traffic? Incremented slowly up, spiked, or sustained loads?
  • That failover systems work correctly?
  • That data backups are being performed properly?
  • That the disaster recovery plan is effective and up-to-date?

All of the above will provide useful information, although some will be more useful than others.  All of those questions will involve testing the system but they will require a vast array of different methods, tools, techniques and skill sets. If you want Security Testing or Penetration Testing done, I’ll introduce you to a man I know who will do the job far, far better than I can. Likewise Accessibility Testing.

If you want your website tested for functionality, browser compatibility and to determine not just what it should do but what it can do than I can offer you my services as an experienced Exploratory Tester who uses context-sensitive testing methods to do the most testing with the least exterraneous processes and documentation, so you get the biggest bang for your buck.

Anarchy in the AST

I’ve just finished doing exactly the same course. If I can adequately muster my thoughts on this, I’ll do my own write-up in due course (no pun intended). I think Geoff’s post is a great summation of it.


 This week I completed the Association for Software Testing’s “Black Box Software Testing — Foundations” course. (That’s a mouthful and a half.) I’d intended to weigh its merits beside those of the ISTQB’s “Foundations” course, but this is going to be a straight review instead, occasionally using the other for contrast.

First Impressions

Initially I found the BBST course to be massively overwhelming. The welcome email leads to Moodle, where there are all kinds of forums, tabs, documents, and links.  Students are buried in information and unread forum posts. Once I figured out where my weekly assignments were, I was able to get going. ( assignments are helpfully listed on a spreadsheet, because presumably EVERYONE is confused by the Moodle set up).

I started pulling 4 hour days, something I was able to do because of training time provided by work.  It was clear I wasn’t going to do all…

View original post 981 more words