Geekly Articles each Day
📜 ⬆️ ⬇️

Patterns and antipatterns of task justification

Content



When you start a task, you need to justify it. You must convince the developer that:


And sometimes you read bugs (especially newbie bugs) and ask yourself a question:

- Why is this a bug ??
')
For example, it says: “Download the report, we get 57.6. And it should be - 57.9 ".



If you write a rationale, this will solve the problem:


See also:
Why do you need a justification in the bug - in more detail about why justification in general.

Hundreds of novice testers (students) passed through me. That's just on their tasks, I began to wonder: “Why is this a bug?” ... You ask the guys, and in return you get, “Yes, this is obvious!”. Well, somehow not very =))

Through a bunch of tasks and “why?” Questions, response patterns began to emerge. I identified good and bad patterns. I want to tell about them.

This article is for:


1. Antipatterns: poor rationale






1.1. Obviously


Why don't testers write a justification in a bug? Yes, because they think it is obvious. And they project their thoughts onto everyone. It is obvious to me = everyone knows why to write something?

But in reality this is not so, because every person is in some kind of context. And what is obvious to you is not at all a fact that it is obvious to someone else.

Let's look at simple examples. Read the word that I will write below — what did you think when you read it? What associations come to mind?

CASTLE

A door lock or a huge stone fortress?

MARRIAGE

Wedding or broken iPhone?
...

Yes, they are homonyms. But they very clearly show the problem "it's obvious." It is obvious to you that the castle is a lock, and to me that it is a castle.

And if you are writing in a bug:

Result
57.6

Expected Result
Obviously, there should be 57.9

That it does not answer my question at all "WHY?" What does "obvious" mean? Explain to me, please. It is not obvious to me, otherwise I would not ask again. But the author is obvious and he thinks that all too.



If we talk about the experience of beginners, then one of my students formulated this idea best of all:

“I didn’t understand why to justify bugs at all until I read the bugs of other students”

It can be a very long time to say that “obviously” is different for everyone and I am not in your context, and much more ... But the author of the task will consider that they are simply finding fault with him, it’s not clear to the others, but he is fine!

And just reading other people's bugs, you start to think, “Hmmm, why does he think so? I've thought differently. ” It is then that the understanding comes that your "obviously" is obviously not for everyone.

Once I went to the bug tracker and saw such a bug from a student: “We enter the name Sharipat, it is defined as male. But it should be like a woman's! ” Why should both feminine? I look at this name - well, Sharipat and Sharipat look like a man's. I'm asking:

- Why do you say that? Why female?
- Yes, because my wife is so called!

And now this at least explains to me why he started the task. When we test applications, we first try simple data, familiar things to us. We try our name, the name of the wife, brother, sister ...

He tried to enter the name of his wife and found a bug. And if he even wrote in the expected result: “The gender is female, this is a female name - my wife's name is that,” then at least the question “Why did you start this task at all?” Would disappear from me.

Of course, such a justification is not enough. Googling "unusual names", because it’s not even forbidden to name your son's Bedside Table, but is it worth considering this word as a correct male name?

So what do you need to google, what are the names at all, localize the problem - the problem with Russian names? Kazakh? Ukrainian? Should the system be able to handle them? And so on. Maybe not a bug at all ...
And yet “my wife’s name is so” at least allows the author to introduce us into his context and explains why he decided to start a task at all.

And remember - the evidence may be dictated by the context. You have now carefully studied the large module of the system, you know everything thoroughly. Therefore, it is completely obvious to you that "this chip should work HERE SO." But if you return to the task in a month or two, you will already be working on another module, and remembering exactly why this will be more difficult.

Even the dumbest pencil is sharper than the sharpest memory of the Internet.

When you start a bug, and the expected result seems obvious to you, stop and think: “Why do I think so?”. And write down the answer to this question.

1.2. Mom, I swear!


When a student realizes that he doesn’t write anything at all, “because it’s obvious,” he doesn’t go off, he goes on to the next stage of anger, denial, and justification of the bugs, which is called “I swear to my mom!” without explaining why.



That is, the rationale looks like this:

Result
57.6

Expected Result
57.9, because that's right

But such a justification again does not answer my question “But why?”. Why did you decide that so right? I'm still not a wang or a telepath, and I don't know why you think this is right.

