Артём Ерошенко — CPO и сооснователь Qameta Software. Он преподает тестирование, хостит подкаст «Айтишники», делает доклады в IT-сообществе, а 1 декабря во второй раз станет ведущим QA Meeting Point. Артём рассказал, зачем делиться знаниями и почему он не верит в будущее ручного тестирование.
Мотивация выступать
Когда я пришел в Яндекс, то уже через год начал делиться опытом с коллегами. Мне нравилось унифицировать наши знания и делать их общедоступными.
Сейчас доклады дополняют мою профессиональную деятельность. Во-первых, чтобы мы в Qameta Software могли и дальше разрабатывать Allure, нам необходимо следить за трендами, общаться с тестировщиками, понимать, что им нужно, а что — нет. Во-вторых, я еще занимаюсь консалтингом. Публичные выступления помогают привлекать клиентов. Люди обращаются, потому что им близки мои взгляды.
Но моя основная мотивация — поделиться тем, что я считаю правильным.
Для меня важно, что публичная деятельность помогает другим компаниям избегать ненужных ошибок. Например, ко мне приходили клиенты, которые хотели выстроить процессы внутри команды. За два года они написали 200 автотестов, из которых половина падала. Я рассказал об этой проблеме в докладе, а процесс по ее устранению обозначил как TestOps. Теперь на эту тему есть доступный материал, и любой желающий может на его основе оптимизировать работу.
Вместе со Стасом Васенковым я организовал школу для тестировщиков QA.GURU. По сути, это тоже часть всей системы по обмену знаниями. Часть первая: мы передаем все, что знаем, друим специалистам. Часть вторая — выступления и доклады на конференциях. Тут я рассказываю про тренды, пытаюсь показать путь, по которому, как мне кажется, нужно идти. Часть третья — консалтинг: по сути это применение идей. Я проверяю, как они работают в разных условиях и при разных вводных. А результат всей этой активности воплощается в инструментах Qameta Software.
Конец ручного тестирования
Сразу оговорюсь, конец большей части ручного тестирования, которая состоит из регрессионного тестирования. Наивно полагать, что здесь будут какие-то изменения, кроме автоматизации. Если посмотреть вокруг, то сегодня даже на бытовом уровне всё автоматизируется. Приведу пример: раньше мы ходили в магазин, и вместо нас продавщица за прилавком собирала продукты. Но все изменилось: сначала появились супермаркеты, потом кассы самообслуживания, теперь и вовсе доставка из приложения на телефоне.
Все эти перемены совершенно точно сопровождались тревогой со стороны владельцев бизнеса и работников. Но в итоге для всех проблем нашлись решения, а у нас появился более удобный способ выполнять те же действия за короткий срок. И это нормально. Разве что в условном селе Берёзовка остались простые магазины, но там нет ни потребности, ни ресурсов в гипермаркете и доставке.
То, что сейчас в таком объеме существует ручное тестирование, не значит, что для индустрии это норма. Это говорит о том, что наша индустрия не доросла до перемен. Я общаюсь с компаниями за рубежом и часто слышу, что ручного тестирования у них уже нет совсем.
На мой взгляд, сейчас наблюдается тренд, когда у тестировщиков вообще остается все меньше ответственности. Например, я сильно сомневаюсь, что еще будут появляться фреймворки от тестировщиков. Разработчики забрали на себя API- и UI-тесты, много фреймворков появилось в JavaScript, Microsoft активно развивает эту тему. Мне сложно представить, что появится новый Selenium от тестировщиков. Эту инициативу перехватили — сейчас этим будут заниматься разработчики.
Развитие для QA-инженера
На мой взгляд, есть несколько направлений, куда стоит развиваться.
Нативные автотесты. Фреймворки «из коробки» довольно крутые, и дают нам больше возможностей, чем те инструменты, что используем мы. Посмотрите на фичи Cypress, Playwright, Spring Test и вы поймете, что тестировать API и UI можно гораздо проще, чем вы это делаете сейчас.
Автотесты около кода разработки. Изучайте, как ваши end-to-end тесты перенести ближе к коду, чтобы они там работали правильно и прогоняли бизнес-сценарии. Это для тех, кто хочет заниматься непосредственно тестированием.
Инфраструктура. Разработчики уже решают проблему автотестов, но они пока не хотят заниматься тестированием разного рода конфигураций. Сейчас тестировщикам стоит больше изучать это направление: как разворачивается тестинг, как работать с docker, как в этой области устроено тестирование. Эта область очень интересная, и ниша не занята.
Внедрение методологий, даже если у вас в компании нет активности на эту тему. Возможно, просто не нашелся человек, который готов взять на себя ответственность за этот процесс. Сформулируйте свой подход, возьмите мой, если наши взгляды совпадают, — примеры можно посмотреть в моих докладах.
Больше опыта вы получите, если будете работать на стыке инфраструктуры и разработки. Тут вы будете сопровождать релизы, настраивать технические вещи. При этом не нужно досконально знать, как работает Docker или Ansible. Надо пользоваться тем, что уже есть.
А самое крутое — если вы в целом возьметесь за трансформацию в компании. Но надо понимать, зачем это делаете и почему. Единственное, от чего тут надо сразу избавиться — от вашего скепсиса. Узнайте про опыт других компаний, посмотрите, как это можно транслировать на вашу ситуацию, сформулируйте плюсы, правильно донесите их руководству. Это интересно и с точки зрения задач, и с точки зрения вызова.
Оставайтесь в тренде — регистрируйтесь на онлайн-конференцию QA Meeting Point. Встретимся 1-го декабря, чтобы поговорить о важных темах в тестировании, обсудить проблемы и найти решения.
