Checklist for testing a numeric field

When testing, there are both interesting tasks with intricate logic, and simple ones, like checking a simple string or a numeric field. For simple fields, you can write a checklist of checks once, and then reuse it, just slightly changing it to suit your own field.



Today we will analyze the checklist for a numeric field. First, I will write a general checklist, then we will go through each item and figure out why it is needed, and at the end we will write a checklist using this template.



So, we have a certain field where you need to enter a number. For example, the field "age" when registering:







At the same time, you cannot register on the site under the age of 18, there is prohibited content.



What checks can be done here:

1. Valid values
2. Incorrect values (outside of valid ranges or illogical: 200 years, 88 seconds ...)
3. Boundary values
4. Boundary values
5. Fractional number - format (separated by commas and periods)
6. Fractional number - rounding (with a bunch of decimal places)
7. Zero
8. One
9. Empty field
10. Very large number (search for technological frontier)
11. A negative number
12. Non-numerical and non-numerical values

Putting It All Together - Example: Age Checklist .

Well, where to practice - try it yourself!

Valid values

Imagine that you literally have 5 minutes to test the functionality. And you only manage to carry out the first few tests from the checklist. And you have a checklist:

• Empty field
• 0
• -1

As a result, these checks were carried out and you think that the system is working fine (well, it swears!). And she always swears, even on the correct value! Not good ... Therefore, we remember the rule:

ALWAYS first positive, then negative!

See also:

Positive and Negative Testing - Learn more about where to start

For a field with age, what are the correct values? Anything over 18 years old:

• eighteen
• 25
• 38
• 45
• ...

Here you need to understand that we are choosing some ONE value. It's just different every time to avoid the effect of the pesticide.



It is also important to understand that we may have more than one correct value. This is when we have several ranges, and different conditions on each.



For example, the same age:

• if under 18 - show all products in the store, except for cigarettes and alcohol
• if over 18 years old - show all products at all

Then we realize that we already have two "valid" ranges. So we need to take a value from each. For example, 16 and 26.







Or if we are calculating insurance depending on driving experience:

• 0 - 1 year - 1000 rubles
• 1 - 3 years - 800 rubles
• 3-5 years - 600 rubles
• 5-10 years - 500 rubles
• 10+ years - US $ 3.00

It turns out 5 intervals. And we need to take one value from each. For example: 0.5, 2, 4, 6, 15.







Each time we take different values, but in this paragraph the meaning is the same - to take the correct values ​​from the TK.

Invalid values

There are different options here. What does an incorrect value mean?

• outside valid ranges
• correct from a computer point of view (number), but meaningless (200 years)

Let's go back to the age example. The correct value is over 18 years of age. So, we must ask the question:



- What happens if we take a value from the “wrong” range? What if I'm under 18? Well, let's say, 10.







Then we carefully look at the selected interval:



- Hmmmmm, but age cannot be less than 0. That is, we have a logical boundary separating two different equivalence classes:

• Possible physically, but invalid according to TK (0 - 17 years old)
• Physically impossible (0 or less)

So you need to take a value from each range. Then it turns out 10 and "-5":







We think further:



- If we have a certain logical border from below, there must be above. What is the maximum possible age for registering on our site? Most likely, it is about 55-65 years old, because the older generation does not like computers. But you can lay down the conditional 100-110 years of centenarians.



We get one more interval with an implicit border. But in any case, the values ​​25 and 145 will differ - one is realistic and the other is not. So you should try it too!







And then again the effect of the pesticide. We take 145 once and 6666666 the other.



Here we may face the fact that more than 2-3 characters cannot be entered in the field. The developer was reinsured "from the fool". This is not a reason to give up and give up your check. Because most likely the developer just set maxlength on the field, and it's easy to get around!

See also:

How to remove maxlength from all form fields - several ways to note ツ

Boundary values

Boundary values ​​separate one interval from another. They must be tested !!! Because it is at the borders that bugs are most common. Why? Because they fall into both ranges, or do not fall into either.