In fact, this is not much different from the situation "did not write anything at all, because it is obvious." Therefore, I call this the second stage - it is precisely in this scenario that events usually develop, first “obviously”, then “yes, that’s just right”. Let's look at an example from the life of students:

Peter and the Indians

Our system is able to incline names by cases. The student checks the name of Peter. Do you know how it bends? In the nominative case, it is written through the letter E, and in all others - through E. “Peter, but Peter”.

And here I go to the bug tracker and read such a bug: “Peter leans over the cases through the letter , but must through e”.

I'm asking:

- Why do you think so?
- Well, obviously, that through E is necessary (the first stage)
“Why do you think this is obvious?”
- But this is according to the rules of the Russian language!
- What are the rules?
- Well, should I run and google the rules of the Russian language? (second stage - right, believe me)
- YES! Yes, that's exactly what you should do. Because it will be a justification of the bug. Because maybe your developer is a Hindu, and you are also a Hindu. And you do not know the rules of the Russian language! So give them a link, and all questions will disappear immediately.


Of course, there is no need to go to extremes and give links to dictionaries when you put a bug on a typo or a missing comma. And yet “Peter” is a non-trivial example, because this is an exception to the rules. It always works that way, but for Peter, it’s different.

Therefore, the link here is not out of place. Especially if the developer asked "Is it really so right?". You can blame him for stupidity and illiteracy and spoil the relationship. And you can give a link, gently confirming his point of view.

But ok, let's take another example, not about the rules of the Russian language, which are “so obvious”.

Email.rf

My students like to start this task very much (almost every stream is made out of it):

- I'm trying to register with email.rf and I can not. This is a bug!
- Why?
- How is it why? We live in Russia, everyone has such emails!

I told this case at the DUMP conference, and I had a full audience. I asked to raise the hands of those who have such an email. Of 200 people, three people raised their hands.

The fact that we live in Russia does not mean that everyone has such emails. Well, yes, yes ... And also tame bears and nesting dolls ...

There is no causal link, it’s just hard to give up your idea. After all, I found a bug! How can this not be a bug ?? So cool. Russia is obviously the same! No, not obvious? Well, anyway, Russia, there are a lot of such people.

Such a justification is more like “I am too lazy to google and search for facts. Believe on the word. When we do not have the facts and evidence, there is a desire to disguise their rationale and write "Probably, perhaps, for sure ...".



But these are STOP-words! If you have a desire to write them - it means that you do not have real facts. So you are just thinking out. And why do you need to do a task based on the fantasy of the tester? Prove your theory!

And if there are no facts? Then the task is not even worth starting. Yes, it is difficult to abandon "his, native" bug. But this, too, must be able to.

Email.rf - facts

What could there be facts?

Firstly, we can make our site for some state customers who are obliged to register in domain.rf. Corporate standard, they have no way out.

Or we really have a lot of such customers, statistics show that. For example, in the logs a lot of errors are “trying to register through such a domain”. And perhaps, then it is worth making this feature. In order not to lose potential customers.

Based on such facts, the RM (Project Manager) decides whether we will do the task or not. And if so, when. Or maybe say, “Well, there are mistakes, and okay, there are less than 1% of total registrations, we will not do”

Instead of the abstract “yes, there are such people for sure!” Cite FACTS.

And when setting the task, use principle 5 why. When writing down the expected result, ask yourself "Why am I expecting this?" The first answer will be “It's obvious,” but again ask the question “Why?”. And if you notice that there is no data, you just think so - look for the facts or discuss the situation with your colleagues.

1.3. Bunnies offended


If there are no facts, and I don’t want to give up the bug, students move on to the next stage of anger, denial and justification of bugs ... Pressure on emotions:

I'm trying to register with the name Cthulhu, but the system does not. Must give, but otherwise ... I was offended and left, and YOU! Lost customer!

And surely everyone is the same as me, so you lost ALL clients, and they also filed a lawsuit for an insult and took all the money!

And other cars ...



Of course, when I personally don’t like something, ignoring my problem is very angry. What does it mean “Normal people don't register with that name?” Am I crazy? As I want, I call it, how can you forbid me something ?!

And then the projection turns on - if I do not like it, then other users will not like it! If not all, then at least many. Therefore, this is definitely a bug and must be fixed. Well, or at least credited within the framework of training, if we are talking about students.

