No Computer?

After attending one of Gojko Adzic's inspirational seminars, The Chief sent an e-mail to all testers in the office. A key point at the seminar was that "testers shouldn't be testing - they should teach testing and help identifying risks with the developers while designing, etc". The e-mail contained a single, though-provoking, question: "Could you do an entire sprint in your teams and maintain quality – without computers?"


I wrote the following reply, which relates to the role I'm currently in, but I'm curious about how this works in other places;




"First off, what do we do during a sprint?

· Release testing – checking core functionality while keeping our eyes open for regressions in a soon-to-be-released version
· Improving the automated test harness – Jbehave tests, etc, to minimize the amount of future manual regression testing
· Testing new features – poking and prodding, making sure the developers have covered all angles
… I think that roughly covers it, though each bullet is of course more fine-grained.

I would claim that the release testing would be most difficult without a computer – at least right now. Depends on how fast we make progress on the second bullet.

I would also claim that improving the automated tests would be difficult without a computer. Yes, we could compose test descriptions on a piece of paper and have someone else implement them. Semantics, perhaps, but sure – the tester part of that task is doable without a computer (the rest, then, is pure coding).

More interesting is the last bullet, the cognitive action of “testing”. The common approach, I suppose, is reactive – we read a requirement, wait for it to be implemented, try it out in a test environment and look for bugs. The alternative, then, would be to switch to a more proactive approach and catch the bugs at the design stage by analyzing requirements together with the developers, agreeing on an implementation and “pair program”, if you will, to be able to assist with unit and integration tests to ensure that the code is well-written the first time ‘round.

Consider the traditional test levels;
· Component tests,
· Component integration tests,
· System tests,
· System integration tests,
· Acceptance tests

They exist because we expect, traditionally, to find different kinds of bugs on different levels. If we switch our focus from system tests & system integration tests, where we currently work, to the design phase & preventative work … well, I’m afraid we are going to miss out on the bugs that appear when putting the system in a realistic user scenario, together with all the other bits, pieces and test data. This is more true, I believe, for the parts that have an interface to an actual human user. I wouldn’t feel comfortable, at least, to let them go without having seen (and tested) them with the eyes of a user.

This is the reason, I assume, that we have employed a session-based way of testing – to be able to analyze and critique the finished product and find the irregularities that show up when everything is connected.

I’m not sure how the “teach testing” weighs in … yeah, we could design tests from our models and requirements and have someone else operate the test environment and execute the actual tests while we monitor and mentor (without, literally, using a computer) but I guess that’s not really the point.

So … could I do an entire sprint in my team and maintain quality without a computer? Sure, but someone else would have to do parts of my job on a computer. So, in reality, no - not really."

Could you do your testing without a computer?