Note for front-end: what to check before testing
Hello!
It so happened that I am from that same quality control service. Recently, our team wrote a big feature. Having reflexed a little, I decided to create such an article cheat sheet for front-end. It will remind you what you should pay attention to before transferring the task to testing.
Layout on prototypes .
')
It so happens that designers are beautiful elves from a high tower, and "they see it that way." And sometimes it’s easier to do it your own way than to follow the prototype. But usually these guys are on our side, and while drawing, they hold to the head (or on paper) some arguments why this is done in what value. And if it seems that something strange is drawn, you can always discuss it.
If something is impossible (read very expensive) to do - that’s what I must say. Very, very, very dumb to see fresh prototypes that do not converge with the fresh task.
Find N Differences. Prototype on the left.
All is well when the information on the site is static and unchanged. You can see in a pair of browsers and several resolutions. This will immediately find obvious problems and fix them before testing.
But everything changes when they are - input .
It is extremely necessary to enter in them everything:
About leading and trailing spaces.
They are not needed in 99% of cases, except, perhaps, only for passwords, but this is inaccurate. I had experience when the application crashed due to the presence of a space at the end of the login. It remained after copying the line from the mail. So: trim the spaces !
Just entering values is only half the story. In addition to saving, you must look at the display. Therefore, we check the appearance of previously entered data: styles, decorations, formatting, etc. Anything can go.
Check the same thing:
There are some live examples under cat.
Sometimes you can’t just take and enter what you want - validations work.
What to do?
We look at the list of validations and for each of them we make checks that she swears. Those. length restrictions, forbidden characters, input mask - all this must be checked and make sure that it works.
Hint: text can also be entered by copying.
I understand that the first reaction is some such.
You are lucky if you have few users of this marvelous browser. But if not, then alas. You will have to look at your work through the prism of alternative perception.
It's almost like with IE, but it doesn’t hurt.
If no custom metrics are collected on your project, then everything is fine. Otherwise, you have to do two things:
I briefly talked about what you should pay attention to when working with the front. These few checks will allow you to get a significantly better product at the output.
I would like to note that the article will be useful if you do not have a tester at all. Therefore, at the end once again a brief summary:
Q: Testers will find everything!
A: Not all. Testers - this is not a HEPA filter for you, but people. And if at the development stage someone did not do their part of the work, then it does not go anywhere, but simply passes on to someone else.
Caught up, but didn’t look? This means that other people will work with this, spend not only time, but also their strengths. A person gets tired, the eye is washed away, fatigue accumulates. And beyond the shaft of such problems, more serious things may be missed.
Also, do not forget that any game with ping-pong tasks only imposes additional time costs. It’s still necessary to finish normally. But early detection of problems speeds up the entire development process.
Thanks for attention.
It so happened that I am from that same quality control service. Recently, our team wrote a big feature. Having reflexed a little, I decided to create such an article cheat sheet for front-end. It will remind you what you should pay attention to before transferring the task to testing.
When you submit the final version of the product to the quality control service, you should expect that the control will not reveal any problems. It would be extremely unprofessional to pass a knowingly defective code to quality control. And which code is knowingly defective? Anyone you’re not sure about!
“An ideal programmer. How to become a software development professional »
Robert S. Martin
Where to begin?
Layout on prototypes .
')
It so happens that designers are beautiful elves from a high tower, and "they see it that way." And sometimes it’s easier to do it your own way than to follow the prototype. But usually these guys are on our side, and while drawing, they hold to the head (or on paper) some arguments why this is done in what value. And if it seems that something strange is drawn, you can always discuss it.
If something is impossible (read very expensive) to do - that’s what I must say. Very, very, very dumb to see fresh prototypes that do not converge with the fresh task.
Find N Differences. Prototype on the left.
Filling and displaying data
All is well when the information on the site is static and unchanged. You can see in a pair of browsers and several resolutions. This will immediately find obvious problems and fix them before testing.
But everything changes when they are - input .
It is extremely necessary to enter in them everything:
- Lots of text.
- Different text: letters, numbers, special characters, etc.
- Little text. Can I enter nothing and how will it look like then?
- Text of the wrong format or invalid text.
- For dessert: large lines with no spaces at all.
- Gaps: leading and trailing.
Hidden text
A typical front-end may wonder: how much text is how much? I have an answer to this: as much as fit into input. No length limit? You can enter 10-20 thousand characters and look at the result. Maybe your backend is not ready for such volumes? For a minute, 20 thousand characters - that's how much:
A4, Times New Roman, 12 point, line spacing - 1.
A4, Times New Roman, 12 point, line spacing - 1.
About leading and trailing spaces.
They are not needed in 99% of cases, except, perhaps, only for passwords, but this is inaccurate. I had experience when the application crashed due to the presence of a space at the end of the login. It remained after copying the line from the mail. So: trim the spaces !
Just entering values is only half the story. In addition to saving, you must look at the display. Therefore, we check the appearance of previously entered data: styles, decorations, formatting, etc. Anything can go.
Check the same thing:
- Large texts, with or without spaces.
- Texts with line breaks, paragraphs. Sometimes I insert poems for this.
- The minimum data set. Does everything remain in place when nothing or almost nothing?
- Display of not all fields from a complex entity. They may be empty.
There are some live examples under cat.
Hidden text
Long inextricable text comes out.
The text pushed the margins in the tablet after him.
Text Wrap vs. IE
An entity with many fields, but only two are used in the list. And this is how the unfilled fields look.
Just narrowed the browser window.
Long inextricable text comes out.
The text pushed the margins in the tablet after him.
Text Wrap vs. IE
An entity with many fields, but only two are used in the list. And this is how the unfilled fields look.
Just narrowed the browser window.
Validations
Sometimes you can’t just take and enter what you want - validations work.
What to do?
We look at the list of validations and for each of them we make checks that she swears. Those. length restrictions, forbidden characters, input mask - all this must be checked and make sure that it works.
Hint: text can also be entered by copying.
IE
I understand that the first reaction is some such.
You are lucky if you have few users of this marvelous browser. But if not, then alas. You will have to look at your work through the prism of alternative perception.
Metrics
It's almost like with IE, but it doesn’t hurt.
If no custom metrics are collected on your project, then everything is fine. Otherwise, you have to do two things:
- Hang all the metrics on the required actions. In my experience, information about metrics came either from analytics, or the front-end vendors themselves were in the know.
- Check that the right metrics with the right data are sent to the actions. At least output to the console in dev mode.
Instead of a conclusion
I briefly talked about what you should pay attention to when working with the front. These few checks will allow you to get a significantly better product at the output.
I would like to note that the article will be useful if you do not have a tester at all. Therefore, at the end once again a brief summary:
- Layout on prototypes.
- Enter a variety of data: a lot, a little, in one word, do not enter.
- Trim spaces.
- Check validations.
- IE
- Do not forget the metrics.
FAQ
Q: Testers will find everything!
A: Not all. Testers - this is not a HEPA filter for you, but people. And if at the development stage someone did not do their part of the work, then it does not go anywhere, but simply passes on to someone else.
Caught up, but didn’t look? This means that other people will work with this, spend not only time, but also their strengths. A person gets tired, the eye is washed away, fatigue accumulates. And beyond the shaft of such problems, more serious things may be missed.
Also, do not forget that any game with ping-pong tasks only imposes additional time costs. It’s still necessary to finish normally. But early detection of problems speeds up the entire development process.
Thanks for attention.
Source: https://habr.com/ru/post/461569/
All Articles