In our example, the TK has the condition “registration only for persons over 18 years old”. This means that the developer must make the following logic in the program code:

• IF x> 18 THEN register
• IF x <= 18 THEN we give an error

If the developer forgot to add the value 18 to one of the ranges, this may not result in an error. Because in such cases the if else construct is usually used. And the developer puts the last "else" just in case - that is, if SUDDENLY the entered value did not fall into any of the conditions above:

• if x> 18 ...
• elseif x <18 ...
• else ...

But if the developer added the value 18 to several ranges at once:

• if x => 18 ...
• elseif x <= 18 ...

Then the program will be at a loss, what should it choose? And it may well fall!



In general, bugs are more common at boundaries than within an interval. Therefore, be sure to research them! In our TK there is a clear border “more than 18 years”. So, we are testing the number 18:







If we have several intervals according to the TK, we check each border separately. These are arbitrary boundaries - which TK imposes.



But borders are of different types:

• Arbitrary
• brain teaser
• Technological

Arbitrary checked? Let's go further. Logical is all about that obeys logic (in a minute 60 seconds, a person cannot be “minus one year old”, etc.). Let's apply it to our example.



Boundary from below:



- It is logical that age cannot be less than zero. So 0 is the border. Testing!







Boundary from above:



- Nuuuu ... Hardly age will be more than 35 years. Although what prevents grandmother from accessing the site? Maybe 65? 88?



It's hard to find the border here. It is easy to take a value from the range “I don’t believe it too much”, but there is no specific border. Hence, there is nothing to test. There is no logical border at the top.



I put the search for the technological frontier into a separate item, so we will return to it a little later. In any case, this is less important than reconciling the valid boundaries that are in the TK.

See also:

Types of Boundaries Using a Washing Machine as an Example

Why Test Boundary Values



How to Find Boundaries on the Client and Server

BMW Mnemonics for Finding Boundary Values

Boundary values

If we have a border, then there are border values. And they also need to be checked!

In the age example, the boundary is 18. So the boundary values ​​are 17 and 19.







Why check the boundary values? Yes, then, that the developer could make a mistake in the code and indicate the border a little not there.

if x > 18 …
↓
if x > 17 …

If our border is shifted, and we do not test border values, then we can easily skip this bug. After all, we checked:

• border - 18.18> 17, so everything works
• the invalid value from the range on the left is 10. 10 <17, so an error was thrown.

We conclude that everything is working correctly, although it is not! So be sure to check the borderline values.



But is it necessary to test border values ​​on both sides? With 17 sorted out, you need. And 19? Let's say the developer has sealed in the other direction:

if x > 18 …
↓
if x > 19 …

We will find this bug by checking the boundary value 18. And if it works for 18 and works for a number within the range (for example, 26), then the code is written correctly. That is, so that there is a bug in the code, it’s how to be perverted, write something like:

if (x == 18 or x > 21) …

This can only be done on purpose)) Well, if you count on a foolish developer with evil jokes in the form of such Easter eggs, then you just have to do a complete bust. So let's consider colleagues as adequate people.



But! What if a developer describes how the code works for multiple intervals? Then, if a typo occurs, the ranges overlap:

if x <= 19 () …
if (x > 18 and x < 55) …

The number 18 will not catch the error, because 18 <= 19, and it does not fall into the second range. So there will be a situation that works at the border, works within the range, but does not at the border value.



So if there is no access to the code, it is worth checking the borderlines on both sides, otherwise you never know where the typo has crept in there?



The matter becomes even more interesting if you can enter not only an integer number, but also a fractional number in the field. What then will be the borderline value? It is worth starting with one decimal place. In our example, these are 17.9 and 18.1:







Ok, let's say we checked:

• Whole borders - 17 and 19
• Fractional boundaries - 17.9 and 18.1

But if such values ​​round off normally, does that mean that others will round off well too? What happens if you enter the value 17.99999999999 (there are 11 nines after the decimal point, and the result of rounding is to hit the border)?



