Автоматизированное тестирование с помощью Selenium / Comments / Habr

Ну признайтесь, маркетолог же писал? Очень слабая в техническом плане статья. И содержит немало ошибок. Немного разберу из начала и конца.

Конечно, можно все свалить на плечи тестировщиков... Но порой и у хорошего тестировщика куча своих задач или конкретно с вашей задачей он мало знаком.

А затем:

И в ситуациях, описанных выше, крайне необходимо иметь хоть какое-то автоматизированное тестирование.

У вас не будет хороших автотестов, если нет хороших тесткейсов, которые пишут ручные тестировщики, а у них "куча своих задач". И если такие проблемы с ресурсами, то откуда у автоматизаторов они найдутся?

Я хочу лишь описать возможность минимизации негативных последствий от отсутствия тестирования как такового.

Так по итогу этого нет в статье. В ситуации нехватки всего вы предлагаете решение в виде автоматизации, а не настройки процессов — это ужасный совет. Автотесты нужно точно таким же образом поддерживать, как и тесткейсы, как и документацию. А таким подходом мы сообщаем бизнесу, что "автотесты нам помогут!". Нет, не помогут. Более того, такой подход отлично иллюстрирует, что совершенно нет дела до качества продукта, который дойдет до пользователя. Качество — это процесс, а не наклепать несколько классов для запуска в CI.

Сквозные тесты (e2e) — это автоматизированные имплементации

Что, простите? Весь абзац технически неграмотен.

Сквозные тесты обычно считаются наиболее ценными и информативными, поскольку они имитируют взаимодействие с пользователем и гарантируют, что вся система функционирует правильно.

Нет, не являются. Нет, не гарантируют.

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

И именно потому что они сложны в обслуживании и подвержены нестабильности вы их и предлагаете в качестве решения, ведь для них есть целая толпа автоматизаторов?

Само автоматизированное тестирование можно разделить на две части: тестирование с кодом и codeless-тестирование.

Нельзя. Ну или эту часть писал маркетолог, максимально далекий от мира IT.

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

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

Весь блок про Codeless-тестирование ужасен. При чем здесь вообще какие-то решения без кода? Сплошная маркетинговая чушь. Но давайте разберем из интереса.

В ситуации с codeless-тестированием вы используете фреймворки на базе искусственного интеллекта, которые запоминают действия.

Давно ли record-and-play стали на базе ИИ? И с чего вдруг "фреймворк" (что тоже неверно) запоминает? Действия пользователя записываются, а затем могут быть экспортированы в виде кода под нужную библиотеку.

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

Ни слова по делу. Что за "некоторая информация"? Что значит "ответ целевого приложения"? И "проверяют ... должным образом" — это каким именно? Нормальное описание заняло бы не сильно больше букв, чем эта чушь.

Эти инструменты часто выглядят как малокодовые платформы для разработки, где вы перемещаете различные панели.

Девятиэтажек, я так полагаю? Или стеновые? Забавно то, что дальше упоминается TestCraft. Только там нет "перемещения панелей". Текст после маркетолога стоило бы вычитать приличия ради.

Один из таких инструментов – TestCraft. Это codeless-решение, разработанное на платформе Selenium

Перед написанием не помешало бы ознакомиться с TestCraft. Вдруг у них ничего не написано про codeless и про "разработанное на платформе Selenium", а то может оказаться, что вы тут вводите в заблуждение читателей.

Как правило, эти инструменты стоят дороже из-за того, что такие функции, как создание, сопровождение и запуск тестов выполняются с помощью простого перемещения панелей, а также из-за того, что для проведения тестов не нужно уметь писать программный код. Но я упомянул здесь про TestCraft, потому что у него есть бесплатная версия, которая включает в себя практически все.

А здесь прекрасно всё. Selenium IDE и Katalon Studio бесплатные, как и TestCraft. Разве что для последнего нужен ключ для chatgpt, но его отсутствие никак не влияет на работу плагина, а сам он не продается разработчиками, только через OpenAi. Про "не нужно уметь писать программный код" — внезапно этот сгенерированный код надо тоже править, что уже выходит за рамки codeless.

При падении сквозного теста бывает довольно сложно определить «место падения». Но это можно компенсировать грамотным логированием и созданием скриншотов.

Нет. Где упал, там и смотрите. В этом ничего сложного.

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

Светлая мысль, жаль, что развивать ее не стали. Ведь если сквозные тесты тормозят релиз, то очевидно, что надо посмотреть на пирамиду тестирования, посмотреть на процессы, закладывать время на тестирование перед релизом. Вот эти все вещи, про которые пишут в умных книгах.

Сквозные тесты имеют «непрерывную» природу

Это очень странно звучит.

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

А при чем тут "непрерывная природа"? И нет, не каждая новая функциональность приводит к обновлению.

«Как тестировать» разобрали, теперь осталось выяснить чем тестировать.

Да лучше бы не разбирали.

Спросим у Яндекс Нейро, что это такое и с чем его едят.

А вот тут лучше бы прогнали через яндекс статью.

Собственно, а почему именно Selenium? Наверняка же есть же аналоги. Конечно, один из них — Cypress.

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

Playwright... уже лучше. Неплохой набор браузеров Chromium (включая Chrome, Edge, Opera), Firefox, Safari. Но до Selenium не дотягивает. Например, Interner Explorer не поддерживает.

А в чем, простите, не дотягивает? Если вам надо старые IE, которые уже и MS не поддерживает, то это не проблема инструмента, а ваша. Это не значит, что он "не дотягивает", это значит, что он вам не подходит. А теперь соберем информацию вместе — вот пишется статья на хабр, неявно вводится критерий поддержки старого IE, по которому остальные фреймворки тестирования отлетают, а инструмент для автоматизации браузера (а не тестирования) на коне. Зачем тогда вообще проводить сравнение, если заранее выбран критерий, искусственно делающий Selenium победителем? Большинство автоматизаторов работают с более-менее современные технологии, но в этой статье нет даже намека на объективное сравнение и выбор.

И еще раз акцентирую, что вы сравниваете фреймворки для автоматизации тестирования с инструментом для автоматизации браузеров. На шарпах же есть Atata (он есть в списке фреймворков на сайте selenium), но его вы игнорируете.

Так что упускать Internet Explorer не нужно, он еще может быть полезен.

Как старый код, который закомментировали вместо удаления, и он хранится годами "на всякий случай". Отличный совет!

И я много раз видел, когда сайт прекрасно работает в Google Chrome, но падает в IE

IE не поддерживается с 2022 года. Можно уже не цепляться за прошлое. Лучше смотреть на новые браузеры, которыми пользуются люди.

using NUnit.Framework;

Так вы же его не using. У вас тест без проверок.

В заключение хочу сказать, что в этой статье мы компенсировали отсутствие unit-тестов набором автотестов.

Хорошо, что только в статье. Не надо так делать в реальности и рассказывать другим, что так можно.

при правильном планировании способен уберечь проект от неочевидных ошибок и сэкономить QA-отделу кучу времени и нервов.

Эта фраза для продажи автоматизации подойдет. А в реальности (это которая у вас в самом начале с нехваткой времени и ресурсов) автотесты будут плохими, потому что проблемы с тесткейсами (у ручных тестировщиков же нет времени), проблемы с поддержкой этих автотестов (чем их больше, тем больше нужно на них времени) и дальше будут пропуски прогонов, отключение тестов, всё как у описанных вами разработчиков.

В целом статья похожа на неграмотную попытку использовать e2e как замену процессам тестирования.