YAGNI

Context

At the time of this blog post my family and me are on holiday in Iceland. Since we are not that often in Iceland we, amongst visiting relatives and friends, use the time to look into administrative and regulatory stuff that is easier to do in Iceland than from abroad.

Syslumen

One of the things necessary is to renew my wifes passport. For which you actually need to physically go to the Civil Registry, or in icelandic ´Syslumen´. The process of renewal is (boringly) straightforward. At the office you get a number, wait, identify yourself and pay for your renewal, get a form, wait, identify yourself again, hand over the form and update your data (including new digital photo and fingerprint), sign and wait for a couple of weeks to pick up your passport at the Civil Registry.

Except

Since we´re only on holiday in Iceland a couple of weeks of waiting is not a real option. So to amend this my wife investigated and proposed the solution to sent the new passport to the consulate in our country. An option, once validated by the team lead, that was acceptable to the civil clerk. And thus the proper check box was looked for and found.

Into the process

After filling in the personal details instead of the offices address the address of the consulate was needed. The page itself did not offer any listing. The help page wasn´t really helpful either as it only pointed towards a government listing at another department. After some searching the consulate in Amsterdam and its address was found and the data could be entered. So everything was entered and the OK could be clicked. Nothing happened. Looking over the page the clerk found:

Færðu inn lögboðnar reit (Please enter mandatory data) next to a field asking for Póstnúmer (Zip code) that had been left empty as it had also been empty on the government listing. So what to do? My wife and the clerks colleague suggested to google it. And so she did. The zip code was entered and again the OK was clicked. The intranet page jumped back to the entry page and everything looked okay. But the clerk rightfully noted that the usual confirmation message was not shown and checked my wifes file. To her, and my wifes surprise no data was added, meaning the whole 20 minute worth of data was absent.

The process repeated itself a few times and eventually another colleague noted that the zip code contained letters. Something not used in Iceland itself. Why not leave those out of the field and move them somewhere else, say in front of Amsterdam. Now when clicking OK the confirmation appeared and a check showed that the file now contained all the data.

YAGNI

Even with only a couple of thousand Icelanders living abroad chances that they live in one of the eight countries (e.g. Canada, Great-Britain) using alpha numeric characters is realistic especially since many more countries use the country abbreviation in front of their zip code. So when my wife returned to tell about her plight she commented: Clearly neither the developer nor tester thought this field was important. But it really bugged me today. Further more she noted The same software company maintained the government listing and had all the zip codes removed, leaving empty spaces in the listing. That´s even more stupid.

Clearly someone must have convinced the developers and testers “You Ain´t Gonna Need It” (YAGNI).

Seven Questions – What will I test?

In the previous post I addressed why you test. In this post I will address what you are going to test. In the sections below I will hand you a number of ideas. Some of them are well-known in main stream testing and other may be a bit more out of the box to some of you.

Requirements

I think I am not exaggerating if for most testers and stakeholders covering the written requirements with test cases still is what you as a tester should do. This line of thought is more generally known under the title of Requirements Based Testing. As a definition this could be described as:

Requirements-based testing (RBT) process addresses two major issues: first,
validating that the requirements are correct, complete, unambiguous, and logically
consistent; and second, designing a necessary and sufficient (from a black box
perspective) set of test cases from those requirements to make sure that the design and code fully meet those requirements

Followers of this approach do admit that requirements, or rather documents, are hardly ever complete and that testers almost never have the possibility to design and execute all possible tests. This last insight is the foundation of an approach called Risked Based Testing (or sometimes called risk and requirements based testing). You can find more information on it here, here, and slightly more hidden in here. But personally I like this   interpretation of risk based testing, by J. Bach, best.

A major advantage of risk based testing, and in my opinion essential in finding out what to test, is that it is based not only on documents as a source, but that it is based on people as a source of information. People are a major source of requirements and especially of requirements that matter to them. Documents can tell you a lot, but people can tell you what’s missing in them, how to give meaning to them and therefore paint you a more complete picture.

A good source of information, besides risks, that people can also give is how they current software or the manual operation that they use to solve the problem now. Often this will be the basis for the acceptance criteria that they formulated, or that you will formulate together with them for the new software. Acceptance criteria are useful to give direction and focus to your testing and are mandatory elements in the structure of your testing report.

You the tester

Finding out what to test is not only about bringing the subject under test and its information to you the tester. It is also about what you bring to the subject. What knowledge of the domain do you already have? What test ideas or mnemonics do you know that are useful in the context of your subject?

