Ну признайтесь, маркетолог же писал? Очень слабая в техническом плане статья. И содержит немало ошибок. Немного разберу из начала и конца.
Конечно, можно все свалить на плечи тестировщиков... Но порой и у хорошего тестировщика куча своих задач или конкретно с вашей задачей он мало знаком.
А затем:
И в ситуациях, описанных выше, крайне необходимо иметь хоть какое-то автоматизированное тестирование.
У вас не будет хороших автотестов, если нет хороших тесткейсов, которые пишут ручные тестировщики, а у них "куча своих задач". И если такие проблемы с ресурсами, то откуда у автоматизаторов они найдутся?
Я хочу лишь описать возможность минимизации негативных последствий от отсутствия тестирования как такового.
Так по итогу этого нет в статье. В ситуации нехватки всего вы предлагаете решение в виде автоматизации, а не настройки процессов — это ужасный совет. Автотесты нужно точно таким же образом поддерживать, как и тесткейсы, как и документацию. А таким подходом мы сообщаем бизнесу, что "автотесты нам помогут!". Нет, не помогут. Более того, такой подход отлично иллюстрирует, что совершенно нет дела до качества продукта, который дойдет до пользователя. Качество — это процесс, а не наклепать несколько классов для запуска в 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 как замену процессам тестирования.
Интересная реакция. Вам дали список недочетов, некоторые из которых будут блокировать повтор действий из этой статьи, а в ответ — 🤣. Прошлый материал был более профессиональным.
Может, надо более точечно было написать, что вот тут: Appium настроен, теперь можно переходить к настройке конфигурации. Создаем конфиг для Appium и конфиг для Selenoid: неплохо было бы указать, какой именно файл создается и где.
А тут "image": ["appium", "--config", "/Users/mobilefarm.am/selenoid/config/appium/iphonex.json"] поделиться секретным содержимым файла iphonex.json .
Для людей же пишете, а не для KPI по статьям на отдел.
С версиями аппиума тоже есть нюанс. Видимо, вы не в курсе, но раньше при установке беты второго аппиума для IP из России сыпались интересные сообщения в консоль. А может там еще и какие-то скрипты дополнительно исполнялись. И потому было бы неплохо иметь какие-то гарантии, что никаких сюрпризов не будет при установке и после (вы же в альфе делаете какие-то проверки, а не тупо ставите всё подряд?).
И если вам нужно , нет, спасибо, давайте без предположений. Я просто хотел почитать качественную статью.
В блоке с конфигами для аппиума и селеноида нет пояснения, где создавать файлы и как называть. В конфиге селеноида есть пути до файлов, но снова нет пояснения, что то за файлы и что в них должно быть и почему такие пути.
Нет объяснения параметров запуска селеноида.
Опечатка в команде для аппиум-доктора.
И нет варианта с запуском симулятора.
Пока что по этой статье шаг за шагом выполнить вряд ли получится задуманное.
Ну вот так точно не надо писать — не надо делать из айтишников каких-то особенных. Они ничем не отличаются от других таких же рядовых сотрудников компании. А так вы только раскалываете, полностью перекладывая финансовый успех на одно направление.
Раз статья для новичков, то выделю то, что их хорошему не научит.
"message_text" и "chat_id" — в джаве принят другой формат именования переменных.
Смущает ".split(" ");" — а если пользователь ввел два и более пробелов случайно? А если клиент телеграма перестанет убирать пробелы до и после текста сообщения, которые тоже случайно были добавлены? А обработка текста со спецсимволами? А если вес на одной строке, а рост на другой? Так что надо тримить, а после из двух и более пробелов делать одинарный. А еще может потом захочется сделать другой разделитель, точка с запятой или еще что-то. А еще проверка на валидность роста, например, что выше 250 быть не может. Кейсов накидать можно много, но хотело бы видеть хотя бы намеки на проверки, хотя бы комментариями. Понятно, что это пет проджект и не более, но привычка подумать о том, как реальный человек будет пользоваться — всегда пригодится. "Все остальные запросы должны блокироваться" — все же это слишком искусственное требование.
Не очень понятно, в чем смысл проверки на наличие пробела ("// если сообщение с текстом содержит пробел"). Она вообще не нужна. Вы же в любом случае делаете массив строк через split и если длина не 2, то отправляете ошибку.
Название переменной "weightAntHeight" тоже не отражает сути массива и может путать.
И неплохо было бы добавить обработку, что если сообщение "/start", то высылать инструкцию. для тех, кто впервые открыл его.
Читая статью, я не знаю, что такое "WriteUser" и "ImtCount". Для этого надо лезть на гитхаб и изучать уже там. Но вот в самой статье это мешает и не несет никакой смысловой нагрузки. Лучше расписать про базу в следующих статьях, материала-то можно много сделать.
Если без этих мелочей, то статья хорошая, пишите еще.
Смотрите, что я увидел. Вы для автотестов предлагаете писать pipeline, при этом в вашем примере я не вижу ничего такого, чего нельзя было бы сделать через freestyle job. Если я перепишу ваш пайплайн на freestyle job, он разве станет "несложным"?
Как инженер, я хотел бы видеть какую-то аргументацию посильнее, чем Если же нужно, что-то более кастомное, то тут нам на помощь приходит Pipeline. Пример: отправка уведомления на почту. В freestyle нет возможности указать тело сообщения, в Pipeline - можно. Как минимум по той причине, что для тех же уведомлений на почту есть плагин Email Extension (https://plugins.jenkins.io/email-ext/), который позволяет настраивать что угодно и сейчас ставится чуть ли не по дефолту. Аналогично и с плагином для слака — полная кастомизация (справедливости ради добавлю, что через пайплайн можно настроить еще лучше, но для автоматизации это излишне — нам же по сути нужен статус прогона и ссылка на него).
Аргументы с официального сайта, конечно, хороши, но это не ваш опыт. Сравните хотя бы картину пайплайна по ссылке с тем, что описано у вас. И далее по списку преимуществ — часто ли у вас перезапускается контроллер Jenkins, часто ли вам нужно писать реально сложные пайплайны с ветвлениями и зацикливаниями, часто ли вы используете настраиваемые расширения для своего DSL? Почему-то кажется, что вообще нет. Что по всем этим пунктам ответ будет отрицательный. И в таком случае получается, что у такого подхода для автотестов нет преимущества. Для полноценного процесса развертки + тестирования + деплоя — да. Но статья не про это. Ну и следом был бы вопрос — а чем этот подход лучше написания скрипта на груви?
Не поймите неправильно, статья отличная, но для автоматизации тестирования я только один аргумент увидел — хранение в vcs. Но и на это можно возразить, что если джобы настолько сложные, что их нужно где-то хранить, то скорее всего что-то делаете не так.
Ну признайтесь, маркетолог же писал? Очень слабая в техническом плане статья. И содержит немало ошибок. Немного разберу из начала и конца.
А затем:
У вас не будет хороших автотестов, если нет хороших тесткейсов, которые пишут ручные тестировщики, а у них "куча своих задач". И если такие проблемы с ресурсами, то откуда у автоматизаторов они найдутся?
Так по итогу этого нет в статье. В ситуации нехватки всего вы предлагаете решение в виде автоматизации, а не настройки процессов — это ужасный совет. Автотесты нужно точно таким же образом поддерживать, как и тесткейсы, как и документацию. А таким подходом мы сообщаем бизнесу, что "автотесты нам помогут!". Нет, не помогут. Более того, такой подход отлично иллюстрирует, что совершенно нет дела до качества продукта, который дойдет до пользователя. Качество — это процесс, а не наклепать несколько классов для запуска в CI.
Что, простите? Весь абзац технически неграмотен.
Нет, не являются. Нет, не гарантируют.
И именно потому что они сложны в обслуживании и подвержены нестабильности вы их и предлагаете в качестве решения, ведь для них есть целая толпа автоматизаторов?
Нельзя. Ну или эту часть писал маркетолог, максимально далекий от мира IT.
Ну почти. Мы используем фреймворки, которые позволяют работать с базами данных, с браузерами, с апи, с файлами и т.д. Кажется, что это несколько шире, чем просто браузеры. И хоть в заголовке статьи написано про Selenium, но написать немного слов по делу было бы полезнее, чем про абстрактные сложности проектов.
Весь блок про Codeless-тестирование ужасен. При чем здесь вообще какие-то решения без кода? Сплошная маркетинговая чушь. Но давайте разберем из интереса.
Давно ли record-and-play стали на базе ИИ? И с чего вдруг "фреймворк" (что тоже неверно) запоминает? Действия пользователя записываются, а затем могут быть экспортированы в виде кода под нужную библиотеку.
Ни слова по делу. Что за "некоторая информация"? Что значит "ответ целевого приложения"? И "проверяют ... должным образом" — это каким именно? Нормальное описание заняло бы не сильно больше букв, чем эта чушь.
Девятиэтажек, я так полагаю? Или стеновые? Забавно то, что дальше упоминается TestCraft. Только там нет "перемещения панелей". Текст после маркетолога стоило бы вычитать приличия ради.
Перед написанием не помешало бы ознакомиться с TestCraft. Вдруг у них ничего не написано про codeless и про "разработанное на платформе Selenium", а то может оказаться, что вы тут вводите в заблуждение читателей.
А здесь прекрасно всё. Selenium IDE и Katalon Studio бесплатные, как и TestCraft. Разве что для последнего нужен ключ для chatgpt, но его отсутствие никак не влияет на работу плагина, а сам он не продается разработчиками, только через OpenAi. Про "не нужно уметь писать программный код" — внезапно этот сгенерированный код надо тоже править, что уже выходит за рамки codeless.
Нет. Где упал, там и смотрите. В этом ничего сложного.
Светлая мысль, жаль, что развивать ее не стали. Ведь если сквозные тесты тормозят релиз, то очевидно, что надо посмотреть на пирамиду тестирования, посмотреть на процессы, закладывать время на тестирование перед релизом. Вот эти все вещи, про которые пишут в умных книгах.
Это очень странно звучит.
А при чем тут "непрерывная природа"? И нет, не каждая новая функциональность приводит к обновлению.
Да лучше бы не разбирали.
А вот тут лучше бы прогнали через яндекс статью.
Не очень понимаю, в чем смысл брать на рассмотрение инструмент, который не поддерживает желаемый вами язык программирования и находить в нем минусы? Вы заведомо ставите его в проигрышную позицию, но это не потому, что он такой неудачный, а потому что вы не умеете сравнивать.
А в чем, простите, не дотягивает? Если вам надо старые IE, которые уже и MS не поддерживает, то это не проблема инструмента, а ваша. Это не значит, что он "не дотягивает", это значит, что он вам не подходит. А теперь соберем информацию вместе — вот пишется статья на хабр, неявно вводится критерий поддержки старого IE, по которому остальные фреймворки тестирования отлетают, а инструмент для автоматизации браузера (а не тестирования) на коне. Зачем тогда вообще проводить сравнение, если заранее выбран критерий, искусственно делающий Selenium победителем? Большинство автоматизаторов работают с более-менее современные технологии, но в этой статье нет даже намека на объективное сравнение и выбор.
И еще раз акцентирую, что вы сравниваете фреймворки для автоматизации тестирования с инструментом для автоматизации браузеров. На шарпах же есть Atata (он есть в списке фреймворков на сайте selenium), но его вы игнорируете.
Как старый код, который закомментировали вместо удаления, и он хранится годами "на всякий случай". Отличный совет!
IE не поддерживается с 2022 года. Можно уже не цепляться за прошлое. Лучше смотреть на новые браузеры, которыми пользуются люди.
Так вы же его не using. У вас тест без проверок.
Хорошо, что только в статье. Не надо так делать в реальности и рассказывать другим, что так можно.
Эта фраза для продажи автоматизации подойдет. А в реальности (это которая у вас в самом начале с нехваткой времени и ресурсов) автотесты будут плохими, потому что проблемы с тесткейсами (у ручных тестировщиков же нет времени), проблемы с поддержкой этих автотестов (чем их больше, тем больше нужно на них времени) и дальше будут пропуски прогонов, отключение тестов, всё как у описанных вами разработчиков.
В целом статья похожа на неграмотную попытку использовать e2e как замену процессам тестирования.
Интересная реакция. Вам дали список недочетов, некоторые из которых будут блокировать повтор действий из этой статьи, а в ответ — 🤣. Прошлый материал был более профессиональным.
Может, надо более точечно было написать, что вот тут:
Appium настроен, теперь можно переходить к настройке конфигурации. Создаем конфиг для Appium и конфиг для Selenoid:неплохо было бы указать, какой именно файл создается и где.
А тут
"image": ["appium", "--config", "/Users/mobilefarm.am/selenoid/config/appium/iphonex.json"]поделиться секретным содержимым файла
iphonex.json.Для людей же пишете, а не для KPI по статьям на отдел.
С версиями аппиума тоже есть нюанс. Видимо, вы не в курсе, но раньше при установке беты второго аппиума для IP из России сыпались интересные сообщения в консоль. А может там еще и какие-то скрипты дополнительно исполнялись. И потому было бы неплохо иметь какие-то гарантии, что никаких сюрпризов не будет при установке и после (вы же в альфе делаете какие-то проверки, а не тупо ставите всё подряд?).
И если вам нужно, нет, спасибо, давайте без предположений. Я просто хотел почитать качественную статью.Не указана версия аппиума.
В блоке с конфигами для аппиума и селеноида нет пояснения, где создавать файлы и как называть. В конфиге селеноида есть пути до файлов, но снова нет пояснения, что то за файлы и что в них должно быть и почему такие пути.
Нет объяснения параметров запуска селеноида.
Опечатка в команде для аппиум-доктора.
И нет варианта с запуском симулятора.
Пока что по этой статье шаг за шагом выполнить вряд ли получится задуманное.
Ну вот так точно не надо писать — не надо делать из айтишников каких-то особенных. Они ничем не отличаются от других таких же рядовых сотрудников компании. А так вы только раскалываете, полностью перекладывая финансовый успех на одно направление.
Раз статья для новичков, то выделю то, что их хорошему не научит.
"message_text" и "chat_id" — в джаве принят другой формат именования переменных.
Смущает ".split(" ");" — а если пользователь ввел два и более пробелов случайно? А если клиент телеграма перестанет убирать пробелы до и после текста сообщения, которые тоже случайно были добавлены? А обработка текста со спецсимволами? А если вес на одной строке, а рост на другой? Так что надо тримить, а после из двух и более пробелов делать одинарный. А еще может потом захочется сделать другой разделитель, точка с запятой или еще что-то. А еще проверка на валидность роста, например, что выше 250 быть не может. Кейсов накидать можно много, но хотело бы видеть хотя бы намеки на проверки, хотя бы комментариями. Понятно, что это пет проджект и не более, но привычка подумать о том, как реальный человек будет пользоваться — всегда пригодится. "Все остальные запросы должны блокироваться" — все же это слишком искусственное требование.
Не очень понятно, в чем смысл проверки на наличие пробела ("// если сообщение с текстом содержит пробел"). Она вообще не нужна. Вы же в любом случае делаете массив строк через split и если длина не 2, то отправляете ошибку.
Название переменной "weightAntHeight" тоже не отражает сути массива и может путать.
И неплохо было бы добавить обработку, что если сообщение "/start", то высылать инструкцию. для тех, кто впервые открыл его.
Читая статью, я не знаю, что такое "WriteUser" и "ImtCount". Для этого надо лезть на гитхаб и изучать уже там. Но вот в самой статье это мешает и не несет никакой смысловой нагрузки. Лучше расписать про базу в следующих статьях, материала-то можно много сделать.
Если без этих мелочей, то статья хорошая, пишите еще.
Смотрите, что я увидел.
Вы для автотестов предлагаете писать pipeline, при этом в вашем примере я не вижу ничего такого, чего нельзя было бы сделать через freestyle job. Если я перепишу ваш пайплайн на freestyle job, он разве станет "несложным"?
Как инженер, я хотел бы видеть какую-то аргументацию посильнее, чем
Если же нужно, что-то более кастомное, то тут нам на помощь приходит Pipeline. Пример: отправка уведомления на почту. В freestyle нет возможности указать тело сообщения, в Pipeline - можно. Как минимум по той причине, что для тех же уведомлений на почту есть плагин Email Extension (https://plugins.jenkins.io/email-ext/), который позволяет настраивать что угодно и сейчас ставится чуть ли не по дефолту. Аналогично и с плагином для слака — полная кастомизация (справедливости ради добавлю, что через пайплайн можно настроить еще лучше, но для автоматизации это излишне — нам же по сути нужен статус прогона и ссылка на него).Аргументы с официального сайта, конечно, хороши, но это не ваш опыт. Сравните хотя бы картину пайплайна по ссылке с тем, что описано у вас. И далее по списку преимуществ — часто ли у вас перезапускается контроллер Jenkins, часто ли вам нужно писать реально сложные пайплайны с ветвлениями и зацикливаниями, часто ли вы используете настраиваемые расширения для своего DSL? Почему-то кажется, что вообще нет. Что по всем этим пунктам ответ будет отрицательный. И в таком случае получается, что у такого подхода для автотестов нет преимущества. Для полноценного процесса развертки + тестирования + деплоя — да. Но статья не про это. Ну и следом был бы вопрос — а чем этот подход лучше написания скрипта на груви?
Не поймите неправильно, статья отличная, но для автоматизации тестирования я только один аргумент увидел — хранение в vcs. Но и на это можно возразить, что если джобы настолько сложные, что их нужно где-то хранить, то скорее всего что-то делаете не так.
А в чем преимущество такого подхода перед, например, freestyle job? Кроме того, что этот jenkinsfile можно хранить в vcs.