However, an offended user is the worst rationale that can be. Because they can justify any nonsense:


Anything can happen and hurt me. The button is green, and I wanted to red, the system did not offer me a pizza as a gift ... I, as a user, can be offended by anything. But who cares? All the same you will not please, insults are inevitable. And so be conducted on threats in general, the last thing.

It all started with one of the students, who said this intimate phrase:
- Oh, you do not want to register through the domain of the Russian Federation? And I, as a user, tried to register, saw this blatant situation, and DID! AND YOU! Lost customer!

Then my friend said that such speeches are very similar to “Bunnies are offended.” I do not know where she took this analogy from, but everyone liked it.

The student realized that he got excited. Went to look for the rationale without emotion. And we got the name antipattern.



Remember one simple rule - there should be no emotions in the bug!

Emotions are a passing phenomenon. You are now blazing with righteous anger and want to express it in snide comments like "only an idiot could write code like that." But remember any situation when a child is capricious next to you, making your mother hysterical about a toy that has not been bought or an ice cream. Do you, as a bystander, enjoy watching this scene? But your hysteria in the bug tracker looks exactly the same!

Therefore, if you really really want to - make it all verbally. Discuss the task in the smoking room with the developer, vehemently defending your position. But as soon as we reach the computer, we remove emotions, we write only facts. Without “if yes if” and without “but YOU! Lost a customer! ”

Remember that the tasks are returned after a year or two or three. And even then you will be disgusted to look at your own tantrum. The past emotions are no longer there, this is what looks funny. So the emotions are maximum verbally - in the smoking room! And in a bug somehow without them.



And in the justification we do not write about mega-offended bunnies. Sometimes this sort of upholding of a task is ridiculous:

The student found a typo in the user's offer. Put a bug with critical priority. On the request to clarify the priority was very indignant:

- The system deceived me, I can not trust her !!!

Probably he was worried that the question would result in “this is not a bug at all”, so he began to defend his bug. But no one is against it, that is a bug. But why criticized something? Who reads the offer at all?

- I am reading! Therefore, I see that the system is bad, if there is a typo, then what can it do? And how to believe her now ?!

But "I read" ≠ "everyone reads." And then the student himself admitted that he did not read carefully EVERY licensing agreement, which is slipped to us when installing programs. So with the offer the same story. So far so good, it is not read. If something is not pleasant, already address to rules.

However, “the system has deceived me and I cannot believe it now” because of one typo on the tenth page of the text that few people read ... Well ... Do not write this in a bug, do not make your PM laugh.

So, we remove the emotions from the bug. And what can we leave there? Of course, the facts!

Instead of writing on emotions, “bunnies will definitely be offended, leave, and you will lose customers”:

- collect statistics;
- Evaluate labor costs;
- calculate ROI;
- poll users;
- compare product with competitors;

And instead of hysterical proteins, you will become a cool tester who gets thought-out bugs!

2. Good reasoning patterns




How to justify the bugs correctly? What do you need to write in the expected result so that your bug is fixed the way you wrote? And they didn’t ask again 10 times “why exactly that way”?

Above we discussed three anti-patterns, let's discuss three good patterns of justification of bugs.

2.1. Pruflink


It may be:



Link to requirements

The easiest bug is when there is a TZ and the system does not work as described there.

So we write in the expected result: "57.9, because it is in the TK." Um, um ... Wait a minute. It sounds like “I swear mom” ...

Yes, in such a formulation it sounds like that. Therefore, confirm your words with a link. Otherwise, the developer reads the bug, and he needs to:


Is not it easier to leave only the last item? After all, the developer can work on 10 different projects, the documentation of which is distributed in 10 different places. His search for TK will take about 5-10 minutes, and adding a link for you is a matter of a second. After all, you are testing now for TK, which means that it is open and in front of your eyes. Copy the link and paste!

Respect the time of colleagues, and they will be grateful to you.

Requirements themselves

If the requirements are not stored in the confluence or another cloud system, but in a normal Word, attach the document you are testing with.



It is possible that you are testing outdated requirements. And if you attach a straight Word-file you are checking with, the analyst can see it and say, “Oh, wait, we changed everything 10 times, forgot to upload it. Take this!"