Sources for Test Ideas and mnemonics

The list below has some online sources you can use and fit into your situation. Use them, adjust them and come up with your own ideas.

Test Cases

There are many definitions for a test case. My personal one is: “A test case is the execution-able version of a test idea. A test case aims at gathering information about the test ideas relation to the subject under test and the value of that information to the stakeholders.” If and how much of a test case is (pre-)scripted is based upon personal preferences, the test idea itself and the context in which it is executed. Attention should in any case not go towards the quality of scripting of a test case, but towards the relevance and value of the information that is delivered by the test case.

Designing test cases, scripted or otherwise, takes skill and experience. I therefore believe that as a start a good tester should have a base of test design skills and a testing mindset. As a start I would like to recommend the following literature:

  • TMap Next (Chapter 14) – Tim Koomen, Leo van der Aalst, Bart Broekman, Michiel Vroon
  • Lessons Learned in Software Testing – Cem Kaner, James Bach, Bret Pettichord
  • Essential Software Test Design – Torbjörn Ryber
  • What is good test case? – Cem Kaner

When working on test cases there are a few principles that I like to keep in mind. The DRY principle. DRY stands for “Do not Repeat Yourself”. If test cases draw their value based on the information they offer it is not useful to use variations of tests that do not deliver new information. This principle does have a catch as you do not always know in advance if a variation does or does not deliver new information or not.

Separation of concerns is another principle that lets you focus your attention upon some (single) aspect. This does not mean that the other aspects are ignored. It means that you address the subject under test with a singular point of view, deeming the other’s irrelevant at that point in time while not forgetting that relationships might exist.

Finally I am always interested in mentions like “You Ain’t Going to Need It” (YAGNI) or “No user would do that” popping up in any design discussion between other team members. The areas discussed are an interesting area to start investigating.

This concludes this third post of the Seven Questions series.

Seven Questions – Why do I test?

Reasons for testing

The question why something is tested has kind of a schizophrenic nature to it. Its answer is either so obvious that the question itself is ignored or it is so cumbersome that testers rather avoid to answer it. The latter is mostly the case if testers have to defend why testing is done in the first place. I cannot provide you with ready made answers for this, because the answer depends too much on the circumstances and context of your situation. What I can tell you is that it is worth while for you to figure out why your specific subject under test needs testing. If you can answer this for your specific situation, then the contextually acceptable general answer should be able to be derived from it.

What to take into consideration?

One of the more common ideas on why software testing is conducted is that it’s done to find bugs. The idea is that the fact that you do or do not find more then a certain amount of bugs in time is a measurement for release readiness. Obviously such a amount of bugs doesn’t say anything about how serious the remaining bugs are nor does it say anything about the bugs you did not find. Already more than 40 years ago Edsger W. Dijkstra (1969 p.16 and 1970) discovered that software testing can show the presence of bugs, but never their absence .

Another reason to do software testing is that there is some internal or external reason to do it. A standard, law or regulation exists that either states that you have to test or whose interpretation makes management believe that you should do tests, often in a certain predefined way, to meet the rules. This is not a bad thing as an external reason for testing.

A better, more internal, reason for testing is that the software is tested to provide information. Better still Information that is meaningful with regard to the product itself, its intended use, its real use, its potential (miss)use and related to the value this has to which stakeholders.

Your Challenge

It is your challenge as a tester to find out what the information is that the stakeholders value. Then extend this with the information they should value, even if for reasons thus far unknown to them. And finally to find a way how to provide that information so that its relevance and value is delivered to them in a meaningful way.

With some well-directed extra effort the value of testing can grow. Both to the tester and to the stakeholders.

Finding the right reason

Way back in 1998, with the introduction of the Euro to the financial markets I came in contact with software testing for the first time. As a business acceptance tester I was responsible of judging whether the new programs actually had the desired functionality and if we could work with them. Especially that latter part had the focus of my attention. Being one of the users myself and being involved in the requirements design of the product I found it easy to understand why this had to be tested and what value to look for.

More often than not software testers are not so familiar with the everyday practical needs and demands of the product they are working on. In this case I have two approaches that I prefer to use and that have served me well in the past. The first is to approach testing heuristically, with for instance the Heuristic Test Strategy Model,  and explore the product with helpful mnemonics like FEW HICCUPPS . The second approach is to converse and to keep on conversing with the stakeholders and ask them all they need to know.

Who else would know better what matters to them than the people who matter (to the product and/or the project) themselves.

Why do I test, summarized.