Артём Ерошенко — 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-го декабря, чтобы поговорить о важных темах в тестировании, обсудить проблемы и найти решения.
Комментарии (13)
tommy_lee
24.11.2021 17:44+1общаюсь с компаниями за рубежом и часто слышу, что ручного тестирования у них уже нет совсем
Неужели прям сразу пилят фичу и релизят не глядя, просто по результатам прохождения автотестов?
lxsmkv
24.11.2021 18:19+3Это может значить, что они просто не держат такую позицию. Но ведь и автоматизатор тестирования в первую очередь тестировщик. А может быть такое, что заказчик или группа ключевых пользователей сами частично проводят «приемку».
Вопрос же как стоит: как обеспечить нормальную скорость отгрузки, если тестировать по две недели после компоновки релиза? Чтобы настроить такой процесс, нужен тест-менеджер, тестировщики, нужно согласовывать и обновлять тестовые сценарии. На все это заказчик не хочеть тратить время и деньги. Поэтому он покупает автоматизацию тестирования, где ему показывают, что фича была покрыта автотестом, показывают репорты. И на это на все нужен всего один человек, а не целая команда, и тестирование происходит «постоянно». T.e. это скорее компромиссное решение в сторону снижения затрат, а не повышения качества.
Если сравнивать автотест с ручным тестовым сценарием то по моему опыту с автоматизацией ты можешь добиться удаления большего количества ошибок, чем ручной тестировщик. Ты просто можешь например сказать, что автоматизация из-за этого работает медленнее, или сыпется. Или из-за неконсистентного поведения ты не можешь написать вменяемый скрипт. А ручной тестировщик всегда проблему может «обойти». Автомат ничего «обойти» не может и в этом его прелесть. В этом отношении машине больше доверия.
Я на своем старом проекте будучи автоматизатором репортил в несколько раз больше багов чем ручные тестировщики с эксплоративным подходом.
Да и если коснуться вопроса сколько проекту нужно «качества», мы понимаем, что многие клиенты не ракеты в космос запускают, им там супер качество и не нужно. Так, чтобы очевидные вещи не сыпались и уже неплохо. А когда ты закрыл регресс автоматизацией у тебя появляется время/возможность «шерудить шваброй в темных углах» приложения. Смотреть на качество кода, делать QA Achitecture (работать над тем, чтобы встроить качество в архитектуру и процесс разработки)
Подводя итоги скажу:
Автоматизация не замена ручному тестированию, а производственная необходимость. Ее именно так нужно рассматривать. Ты без автоматизации будешь неконкурентноспособным, просто не сможешь держать темп.eroshenkoam
24.11.2021 18:35+1Ого, ты меня опередил) Я тебе респектую от души и согласен с каждым твоим словом)
Вот это вообще топ:
Ты без автоматизации будешь неконкурентноспособным, просто не сможешь держать темп.
tommy_lee
24.11.2021 19:23время/возможность «шерудить шваброй в темных углах» приложения
В любом крупном проекте подобных задач набирается столько, что по-факту над ними работает отдельная команда SDET, так сказать, in Manual Testing. Но в вакансиях и резюме все пишут парочку хайповых фреймворков автоматизации, дабы не прослыть ретроградами.
Особенно это забавно на фоне того, что индустрия идёт по пути специализации - ведь уже даже есть отдельные специалисты по мейкфайлам и нажиманию кнопки Build. Но «тестирование у нас делают разработчики», ну да
lxsmkv
24.11.2021 20:31Я бы не обобщал. Проекты разные бывают. Бизнес-модели разные.
Часто под разработкой люди понимают разработку своего продукта, но в айти на самом деле гораздо больше контрактной работы. Где ты предоставляешь заказчику работу/команду как сервис. А в контрактной работе тебе нужно предложить заказчику пакет услуг по приемлемой для него цене. И тут договориться об оплате выделеной роли не так просто. Конечно, подрядчик пытается увеличить чек, но конкуренция бешеная и это весьма и весьма сложно. Конкурренты демпингуют жестко, даже не имея необходимых компетенций, лишь бы получить контракт, а там хоть трава не расти. Поэтому работа айтишников сильно зависит от ловкости отдела продаж, смогут они охмурить заказчика или нет.
То, куда идет индустрия в конце концов решает рынок. Поэтому сервисные компании подбирают такой режим работы, чтобы во первых быть дешевле и получить заказ, а во вторых увеличить маржу, например, запихивая в проект джуниоров, и студентов.
А когда компания работает на себя, там другие мотивы. Они конкурируют продуктом.
Так что есть наше профессионально обусловленное представление о том как было бы лучше, и есть рынок, который все эти твои фантазии и мечты о лучшем мире жёстко херачит об асфальт и либо ты идешь на галеры, более или менее устроеные, либо ты идешь ко всем чертям (во фрилансеры).tommy_lee
24.11.2021 21:35Собственно о том и речь, что, несмотря на 30 лет обещаний консультантов всё автоматизировать, ни одна компания не обходится без ручного тестирования. И не так уж важно, занимается ли этим разработчик в нагрузку или отдельный человек - по факту затраты на это не уменьшились.
Это касается и крупных компаний из FAANG, где нет выделенной роли тестировщика нет только в Facebook (все знают уровень качества и удобства её продуктов)
xsash
24.11.2021 20:55+1Автоматизация процессов - это безусловно необходимость и сильно сокращает время регресса. Только всегда появляются ньюансы
1) Кто пишет автотесты? Встречаю команды, где работают в автоматизаторах разработчики и все тесты, условно, "в лоб" написаны, а чуть влево-вправо отойти от теста и лезут баги.
2) Если гонять только автотесты, можно получить эффект дихлофоса. Вроде все прогоны зеленые, но в саппорте жалобы
3) В процессе разработки нужно уже продумывать сценарии и окружение. Разработчики, хоть и покрывают свой код юниттестами, но часто не знают пользовательских сценариев
lxsmkv
24.11.2021 21:40Да, все так. Часто тесты пишутся «в лоб», подгоняются под приложение, и реальные пользовательские сценарии не учитывают. Только вот это не проблема автоматизации как таковой. И имея отдел ручных тестировщиков можно иметь баги на проде, и тестировщики будучи людьми могут закрывать глаза на некоторые недочеты в приложении (по разным причинам) и тестовые сценарии для ручного прогона могут не покрывать всех пользовательских сценариев.
Потому что тестирование это борьба с комплексностью. Это решение задачи не как покрыть все (это невозможно на практике), а как с минимальными затратами покрыть наиболее критичные области приложения.
Поэтому хорошая метрика, не количество человекочасов в тестировании, или количество пройденых тесткейсов, а количество задокументированых багов. Нужно увеличивать выхлоп от тестирования, а не расширять тестировочные активности. Я бы еще ввел метрику соотношения найденых недочетов к задокументированым багам. У меня есть основания полагать, что далеко не все найденые недочеты попадают в беклог. Существенная их доля растворяется в дискуссиях. «Оно всегда так работало», «Давай не будем будить спящих собак», «У нас нет спецификации на это» и пр. и пр. Несгибаемых тестировщиков небывает, хоть к этому и надо стремиться.
Всё это компромиссы, компромиссики, которые потом боком выходят. Приведу тут еще раз тут эту поучительную историю:При подготовке полета «Аполлона-8», первого пилотируемого космического корабля, добравшегося до орбиты Луны, Маргарет Гамильтон удалось обнаружить серьезную уязвимость, но никто не поверил, что она представляет реальную угрозу. Найти эту уязвимость помогла дочь Гамильтон, которая играла с симулятором компьютера «Аполлона-8», пока ее мать работала. В какой-то момент она включила последовательность P01, запускаемую перед стартом космического корабля, когда симулятор был уже в «полете». Запуск P01 в неподходящий момент привел к сбою; и хотя у космонавтов нет никаких причин допускать такую ошибку, Гамильтон решила добавить несколько строчек кода — сделать своего рода «защиту от дурака». В NASA воспротивились, сочтя, что прекрасно подготовленные астронавты никогда в жизни не смогут так ошибиться. Тогда Гамильтон включила строчку «Не запускайте P01 во время полета» в документацию, но и это показалось руководству излишней мерой предосторожности.
— Маргарет Гамильтон: «Пацаны, я вас на Луну отправлю»
Вскоре после Рождества в 1968 году, когда «Аполлон-8» должен был покинуть орбиту Луны и отправиться на Землю, астронавт Джеймс Ловелл сделал именно то, чего от него никак не ждали — по ошибке запустил P01
xsash
24.11.2021 22:10+2Подобные метрики все таки, либо не работают, либо сложны в понимании, либо слишком много коэффициентов и поправок нужно вводить. Баги бывают сильно разные: приоритеты, затронутые компоненты, а так же заведение бага. Если баг не только был найден и задокументирован (вот баг, надо починить), но и был исследован так, что сразу понятно в какой компоненте или функции проблема, что экономит ресурсы разработчиков?
Скорее, показатель качества продукта - сколько багов (и какой серьезности) нашли пользователи и как сильно саппорт завалило тикетами.
Если коллеги из саппорта не приходят с фразой "как вы это ***** тестировали!?" - значит релиз вышел приемлимым
VictorKharlamov
26.11.2021 14:01+1Вот поэтому из-за того, что они пишутся "в лоб", а если хочется продукт не кривой как ФБ, то отдел QA необходим. Для меня яркий показатель это Тинькофф. Где автотесты пишут разработчики, покрывающие регресс и фичи соотвественно, но пишут тест-кейсы и тестируют фичи – ручные QA. Ибо QA это больше про коммуникацию и процессы, а не тупое тыканье в аппликуху. Поэтому я скорее поверю в подобный коллаб QA/Developer, чем в вымирание ручного тестирования. Насчёт "машину не отманишь", "с человеком можно договориться", такое ощущение мы про госдуму говорим, а не энтерпрайз. Тысячу раз сталкивался с майндсетом разработчика, что для него это работает правильно, ведь под капотом же ок, а на юзкейсы (проще говоря) в ширь он не мыслит. И это правильно, в голове он видит код, а не юзера.
EvilsInterrupt
25.11.2021 13:00@eroshenkoam Спасибо за статью, уже заплюсовал. Хочу поинтересоваться, а не собираетесь ли вы делать доклад про то кто такой FullStack QA ? Очень хотелось бы услышать именно вашего развернутого мнения поэтому вопросу
Oriolidae
25.11.2021 13:53Из серии "Меня зовут %username%. Мне нравилось быть тестировщиком и нажимать на кнопки в приложениях, проверять, все ли они работают так, как это задумывалось изначально. Но со временем для качества ПО этого стало не достаточно, и я решил стать кем-то другим, чем-то другим (не "Зеленой стрелой", но "Серебряной пулей")"
lxsmkv
Ерошенко прошареный чувак, слушаю его с удовольствием. Говорит правильные вещи.