Pull to refresh
0

Я, бот и моё шило

Reading time 3 min
Views 5K
Меня зовут Даша, и я инженер по тестированию уже 4 года. Это значит, что интересные задачи, на которые набрасываешься с азартом «джуна» в поисках новых решений, появляются всё реже. Одни и те же проекты, постановки и кейсы! Нет, я так не играю! Тестирование – это всегда challenge, а желание изменить мир к лучшему не должно умирать. И вот однажды мне попалась такая задачка: необходимо протестировать простой чат-бот в Telegram.



Предыстория: нашему заказчику было неудобно выполнять рутинные действия по согласованию, так как изначально ему отправлялась ссылка на необходимые расчеты, и он каждый раз открывал через браузер нужные показатели для ознакомления, что увеличивало время работы. Мы предложили перенести логику в чат-бот, чтобы сократить время принятия решения и облегчить жизнь сотрудникам клиента.

На радостях я решила подойти к этому делу со всей ответственностью, проявить максимум изобретательности, да и просто получить удовольствие от работы.

Тестирование выполнялось методом «черного и серого ящика». Поэтому можно использовать всю свою фантазию в придумывании пользовательских сценариев.

Постановка: сторонняя служба присылает SOAP-запрос, который мы должны обработать и сохранить в базе данных, а затем сформировать картинку с параметрами в табличном виде и отправить пользователю на согласование. В ответ система получает подтверждение или отказ вместе с комментарием к решению.

Описание есть, карандаши наточены, чек-листы подготовлены, печенье все съедено. Я готова начинать! С каждой секундой рождались новые вопросы…

Стоп-стоп-стоп! Keep calm and start testing. Итак, по порядку:

1. В каком виде выводить дату? Проблема с датой всегда есть: формат, часовой пояс и т. д.
Получить точные требования от внешней системы мы не могли, поэтому решили выводить дату в том виде, в котором она была получена изначально. Предугадать, в каком формате будет получена дата очень сложно (с этим даже магический шар не справился бы).

2. Как сильно пострадает качество картинки, если сообщение будет содержать большой объем информации?
Качество картинки напрямую зависит от количества информации, полученной извне. Сам Telegram снижает качество изображения. В случае, если будет большой объем информации, то, передавая документом, мы получим таблицу в читабельном виде, но тогда пользователю необходимо использовать стороннее приложение, чтобы открыть сформированный PDF-файл. Это ещё усложнит жизнь, а никто не любит трудности (зато все любят печенье!). В то же время, если отправлять картинку, то она будет читабельна, только когда данных было получено немного, но тогда пользователь сможет использовать функционал самого Telegram для просмотра изображения. Решили, что лучше оставить отображение картинкой, так как с ней удобнее работать, да и получить большой объем информации маловероятно.

3. Как система должна реагировать, если не был получен комментарий к решению?
Тут оказалось всё достаточно просто: мы сохраняли результат решения, который был отправлен. А при повторном запросе выдавали пользователю информацию о необходимости заполнения комментария к решению.

4. Как пользователь должен понять, для какого решения необходимо оставить комментарий, если было получено несколько запросов на согласование подряд?
Здесь функционал был реализован так, что сообщение с просьбой об указании комментария приходит в виде ответа на сообщение с основной информацией о решении.

5. Что должна делать система, если пользователь ещё не принял решение по старым сообщениям, а уже были получены новые?
В этом случае наша система отправляет повторно это же сообщение на согласование (никто не смеет нас игнорировать!).

6. Как много сообщений мы можем принять?
Чтобы ответить на этот вопрос, я решила создать простой Test Suit в SOAP UI. Выбор пал на данное приложение, потому что у него обширная область применения (охватывает проверку веб-сервисов, имитацию, функциональное тестирование, нагрузочное и т. д.).
Как создавать простой Test Suit я не буду рассказывать, так как об этом писали уже достаточно, хотелось бы просто описать проблему и вариант моего решения.
Основная загвоздка заключалась в том, что для каждого нового запроса должен был формироваться новый идентификатор, и это сформированное значение используется повторно в рамках одной XML.

Решение было найдено:

В test case создается Property с атрибутом ID_Calc.



Затем во вкладке Setup script необходимо вставить скрипт:
testCase.setPropertyValue(«ID_Calc»,new java.util.Random().nextInt(99999).toString())



После этого, в самом запросе, в тегах, где используется идентификатор, необходимо прописать:
${#TestCase#ID}



Таким образом, каждый запрос имел уникальный идентификатор, но в рамках отдельного сообщения идентификаторы были одинаковыми.

Работа по разработке и тестированию велась очень оперативно и слажено, поэтому нам удалось добиться результата в кратчайшие сроки. Доработка была сразу же сдана заказчику, и он остался доволен.

Даже из самой простой и обыденной задачи можно сделать крутой квест, прохождением которого можно будет гордиться! Ну а если тебе скучно, а ярких ощущений хочется, – просто у себя на проекте найди проблемы и реши их необычным способом:)

Удачи!
Tags:
Hubs:
+4
Comments 0
Comments Leave a comment

Articles

Information

Website
digdes.ru
Registered
Founded
Employees
501–1,000 employees
Location
Россия