These are different equivalence classes if we are talking about fractions that will be rounded:

• One decimal place
• Many signs

And it's worth checking out both! So we add new tests: 17.99999999999 and 18.00000000001

Fractional number (format)

If the system allows you to enter fractional values, then we check them in step 1, when testing the correct values. We just break down the concept of "correct number":

• Whole
• Fractional

And we break down the item "fractional" further. After all, a fractional number can be written through:

• point - 6.9
• comma - 6.9

If one of the methods works, it does not mean at all that the second will work! I even have an example of two calculators that work with fractional numbers in different ways - http://bugred.ru/calc/ .

See also:

Do not write "Enter 6.9" in the bug! - analysis of bugs in the calculator

So we need to make sure that both methods work. At least if they are supposed to work. If only one should work, because standards prohibit the use of the other - check that the second returns an error!



In the case of age, what is the positive fractional value? Most likely half - for example, 20.5 years old:







Have you checked it? Working? Then we look through a comma - 20.5:







The fact that fractional work in principle has been checked. Okay.

Fractional number (rounding)

Of particular interest are values ​​that are close to the cutoffs, rather than any fractional values. When approaching the boundary at a distance less than the computational accuracy, we can get into a situation where the validity checks of a value pass successfully, but the computations fail.



So if you can enter a non-integer number, be sure to try many nines after the decimal point, close to the border of the value (we already did it with the point above):







It makes no sense to check rounding through both a period and a comma. This will be unnecessary duplication of tests. We check separately:

• format - separated by period or comma
• rounding - when one or many decimal places

See also:

In testing, we always start simple! - why you shouldn't mix checks

Zero

We always test zero. And everywhere. Just remember this as an axiom. Simply because there are often bugs in zero.



Because this is usually the border. It can be explicit (spelled out in the TK) or implicit (it is not written in the TK, but it is clear that the age cannot be negative).



If we are talking about a numeric field, then we try to enter the number 0. Although, of course, "zero" in testing goes beyond a prime number.

See also:

Zero-Not-Zero Equivalence Class — Learn more about testing zero, and not just numeric fields!

One

Since we always check for zero, we do not forget about the borderline value - one.



In fact, this is usually the "minimum possible value", if we are not talking about fractional values:



- It is logical that if we place an order, we buy at least 1 book, or 1 dress, or 1 kg of flour ...

- The minimum age is 1 day / month / year

- Minimum amount of time - 1 second

- Minimum amount of work experience - 1 day / month / year

- ...



So one is no less a magic number than zero. We check it too!

Empty field

In fact, this is also a zero test. Only not by the number "zero", but by zero in the length of the input string.



After all, if we enter "0", it turns out one character.

And if we are studying the length of a string, it is worth checking not only one, but also zero .



Remember that zero is not just a number. Even in a numeric field, we will have at least two zeros - an empty string and the number "0". There may be more zeros - do not forget about the zero in the output. But in our example with age, it is not.

A very large number

A very large number must be entered to find the technological frontier. For example, 9999999999999999.







We're trying to get as far as possible. But not too hard - it should be one test, well, two.



First, you can start from the integer value - most often this data type is chosen for a numeric field. If you manage to exceed it, just check 25 or 45 nines in the field. Didn't fall? Well, weird. There is no technological border, but at least we tried to find it.

See also:

How to generate a large string, tools - you don't have to do it by hand))

Technological frontier in legal tips - an example of a real bug

If the field allows negative values ​​to be entered, then we check “many nines” with both a plus and a minus sign, conducting two tests:

• 99999999999999999999999
• -99999999999999999999999

Let me remind you that if you cannot enter many characters in a field, this is not a reason to give up and say “the technological border cannot be checked!”. Because if you cannot enter many characters in a field, there is most likely a maxlength per field, which is easy to get around. We removed the restriction on the client and made sure that the server also has foolproof protection.

See also:

How to remove maxlength from all form fields

How to find borders on client and server

