Introduction: Exploring the Power of Logical Thinking

Being a tester requires a whole mix of skills. Nowadays, it requires as many soft skills as it does technical skills. For example, a tester should not just have the ability to find defects, they should also have the ability to present their findings and ability to solve problems.

One incredibly important attribute a tester must have an aspect of logical thinking or an ability to think logically. 

'LOGICAL THINKERS' EXERCISE

The university is holding a technical recruitment fair for its students, with a number of companies attending, with jobs on offer for both developers and testers. In order to help the students, the university has prepared a set of information packs.

One box contains information & a keyring labelled ‘Tester’, second box is labelled ‘Developer’ and the final box has information for both, ‘Tester’ and a ‘Developer’. 

The problem is that, the Student Guidance Councillor has mixed up the contents.

Each set of boxes contains the same set of information and keyrings but no set of boxes contains the set listed on the box, i.e.

• The boxes labelled “TESTERS” do not contain tester information and keyrings.
• The boxes labelled “DEVELOPERS” do not contain developer information and keyrings.
• The boxes labelled “DEVELOPERS/TESTERS” do not contain information and both keyrings!

All boxes labelled “TESTERS” contain the same set of contents, likewise the boxes labelled “DEVELOPERS” and the boxes labelled “DEVELOPERS/TESTERS”. 

Using your logical deduction powers, please comment below what is the least number of boxes you need to open and in what order do you need to open them, to determine the contents of each set of boxes.

No cheating!

=============================================================

When you have your answer, read on: 

As a tester, the first thing we need to do is review the available information so that we understand what we are looking at. Indeed, how can we test if we don’t know what it is we are testing and what we are testing for? 

In this case, we have a fair bit of information to go on. We know that there are three groups of boxes, (Developers, Testers, Developer/Testers) and that each group of boxes contains a set of items (information and keyrings).

We know that the set of items, each box contains is not the set stated on the box.
So first of all, we can determine what is NOT in each box.

• Set A is labelled Testers, so cannot contain JUST tester keyrings.
• Set B is labelled Developers, so cannot contain JUST developer keyrings.
• Set C is labelled Developers/Testers, so cannot contain BOTH developer & tester keyrings.

A chart of contents might look like this: 

Having drawn the chart, it is now easier to see what might be in each box.

As box C can ONLY contain a Tester or Developer keyring, (and not both). We can see that if we open box C first, we can determine what it actually contains.

It does not matter what it contains, the logic works regardless. So for the sake of this exercise, let's say we open it and it contains a Developer keyring. We can then redraw the chart with this new information: 

Having established the box that only contains Developer information and keyrings, it's an easy task to see what is in the other boxes without the need to open any more.

If box C has the Developer content, then box A cannot! So let’s redraw the chart: 


If not only Tester or only Developer, then Box A must contain both sets of information and keyrings. Which means that Box B has the Tester content.

This was a simple exercise but it does illustrate some important points regarding testing. 

The ability to be able to follow a logic trail, often scattered across different sections of a document or ever across documents is very important. For example, spotting a contradiction in requirements where the specification has separate requirements that individually make sense but when looked at as a whole, it cancels another one out.

Particularly, if the conflict exists in different design documents, worked on in isolation, spotting the logic error in the review stage can save a lot of costly regression and remediation work, later in the process.

Another test-related lesson from the exercise is the need to maximise the effect of your effort. With testing time often being squeezed due to late delivery, over testing is a luxury few can afford. Why spend time running two tests (like opening two boxes) when a single test can provide you with the results you need. Being able to follow the logic and explain why you only need to run X number of tests rather than Y can help mitigate the fears of risk adverse organisations who are stuck running unnecessary exhaustive test, simply because it makes them “feel” safer.

The final lesson for testing that I want to comment on is the need to allow time to reflect on the subject under test. In the exercise, the immediate reaction of may (including myself) is to say, let's just open two boxes - it's quick, it's easy and it gives me the answer I need and in truth, sometimes that would the expedient answer.

However, without allowing enough time to contemplate the test, review the approach and approach problems, important elements of the system can be overlooked. In the long term, hundreds of needless tests could be written and executed. Easier time focusing in preparation often can pay dividends in terms of more accurately forecasting the time required for testing and more efficiently executing the required test.

So, the rational conclusion is testing requires logic - how did you do on the test?