If you do not do this, then you will spend three hours disassembling with the developer, who will say “I’m different with me!”. You will run, watch his requirements, then yours, then look for an analyst, to clarify who is right ...

And so you immediately invested the requirements, the developer looked said, “something kind of garbage,” redirected the analyst. The analyst wrote them, and he, opening your Word, will immediately understand whether it is outdated or not. That's saving time!

Link to the Internet

As we remember, requirements are far from always. And instead of them maybe ... Link to the Internet! Yeah why not?

If we recall our example of “Peter, Peter”, then even if we have requirements in the system, it is unlikely that it says “The system works according to the rules of the Russian language” and lists all the rules of the Russian language. Of course, nobody writes like that. And it still turns out, if you want to refer to the rules of the Russian language, you will have to go and google them.

Or if you take an example from Sharipat. Again, where did you get the idea that this is a normal female name? We go google all sorts of Kazakh and other names, we find Sharipat, we find other similar names and give a reference to this page.

And here already, even if the developer does not agree with you, he can come and say - "Look, you gave a link to the site, but this is some kind of yellow press, they always write garbage." But if you don’t give the link, the developer will have to google himself, search for any websites himself, and only then he will understand that you may have attacked some false information. Save him time, give immediately a link to the Internet.



Yes, here you need to understand that not every link is useful and justified, but at least it will show why you think that this is really a bug. This is no longer “I swear by my mother”, but with a justification!

Customer's letter

The rationale may be sending a letter to the customer. We even have a separate field in Jir, “Business justification”, where we write down which customer requested this feature. And then, when we read our bug, we immediately see:

- Yeah, the business case is empty. This means that we ourselves have found this problem and believe that it should be corrected.

Or:

- Yeah, so the customer complained about the problem on August 1, 2015

And if we need to clarify with this Customer what exactly does not suit him, then we can easily find this letter, because we have all the information (who, when, the name of the letter). Knowing this info, I will go and find the letter in 5 seconds in my outluk. If this information is not there, then I will have to go to Outluk and search among 10 different daddies - which customer requested it and in which letter?

Moreover, if we see that this feature was requested by several different customers, then its priority immediately rises. Since we understand:

- Yeah, customer 1 complained then, in a couple of weeks / months the customer complained to another. Hmmm, but surely there are a bunch of other customers who also suffer, but are silent. Cry, inject, but continue to eat the cactus. After all, not everyone will write to us and report a problem ...



So the more complaints, the higher the priority. Since we understand that this is a real user complained, they really have such problems. And even if we return to the bug after six months or a year, thanks to the attached letter or at least a link to it, you can always raise the history of the task.

ROI

We can try to calculate ROI - payback ratio. Do we really need to make this feature or fix this bug? Will this have the proper effect?

One thing is to make a minor edit for half an hour of development, which will help hundreds of users. It is completely different - because of the hysteria of one user, two weeks to redo the work of the system, which suits everyone else.

If we calculate ROI and see that the game is worth the candle, we put the calculations into the task. But sometimes, after calculations, it turns out that the task is not needed. And this is normal! So we saved the team time to discuss an unnecessary feature.

That is why we think over the justification - because sometimes it seems “Oh, what a bug, what a bug!”

For example, we come to work with a mobile application, and there is a debug panel for testers, which looks like this:



Whoa whoa! There is a blue one, there is a red one, the text is not completely visible, the fonts are scattered ... An obvious bug! How did they not notice me? I urgently make out, I need refactoring!

How to justify? “What are you, if a user SUCH sees, then he will be offended immediately and leave.” Stop. Turn on the brain. This is a debag panel. It is for testers and developers, assistant in testing [2]. The user will NEVER see her. And if he sees, then THIS will already be a bug, and a critical one!

And the guidance of beauty ... But who needs it, is this beauty? New functionality is added there urgently and quickly. The tester comes, complains about the problem, the developer writes code on his lap. Works? Do not touch!

Nothing will happen to the tester’s sense of beauty, let him look for such bugs in other places. Because the refactoring of this panel can take a week of development. And it is very expensive. And for what? For the sake of beauty? Oh, its nafig, it is better to make the functionality for which the client will pay.

So they calculated the labor costs and realized that we already live so well, we should not change anything!

Statistics

Collect statistics and invest in the task:

- the number of errors in the logs;
- the number of complaints in technical support;
- the number of clicks on the button;
- the number of users who left at the stage of placing an order (closed the tab);
- ...

That is, if you think that the typical order form in the online store is “bad” and it needs to be improved - justify it. What exactly is it bad? The fact that to enter the address you need to know your index and fill in 10 required fields? Is it really bad or annoying only for you?

Consider that developers may not see the “obvious” in their software. After all, they developed it, tested it ... They see it constantly 100 times a day, they are already used to the interface. So even if it’s really outdated, facts are needed.

And the facts are easy to gather - please make statistics to see when the user leaves the page. And if he added pizza to the basket, and then started filling the fields and after 5-7 he spat and left, this is not very cool. And if every third person acts in this way - it is definitely worth improving something!

If you remember about email.rf, then you can look at the logs - and if there are any errors like “Attempt to register on such email is rejected”? Maybe they don’t exist at all, and we’ve already come up with a bunch of offended users, because of which the site has literally lost millions.

Why statistics are better than emotions? Yes, because we, IT professionals, and ordinary users are two different worlds. What is convenient for us is uncomfortable for them. And vice versa.



Suppose we do accounting software. It seems to us: “Fu, nobody works with the mouse, it’s necessary to make everything work from the command line, so that you don’t have to touch the mouse at all!”. We spend a lot of time on this functionality, but real users do not use it at all. Because they need a mouse to pick up a big button ... And what is convenient for programmers, they’re generally up to the bulb as it’s convenient for something completely different.

And if you want to tell everyone what users need, first learn usability testing, and then say whether the hare will be offended or not.

In our system, we collect anonymous statistics on what functionality is used and what is not. There are a lot of filters on the web form that are hard to maintain. Do they need them? You can not just take and remove, it is worth checking out.

So statistics are usually very surprising. We thought that this filter was not used at all, but in fact it was working every hour. And on the other they pinned high hopes, and nobody needs him ...

Only statistics honestly tell you about the existence of the problem. If there are no statistics, it will be just tastes. And everyone has different tastes. The tester wants the red button, the developer wants the green one, and the designer wants the blue one. So look for the facts and give them a proof link!




2.2. Uniformity


If there is no pruflinka, we can refer to the uniformity of the system. Because if the system always works like that, and then suddenly it works differently - it could well be a justification for the bug.

For example, if our system works as a puntoswitcher (this is when I type in Russian, forgetting to switch the layout, and the system switches it itself). I can type “Olga”, and I can “Jkmuf”, the system will turn the second option into the first one.

This happens on all sorts of state applications. They sometimes work on the same principle themselves. You must register clearly as in your passport. Since we live in Russia - registration is in Russian, so the English letters will be corrected. You obviously forgot to change the layout, man!

Jkmuf → Olga

Okay, but what if I try to type the name "Julia"? It begins with the letter U, and this letter does not correspond to the letter of the Russian alphabet, but a special character:

> → Yu

And this is a completely different equivalence class!

That is, if we understand that the system works as a puntoswitcher, we have at least 2 equivalence classes: there are Russian letters that correspond to Latin letters, and there are those that correspond to a special character.

These are completely different classes, they need to be checked! And perhaps, when we print a special character, the system does not recognize it. And then we start a bug - I type the symbol>, I expect that the system will translate it into the letter Y, but nothing happens. Why do I expect it? Because the system ALREADY works that way, because if I enter Jkmuf, the system will understand that this is Olga.

We show that the system already works that way, and this is already a good rationale. We do not say “I swear to my mother, she works like this,” we prove it on Olga.




2.3. The problem, or # life is pain


Tell us about some real problem user.

Because we are testers. Our task is to destroy and break, enter “War and Peace” in a short field, edit one entry in two browser tabs, and so on. And even if something is not working with us, this does not mean that the user will do the same.

And sometimes bugs are not fixed simply because “yes, no one does that!”. And that's fine.Why waste energy and resources on a problem that never arises?

This is especially true of problems with usability. As we remember, what is convenient for an IT person is inconvenient for a simple user. And vice versa! And it turns out that if we just write “Well, this is inconvenient ...” - this is a bad rationale, you never know what is uncomfortable for you, the rest is satisfied. But if we collect feedback from users, we attach their letters in which they complain to us, then this immediately indicates that such a problem really exists. And it already raises its priority.