A negative number

When we have a number, we always remember that it can be:

• positive
• negative

At the same time, from the experience of interviews I conduct, I can say for sure that few people think of the check "and if you enter a negative value." But the system can work in different ways:

• give an error “there is no such age / quantity of goods, please enter a positive number”;
• cut off the minus sign and treat a negative number as a positive one.

This is in addition to the fact that a negative number can be quite normal for the field (for example, if we are saving income / expenses).



What are we testing in this section?

• What happens if you enter a negative number, which will be correct in modulus: -26 in our example
• Trying to find technology boundary: -99999999999999999999999

Non-numerical and non-numerical values

If you think that to check for a non-numeric value, it is enough to drive in any string like "hello", then you are mistaken)))



Lines can also be different, and they can be split into:

• many strings that the program interprets as numbers;
• lots of strings that the program cannot interpret as numbers.

Tests for "not quite numeric" values ​​are very well covered in this article: Equivalence classes for a string that denotes a number



I won't rewrite it completely, just add to the list of checks for our example. What we haven't seen yet:

• Definitely not a number - "Test"
• Leading zero - "025"
• Space before the number - "25"
• Space inside the number - "2 5"
• Writing through e - "1.2e + 2"
• Hexadecimal value - "0xba"
• Boolean - TRUE / FALSE (can be interpreted as 0/1)
• Infinity (yes, just like that in text and we write)
• NaN

In our case, with the correct value of age from 18 years, the item "space within the number" becomes more interesting. It depends on the logic of the system. There are different options here:

• Swear if multiple words are entered
• Cut off everything that comes after the first space - "2 5" → "2"
• Remove the space and pretend that it was not there (perceived as a typo in a number) - "2 5" → "25"

Likewise with letters. The system can swear when it sees them, or it can just throw them out. So let's see the new test options:

• up to space less than 18 years old - 2 5
• up to a space of more than 18 years - 25 6
• after a space of text - 25 test
• before space text - test 25

Please note that in the interface we simply enter some value without specifying the data type. But if we are testing the REST API and the json message in it, then we should definitely try to pass the number in a string:

• number: 3
• number: “3”

These are different meanings. If the unquoted value is a number. If quoted is a string, even if it looks like a number. Maybe the developer will cast the types in the code and "accept" the second option, or maybe not. Worth checking out anyway!

Putting it all together: age checklist

Ideas for tests were written down, each was discussed. Now let's put all the points together and write a checklist for our example.



Let me remind you the condition - we have a field "age" when registering. At the same time, you cannot register on the site until the age of 18, there is prohibited content.







When drawing up a checklist, we take into account all the points that were discussed above. But let's not forget about priorities. We always start with the basic checks, and not with "hammered in zero, a negative number and generally tried to break it in every possible way."





* If 18.000000000001 works, then there is no point in checking the integer 19. If fractions are not accepted by the system, then yes, we check for 19



Of course, checks from the block "non-integers" are not super-important. Sometimes you can and should score on them. Especially if we know that the system should not analyze anything, remove spaces, discard text and so on ... Then it is enough to take one value from this list. And the rest to use for the effect of the pesticide, that is, every time a new version of "not a number".



But in order to cut off the excess, you must first learn how to generate a lot of ideas! This is what we practiced with you today =)

See also:

Cheatlist for a numeric field in Strainer (you need to log in)

Where to get ideas for tests (a selection of useful links)

Try it yourself

Write a checklist for the “Driving experience” field. Insurance is calculated depending on the length of service. All intervals on the left have the number "inclusive", but on the right they do not.

• 0-3 years - 1000 rubles
• 3-6 years old - 700 rubles
• 6-10 years old - 500 rubles
• 10+ years - US $ 3.00

The form does not allow you to enter anything except numbers (this limitation is on the client). Fractional values ​​are unacceptable, how many full years of experience we have, so we write.



PS - for more useful articles, look at my blog under the tag "useful" . And useful videos are on my youtube channel