Комментарии 8
Да ё-мое почему у тестировщиц статьи про совсем другое, чем указано в заголовке? Уже вторая за сегодня.
Статья называется «а нужна ли вам автоматизация тестирования». Потом я вижу оглавление и в конце ссылка на раздел «Нужна ли автоматизация?». Я перехожу и вместо весомого описания как это определить с критериями и заметками из собственного опыта - одно водянистое предложение. Зачем вы так делаете?
Не хотелось бы набрасывать негатива, но полностью согласен. Статьи на хабре от тестировщиков впринципе имеют мало практический ценности и много воды. Тут больше на пиар компании Авито похоже и на пиар другого такого же тестировщика. При этом кто сама автор и чего добилась в проф. деятельности и почему к ней должен быть какой-то кредит доверия, не ясно.
Дело в том, что практически невозможно предусмотреть все виды приложение, и этапы в их разработках, чтобы можно было бы дать какой-то конкретный ответ. В данной статье довольно подробно расписаны общие критерии, поняв которые, можно понять, стоит ли заводить автоматизацию на проекте. Сам являюсь автолидом, и почти под каждым словом из статьи готов подписаться.
Надо поделиться своим конкретным опытом в конкретной компании с подробностям - какая проблема была, какие варианты решений, какое решение выбрали и почему, какие результаты. За 13-то лет опыта наверняка найдется о чем рассказать, не?
А данная статья на 80% состоит из очевидных вещей и воды. Такой статье место на vc ru или пикабу. Вы посмотрите на оглавление. "Что такое автоматизация" - серьезно? Тут habr, и народ в целом в курсе что такое автоматизация.
При этом по теме - ничего, кроме общих фраз в разделе признаков. Статья по своей сути, указанной в заголовке, как раз должна была начаться с "Нужна ли автоматизация?". Остальное это введение. Но она на этом закончилась.
Да вроде есть конкретный ответ (из которого и растут уже остальные рекомендации) — экономическая выгода.
почему у тестировщиц статьи про совсем другое, чем указано в заголовке?
Хочу поделиться с вами своими догадками, и для начала немного о мотивах, которые стоят за этой статьей. Возможно, вам будет интересно узнать, что роль автоматизаторов тестирования (или AQA) зачастую оказывается менее заметной, чем, скажем, у менеджеров, разработчиков или даже DevOps-специалистов. У них есть четкие критерии успеха: в срок сделанный проект, поддержка всех заявленных функций продукта или сервер поддерживающий требуемую нагрузку.
Когда мы говорим о тестировании, дело обстоит немного иначе. Результаты, как правило, остаются вне поля зрения пользователя, ведь основная задача отдела качества – сделать так, чтобы все работало без сбоев. Это довольно иронично: когда все идет хорошо, никто не задумывается о том, что именно специалисты ОТК постарались, чтобы так было. Но стоит чему-то пойти не так – и сразу обрушивается внимание с разных сторон: будь то проблемы с оплатой, задержки в отправке уведомлений или сбои в верстке, а как следствие очень важная потеря репутации.
В такой ситуации многие ищут способы заявить о себе: пишут статьи или выступают с докладами. Эти выступления можно воспринимать как «визитные карточки», где меняется имя и компания, но по сути это очень похожие истории. Авторы таких материалов рассказывают миру о своих достижениях и опыте, но делают это рассказывая о типовых инструментах (Selenium, Playwright и т.д.), рассуждая о целесообразности (по сути прикрывая отсутствие сил на проведение ревью на уровне архитектуры и кода) и т.д.
Мне кажется, что такие статьи или выступления могут быть своеобразным признанием предела карьеры для автоматизаторов. Это не просто подведение итогов; это также возможность задуматься о следующих шагах в профессиональном развитии. Такие возможности действительно существуют, но чаще всего они представлены у ведущих игроков рынка, когда тестирование переходит ближе к разработке в SDET. В этом переходе тестирование выходит за рамки простого контроля и превращается в более глубокое понимание работы модулей и компонентов. Например, разработка самого инструментария драйвера для Selenium в Google, появление альтернатив Selenium вроде Playwright в Microsoft и так далее.
Автоматизаторы становятся равноправными участниками разработки, сотрудничая с архитекторами и программистами. Они способны предоставлять ценные инструменты сообществу, данные о производительности, тем самым внося свой вклад в индустрию. Это открывает новые горизонты для профессионального роста и расширяет круг возможностей.
Следует отметить, что переход от автоматизации тестирования к роли SDET подразумевает значительное повышение квалификации. Это путешествие включает в себя полноценное погружение в разработку, где важно не только знание программирования и архитектуры, но и понимание потребностей бывших коллег.
Сложно автоматизировать разные состояния ошибок
Что такое "состояние ошибки" и почему их сложно автоматизировать?
Автоматизация также невозможна при наличии интеграции со сторонними сервисами
А если замокать сторонние сервисы?
Нельзя автоматизировать и look‑and‑feel — оставьте это дизайнерам
Можно. Есть куча софта как раз для этого. Applitools Eyes например.
А нужна ли вам автоматизация тестирования?