The problem of a real customer is always better than just some kind of negative test from a tester.



This does not mean that testers never fix problems. If you have a problem, too, complain! Maybe the developer can help you in just 5 minutes, he just does not know the situation.

Testing a new feature, I cover it with autotests. The test framework has been around for a long time, we are used to it. Tests are similar to each other, so copy-paste - after all, we usually change one parameter of some kind, leaving the rest unchanged. This is the “1 test = 1 test” principle, so that the drop in the test immediately indicates the cause.

And here I need from autotest to autotest copy-paste parameters. And I have to dig them out from the first test to the second, to the third, to the fourth, to the fifth, to the tenth ... And in this copy-paste I need to change only 1 value in one line, and if I don’t do it, everything will fall apart from the terrible by mistake.

, , - … 30 , , NPE. , «, ».

, , … , . :

— , , . !

:
— , .

, ?!!!

Complain, do not be afraid! Maybe you are suffering, but the developer does not even know about it. And maybe he can quickly fix your problem, here and now. Or maybe not fix it, but suggest a workaround.

Of course, if the problem is one-time, or it’s too long to fix it now, the optimization task will go to the next release or further. But it is worth at least discuss "how this can be improved" and set the task. After all, if there is no task, no one will do anything.

There are different cases of problems:

- customer problem;
- the problem of a real user;
- the problem of the tester;
- a problem within the team;

Some are more priority, others less. And yet, if we describe a real case and a real problem, then such a task has more chances for correction than “obviously, it will be better for everyone”.

Yes, you need to understand that even if we describe how real users feel badly, this still does not guarantee that we will fix the bug, but such is life. In any case, if we at least describe the problem, it will be at least understandable why we have set this task at all. Even if we return to him in a month, two or three. We will always see why we thought that users feel bad and uncomfortable working with it.

3. When justification is not needed


Suddenly, isn't it? =)

Nevertheless, the anti-pattern "obviously also" has exceptions. We really do NOT need to write a rationale if the system:


Especially if it happened in production. If our site is lying, there is no justification, it is necessary to beat the gong and run to the developer “urgently fix it!”. You can do without a bug. And you can with a brief “Error 500 on the main one”, that's enough.

No need to suck the rationale of the finger, because "it is always necessary." To write "the system should not fall" - the text for the sake of the text.

But!You must write the expected result. Even if it seems obvious to you, write it down, it will not lose you.

Steps
Open example.com site

Result
Error 500

Expected result
Main page opened

Everything seems to be simple here - the main one does not open, but should. But there are more difficult examples.

For example, the developer made a formula from the TZ and somewhere there is a division by zero. If you just write “There should be no errors, the report is loaded”, the developer will still come to you with the question “How should it open? There is a division by zero! ”

You need to think it over and write “I expect that a report will open with such and such values ​​according to formula XXX” - as long as you think what it should be, you can discover the joint in TK. And then already ask the analyst how to.



So even if there is no justification, there is at least an expected result. And remember that this is an exception to the rule. The system should not fall and hang. However, such bugs are rare, and in other cases, the rationale should be.

4. Results


We discussed 3 antipatterns. Three steps of anger, denial and justification of bugs:

  1. Obviously - We are obviously not justified. And then we get “oh, I forgot why I wanted it so” ... It is obvious only to you, only here and only now. In six months, you’ll forget why. Explain how for the stupid that there is such an obvious.
  2. Mom swear so right! - Why swear? For some reason, you think that this is the right way, so tell me why. Give a link to the requirements, for example.
  3. Bunnies offended - "Oh, you did not add a cat to the main? All right!I was offended ... and GONE! And you! Lost a client !! ” But what is inconvenient for you may be convenient to others. So remove the emotions and bring the facts.

Instead, they should use the correct justification:

  1. — , , , ...
  2. — , -, !
  3. — , , ( ). , .




Be sure to write why we decided that this is really a bug and why we want to fix it exactly as we wrote here. We ask ourselves questions from the “5 why” series

- why I think that this is obvious?
- why do I think so right?
- why I think users will be upset?

We give links to requirements on the Internet, point out the uniformity, or talk about the real problem of the user.

And when you reread the well-formed tasks a year later, you will still say “Thank you!” To me ツ

Source: https://habr.com/ru/post/434522/

More articles:


All Articles