How to find boundaries on the client and server
But if we have a client-server application , then the developer can set boundaries on each link!
And the tester should check them all. Why? Because when we duplicate the same value several times in different places, there is a great chance to make a mistake. At the same time, the border on the client is very easy to remove. What happens if the user bypasses the border on the client? Will he break our site with a big line?
In this article I will tell you how to look for borders for a field in a web form. Take the user editing form as an example in the users free system .
1. Borders on the client
- 2. Borders on the server
- 3. Borders in the database
- Total: border search checklist
1. Borders on the client
The limit on the length of the line on the client is specified in the parameter maxlength field.
To find it, you need:
- Open the developer panel - press f12 .
- Click the left-most button and move the cursor over the element on the page.
Voila! For the field "name1" we have a limit of 10 characters.
What a tester needs to know about the developer panel
Check the restriction - try to enter more than 10 characters. But exactly 10 is introduced, no longer gives. You type on the keyboard, but the system simply does not respond:
This is the border! Border on the client, we found it, cheers.
But this does not mean that you need to calm down for the sim. Borders on the client are removed very easily, so it is important to check on the server too. And we, as testers, should check if there is protection on the server.
Therefore, we are removing the border. To do this, right in the DOM model (this is the structure of our page that we searched for by the inspector), we correct the line with the parameter. Yes, it is changing. Double click on the maxlength parameter and change the value. Voila! Now you can enter a lot more characters than before!
Please note that you can enter characters immediately without refreshing the page. Moreover, if you refresh the page, your changes will be lost. After all, when you refresh the page, the HTML code is requested from the server, and there your changes are not there. So indulge as much as you want, do not be afraid to break something =)
In principle, to check the boundary on the server, you can first change the value from 10 to 1000. But if you want to look for the technological boundary, it is better to choose a larger value. Or delete the parameter altogether. Highlight and delete!
When you find an item in the inspector, you can see other digits besides maxlength . For example, "data-max" or "data-jsmax" , or some others. Can they be considered borders? Only if you can read the code and find their meaning in it.
A developer can write HTML the way he likes. It can specify any attributes for the tag, with any names. It is not at all a fact that this will be some kind of boundary.
It can be a “Legacy” element, that is, it is not processed or used at all. Just forgot to delete. Or it can be used for CSS - “if we have such and such a value, then we write in white, if so, then in black.”
But maxlength is the standard attribute. And if it is installed, then it restricts the user - the user cannot enter more characters in the input field than specified in maxlength . Therefore this is the boundary.
And everything else - you need to check whether it restricts us somehow, or not. How to check? Enable Console!
Errors in the JS console
When testing the web, you must enable the console:
F12 → Console
And follow her out of the corner of her eye. Otherwise, you can skip the error!
It happens that the system does not show a problem in any way - nothing changes in the interface itself. Enter data in the fields? Nothing is highlighted in red, but an error appears in the console. Poke a button? The report is loading, everything seems to be fine, but the console has an error.
If an error appears in the console, this is not normal. And this must be dealt with. A mistake can carry a delayed effect, or maybe you just did not notice its manifestation. For example, when loading a report, one cell was calculated incorrectly because it could not load the data, which was written to the console about. At the same time, the report loaded and it seems like there is data inside, it looks normal. But there is a mistake.
So, open the console and start filling in the user fields. For example, we drive data into the “hamster” field. We removed the border on the client (maxlength) and print. And here we notice that an error appeared in the console!
It turns out that the developer put additional protection on the field. In addition to maxlength, I registered a restriction in the code. Perhaps this message should have been displayed in the interface so that the user could see that something was doing wrong, but the developer had messed it up and output it to the console.
In the case of Users, the developer did not confuse anything, he had to write such a message to the console on TK =)) Because our task was to simply show the situation when everything is fine in the interface and there are errors in the console.
But where is the border? Judging by the error message "Maximum - 10". That means a border of 10 characters. Yes? Nevermind! A border is when we have one system behavior before it (no errors), and after another.
Remember that error messages are also code. Which also needs to be tested. The developer may make a mistake and write the message incorrectly. So let's check where the system’s response to input changes.
Start typing characters slowly, following the console:
- 10 - no error
- 11 - no error
- 12 is a mistake!
Yeah, that means that the JS border is not 10, but 11 characters! Until 11, everything is fine, and after that errors are raining. And the error message, as it turned out, is lying. So "trust, but verify" =)
This is also the border on the client. Thus, the hamster field has two boundaries on the client:
- maxlength =10 characters
- js =11 characters
But in the "name 1" field there is one border on the client: maxlength=10 characters. There are no errors in the console when entering characters.
I would like to emphasize once again that a border is not only when errors are poured into the console. It can be a user-visible change in the behavior of the system.
For example, the analyst decided that the name should be at least 3 letters long. Therefore, when the user places the cursor on the field with the name, a red frame appears around it and the signature “Name should not be shorter than 3 letters” at the bottom. Entered 1-2 letters - nothing has changed. Entered 3 - the frame with the signature disappeared. Or the frame changed color from red to green.
There are no such borders in Users, so I just took a picture from the Internet =)
This is the lower limit established by TK. And made on the client. Similarly, you can draw the upper border - entered more than 10 characters? A red frame appears around the field. So that’s also the border.
Total on the border on the client
The border on the client is the value of the "maxlength" attribute in the character input field. You cannot enter more than this value, the system simply will not allow it to be done.
This restriction can be easily removed through the developer panel - How to remove maxlength from all form fields .
This may not be the only border. The developer can also specify the border in the code. To find her, follow the system. If she changes her behavior - we found the border:
- Enter the characters and a red frame appears at the field and the signature "too long" - the border! In addition to "maxlength", the developer added verification
- You enter characters and errors appear in the console - also a border!
2. Server border
The border on the server is how many characters we can save in the system. In theory, it should coincide with the border on the client =) But anything happens. When we need to register one value in different places, there is always a chance to make a mistake.
Since the border on the client is easy to bypass, we must do this during testing. And see if there are borders on the server. And if so, which ones.
Let's remove the restriction maxlength=10 from the field “name1” in Users, enter a long line there and try to save it. When saving, the system gives an error:
This is the border on the server. The client passed the request to the server, it worked it out and returned the feedback.
It remains to understand where the border is. Of course, the error message helps us with this: "actual: 37, maximum: 9" . In theory, the server is limited to 9 characters. But you and I already know that this must be verified!
- Enter 9 characters, save - saved!
- Enter 10 characters - saved.
- Enter 11 characters - an error occurred while saving.
So, really a border of 10 characters on the server. Same as the border on the client, that's good.
Now let's check the hamster box.
Yeah, there’s a different border. The message is 19, but we remember that it is lying. Check - a border of 20 characters. And on the client it was 10, in maxlength! So the borders are different.
In general, this is an occasion to put a bug, because the boundaries must coincide. True, it can be closed as "won`t fix" , well, it saved a little more, and okay. Much worse when a developer makes a mistake the other way:
- Server - 10 characters
- Customer - 20 characters
As a result, you can enter 20 characters on the client, but we save an error when saving. Not good!
After checking the upper bound in “adequate” limits, it is worth looking for a technological boundary. Removed the restriction on the client, entered several million characters. It is very easy to do. We take any tool from the article " How to generate a large line, tools ", we substitute save.
If the system generated exactly the same error as before, then approx. So, there is no technological border. Well, nice. The main thing that we tried to search =)
Why do this? Because the system can not only save data, but somehow pre-process it. Check by condition, or somehow else. And then the system will master a small line, but the huge one is gone.
The technological border in the prompts for legal entities - if you enter 1000 characters, nothing will happen but if “war and peace”...
3. Border in the database
The border in the database is how many characters fit into the database. Creating a base, we indicate the dimension of each field. Here's a example from folks :
- surname - VARCHAR (255)
- name - VARCHAR (100)
- city - VARCHAR (20)
This means that in the "last name" field we can save 255 characters, in the name 100, and in the city - 20. When you try to stuff a larger line there, the system will generate an error from the series "ORA-06502: PL/SQL: numeric or value error: character string buffer too small » .
It is important to understand that we will see the database border only if there is no border on the server. Border Search Path Does Not Change:
- Removed the border on the client
- Crammed a large string
- Trying to save
So, if the developer set the border on the server, then we will see the error processed - beautifully (or not so) rendered, with quite meaningful text. Because the developer wrote it and it is about our application.
And if there is no border on the server, then we will see an unprocessed error. This can be an error of the form “ORA-06502 :.”, or a code string trace - a bunch of characters incomprehensible to a simple user.
Of course, there may be another situation - when there is more border on the server than in the database:
- Server - 20 characters
- DB - 10 characters
And then we get a funny situation. Yes, we defended ourselves against the insertion of “war and peace”. Enter 25 characters or 25 million characters - you get a meaningful error. But if you enter 11 characters, then oh! Big and scary stackrace full screen.
Therefore, when testing a black box, do not immediately strive to fig a lot of characters. First, try a meaningful meaning. And if you removed the restriction on the client, you should try the borderline value to it. Was maxlength=10? Try 11 characters. And then already 55, and then already 55 million.
Total: Border Search Checklist
In a client-server application, boundaries can be at each link. And ideally, they should match. But we have to check it out!
There may be more borders. On the client, the developer can hang several boundaries at once: both maxlength and behavior change when crossing a certain line (js-code).
Borders may be less. From the series “May the user not introduce nonsense”, and as a result, on the client and server without any restrictions at all. But the dimension of the fields in the database remains.
How to search for borders:
1. Check if the maxlength field is the most obvious border on the client.
2. Remove this restriction .
3. Turn on the JS console (and where without it?).
4. Start driving in characters, about 50-100 in each field. Follow:
- to the console - have any errors appeared?
- by the behavior of the system itself - has the behavior changed?
If the behavior of the system changes, or errors appear in the console, this is also the border on the client. But the other, in js code.
5. Try to save these 50-100 characters. So we are looking for a border on the server and/or in the database.
If the system produces a meaningful error of the form "Too long field" - this is an error on the server. If the error is not processed, most likely there is no border on the server, and you found the border in the database.
The exact value of the boundary can be found using the bisectional division method. Well, or using the logs/text of the error message.
6.Enter 100 million characters ( tools ) and try to save them to find the technological frontier.
In the process of the article, we checked the “name1” and “hamster” fields on this checklist in the Users system. Results:
- maxlength - 10 characters
- server - 10 characters
- maxlength - 10 characters
- js - 11 characters
- server - 20 characters
Everything is fine for the name, the boundaries are the same. But when examining the “hamster”, we immediately found 2 problems - the difference in client-server boundaries (10 and 20), as well as an error in the console. You can put bugs !.