Me bot and my awl
Background: it was inconvenient for our customer to carry out the routine actions as agreed, since initially he was sent a link to the necessary calculations, and each time he opened the necessary indicators through the browser for review, which increased the operating time. We proposed transferring the logic to the chatbot in order to reduce decision-making time and make life easier for the client’s employees.
To celebrate, I decided to approach this matter with all responsibility, to show maximum ingenuity, and just enjoy the work.
Testing was performed using the black and gray box method. Therefore, you can use all your imagination to come up with custom scripts.
Statement: a third-party service sends a SOAP request, which we must process and save in the database, and then create a picture with the parameters in a table form and send it to the user for approval. In response, the system receives a confirmation or rejection along with a comment on the decision.
There is a description, pencils sharpened, checklists prepared, cookies all eaten. I am ready to start! Every second new questions were born …
Stop stop stop! Keep calm and start testing. So, in order:
1. In what form to display the date? There is always a problem with the date: format, time zone, etc.
We could not get exact requirements from an external system, so we decided to display the date in the form in which it was originally received. It is very difficult to predict in what format the date will be received (even a magic ball could not have done this).
2. How much will the image quality suffer if the message contains a large amount of information?
Image quality directly depends on the amount of information received from the outside. Telegram itself reduces image quality. In case there is a large amount of information, then by transmitting with a document, we will get the table in a readable form, but then the user needs to use a third-party application to open the generated PDF file. This will complicate life, and no one likes difficulties (but everyone loves cookies!). At the same time, if you send a picture, it will be readable only when a little data has been received, but then the user can use the functionality of Telegram itself to view the image. We decided that it was better to leave the display with a picture, since it is more convenient to work with it, and it is unlikely to get a large amount of information.
3. How should the system respond if no comment has been received on the decision?
Everything turned out to be quite simple here: we saved the result of the decision that was sent. And when the request was repeated, the user was given information about the need to fill out a comment on the decision.
4. How should the user understand for what solution it is necessary to leave a comment if several requests for approval in a row have been received?
Here, the functionality was implemented so that a message asking for a comment comes in the form of a response to a message with basic information about the solution.
5. What should the system do if the user has not yet made a decision on old messages, but new ones have already been received?
In this case, our system resends the same message for approval (no one dares to ignore us!).
6. How many messages can we accept?
To answer this question, I decided to create a simple Test Suit in the SOAP UI. The choice fell on this application, because it has an extensive scope (covers web services verification, simulation, functional testing, load testing, etc.).
I will not tell you how to create a simple Test Suit, since they have already written enough about this, I would just like to describe the problem and the version of my solution.
The main problem was that for each new request a new identifier had to be generated, and this generated value was reused within the same XML.
The solution was found:
In a test case, a Property is created with the ID_Calc attribute.
Then, in the Setup script tab, paste the script:
testCase.setPropertyValue ("ID_Calc", new java.util.Random (). nextInt (99999) .toString ())
After that, in the request itself, in the tags where the identifier is used, it is necessary to write:
$ {# TestCase # ID}
Thus, each request had a unique identifier, but within the framework of a separate message, the identifiers were the same.
The development and testing work was carried out very quickly and harmoniously, so we managed to achieve the result as soon as possible. The revision was immediately handed over to the customer, and he was satisfied.
Even from the simplest and most mundane task, you can make a cool quest, the passage of which you can be proud of! Well, if you are bored, but want vivid feelings, just find problems on your project and solve them in an unusual way 🙂
Good luck
