Решил написать свое мнение касательно того, заменит ли автоматизация тестирования, собственно, тестировщиков. Прежде всего потому, что довольно часто слышу подобное мнение среди Junior QA, кто только делает свои первые шаги в тестировании и уже боится, что чего-то не успел.
Справедливости ради, подобное мнение бытует и среди ребят постарше. Довольно часто считается, что автоматизация — чуть ли не единственный путь развития ручного тестировщика. Обо всем этом и многом другом под катом.
Небольшое уточнение, прежде чем мы начнем. Вся речь далее будет идти о функциональных автотестах. Это именно UI-тесты, которые не стоит в данном контексте путать с unit-тестами. Последние всегда писались и должны писаться разработчиками, а где это не так — это предмет уже совсем другого обсуждения.
Коротко об истории автоматизации
Я довольно давно работаю в тестировании и видел несколько этапов развития автоматизации тестирования. С ее развитием и отношение к ней тоже менялось. Давайте посмотрим, как оно было, и попытаемся понять — к чему все это идет?
В далеком 2010 году, когда я только делал свои первые шаги в мире IT, такой инструмент, как Selenium был известен далеко не каждому. На тот момент в ходу была его первая версия, которая называлась Selenium Remote Control.
Я помню, как мы автоматизировали наш первый проект на Selenium. Этот инструмент тогда был довольно простой, мог кликать по невидимым элементам, иногда ошибался в поиске локаторов и даже при получении текста некоторых хитрых элементов.
До сих пор помню, что наш шеф называл их “тыкалками”. Видя, как мы сидим и пишем эти тесты, он так и говорил: опять тыкалки свои пишите? Мол, нет бы руками давно проверили и зарелизили.
Но время шло, Selenium развивался, у него появлялись новые возможности. Сначала была вторая, а теперь и третья его версия. Появился стандарт (производители браузеров стали сами писать драйверы), Selenium оброс несколькими протоколами, обзавелся конкурентами на рынке и сейчас про него уже знает практически любой работающий в IT специалист независимо от его принадлежности к QA.
На данный момент существует много решений для автоматизации тестирования как веб, так и мобильных приложений.
Теперь это уже не просто тыкалки, теперь средний разговор с HR на QA-позицию выглядит так (утрированно, конечно):
— Добрый день. По Вашему резюме не понятно, Вы умеете писать автотесты?
— Нет, но я хорошо разбираюсь в…
— *трубку уже повесили*
А если это позиция лида, то ты слышишь, что им бы хотелось в первую очередь настроить автоматизацию, а уже потом нанимать QA-инженеров. Или не нанимать. А вдруг не надо? Это ж экономия какая. Еще и тебя после того, как напишешь все тесты, уволить бы. И разработчиков, когда все сделают… Оставить бы на сайте одну кнопку “Плати сюда” и укатить в закат… Что-то меня понесло не туда.
Конечно, при таких тенденциях возникает вопрос: заменит ли автоматизация ручное тестирование? И когда это случится?
Автотесты глазами разработчиков
Чтобы ответить на этот вопрос, стоит в первую очередь подумать — а кто пишет автотесты? Я видел компании, в которых автотесты пишут сами разработчики. И видел компании, где автотесты пишут QA-инженеры. Как думаете, в чем принципиальная разница?
Хочется предположить, что разница в коде. Мол, раз они разработчики, то и код пишут лучше. Следовательно — тесты их лучше. Но это не совсем так.
Качество кода, несомненно, важный параметр, но у самих разработчиков тестирование — это не основное занятие. И потому выделить на него много времени они не могут. Тесты пишутся на скорую руку и код довольно часто оставляет желать лучшего. И это нормальная ситуация, повторюсь — это не то, на что они должны тратить существенный отрезок своего рабочего времени.
Тем более хороший код — это не самое главное в автотестах. Куда важнее то, какие кейсы эти автотесты покрывают. И вот тут уже мышление QA-специалиста существенно отличается от того, как продукт видит разработчик.
Рассмотрим пример. Надо покрыть автотестами регистрацию на сайте. Ясно, что в первую очередь мы будем покрывать позитивный кейс. Зашли, забили форму из пяти-шести полей ввода, прошли какие-то дополнительные этапы вроде подтверждения через почту или смс — тест готов, вы прекрасны!
Я утверждаю, что 90% разработчиков, на которых свалились обязанности по написанию автотестов, на этом остановятся. Часть кейсов они не опишут потому, что считают их ничем существенно не отличающимися от уже покрытого. Часть просто не учтут. Да и вообще “я же сам писал продакшн-код, там все надежно и на века”.
Классы эквивалентности, граничные значения, негативные кейсы — все это остается где-то в стороне.
Подход QA-инженера
QA-инженер использует другой подход. За его плечами опыт, понимание принципов тест дизайна, достаточное количество времени и, главное, искать баги и заниматься проверкой его прямая обязанность. Плюс, чаще всего, таким людям просто интересно что-то проверять. Что будет, если ткнуть сюда вне очереди? А если ввести данные сюда некорректно?
Именно подход отличает QA-инженера от разработчика. И его формирует не умение автоматизировать тестирование, а образ мышления. Плохой тестировщик напишет плохие тесты. В этом случае хороший тестировщик обнаружит больше проблем при ручной проверке, чем плохой с его кучей непродуманных тестовых сценариев.
Какой вывод я хотел бы из этого сделать? Все очень просто. QA-специалист — это в первую очередь понимание принципов тестирования и опыт тестирования, который имеет человек. А не инструменты, которыми он пользуется.
Конечно, быть просто хорошим тестировщиком недостаточно. Без знания основных инструментов, таких как bash, Git, SQL и т.д эффективно работать в любой компании невозможно. Их обязательно надо изучать.
Автоматизация — это такой же инструмент, он сам по себе не хороший и не плохой. Он не сделает вашу работу эффективнее просто потому, что вы взяли его в руки. К нему еще необходимы определенные навыки.
Ну а что там с ручной проверкой?
Ручная проверка никуда не денется. Так или иначе, когда мы видим перед собой новую фичу или целый продукт, мы будем изучать его руками. Нам все равно необходимо разобраться с тем, как он устроен, какие кейсы считать приоритетными и вообще, работают ли они сейчас. Какой смысл кидаться писать тест, если продукт сломан?
И так будет всегда, с каждой новой фичей или внесенным изменением. Сначала будет этап ручной проверки. И только потом — покрытие или актуализация тестов вокруг него.
Будет лучше, если ручную проверку и написание автотестов будет выполнять один специалист или поделить обязанности? Не знаю, это уже зависит от особенностей того, как построен процесс именно в вашей компании. Где-то это будет эффективно и, следовательно, выгодно. А где-то — нет.
Так что на вопрос, стоит ли изучать автоматизацию тестирования, я категорически отвечаю да. QA-инженер должен быть знаком с автоматизацией. Обычно, у специалистов с этим навыком в резюме и ЗП побольше, и на рынке они ценятся выше. Но заменит ли автоматизация ручную проверку и ручное тестирование? Конечно же, нет.
Итог
Такой получилась эта статья. Я поделился своим мнением и своим видением вопроса. Буду рад узнать о ваших, обязательно делитесь в комментариях!
А еще мы с коллегой из Яндекса разработали онлайн-курс для тех, кто хотел бы погрузиться в автоматизацию мобильного тестирования. Информацию и ссылки можно найти у меня на странице профиля. :)
Спасибо за внимание!
Комментарии (30)
SemenPV
27.08.2019 17:28+1Ручная проверка никуда не денется. Так или иначе, когда мы видим перед собой новую фичу или целый продукт, мы будем изучать его руками.
Надо просто назвать это правильно не тестирование, а например user acceptance.
С ручным тестированием нету масштабирования и предсказуемого времени отклика. Если это не требуется и цена ошибки приемлема, то конечно будут вручную тестировать.
Но мне кажется придут к решению когда в язык будет встроены конструкции для поддержки тестирования и не скомпилируешься без написания тестов.
armid
27.08.2019 17:49+1Ручная проверка никуда не денется
В некоторых отраслях возможно. Но в тоже время при текущей модели разработки приложений, а именно очень частые релизы, обилие встроенных инструментов телеметрии и обратной связи, то в какой то мере можно сказать что сейчас многие ошибки отлавливаются на реальных пользователях и тут же достаточно быстро развертывается исправление.
saver Автор
28.08.2019 08:33+1Я думаю, зависит от приложения. Всякий «интертеймент» — возможно, и правильно!
А как насчет банковского софта, например? Там на живых пользователях не получится экспериментировать.
Kanut
27.08.2019 18:00Ручная проверка никуда не денется. Так или иначе, когда мы видим перед собой новую фичу или целый продукт, мы будем изучать его руками. Нам все равно необходимо разобраться с тем, как он устроен, какие кейсы считать приоритетными и вообще, работают ли они сейчас.
Для меня это не «ручное тестирование», а скорее «фаза анализа». И её действительно придётся делать всегда.
Но во первых это совсем не обязательно «делать руками». То есть даже если сейчас другого инструментария нет, он вполне себе может появиться позже.
А во вторых само тестирование начинается уже после этого. И его можно либо делать вручную(то есть десятки и сотни раз одни и те же телодвижения), либо каким-то образом автоматизировать и сэкономить себе кучу времени и нервов.
Ну и в третьих уже сейчас часто встречается что «фазу анализа» делает один человек, а само «тестирование»(ну или как минимум итерации начиная со второй) другой/другие.
И поэтому с моей точки зрения рано или поздно автоматизация заменит ручное тестирование.
slonopotamus
27.08.2019 19:59+1Непонятно что вы вкладываете в слово "заменит".
Например: возможно ли создать программу, решающую задачи клиента в приемлемом для него качестве, при этом тестирование которой вручную не выполняется на хоть сколько-нибудь регулярной основе и в команду разработки которой не входят выделенные QA, занимающиеся ручным тестированием? Конечно, да.
saver Автор
28.08.2019 07:35Конечно да. Но тут Вы говорите о возможности отказаться от тестирования:
при этом тестирование которой вручную не выполняется на хоть сколько-нибудь регулярной основе
Тогда за качество будут отвечать разработчики. Может у них получиться выпустить продукт хорошего качества? Конечно может!
Но я говорил скорее о том, что если все же тестирование необходимо, возможно ли его полностью передать автоматике? И склоняюсь к тому, что без определенной экспертизы — нет, нельзя.
Orange11Sky
27.08.2019 22:20+2Вот подумалось: А если робот Фёдор вручную займется тестированием — это будет автоматизация или ручное тестирование?
24twelve
28.08.2019 06:45Тем более хороший код — это не самое главное в автотестах.
Позвольте с вами не согласиться.
Если вы захотите покрыть тестами весь регресс немаленького продукта, вам потребуется много тестов. Работать с большой кодовой базой это сложно. Разраьотчики это умеют, а тестировщики — нет.
Вам будут нужны много доработок по тестируемости приложения — без них вы не сможете сделать тесты с 99,99% стабильностью и они будут только мешать. Разработчики могут вносить правки в приложение, а тестировщики не могут (плохо кодят + не знают код продукта).
Если ваши разработчики не будут обязаны писать тесты, то вы их не заинтересуете помогать с вещами, которые я описал. И у вас не получится отказаться от ручного тестирования регресса.
Без хорошего кода ваши автотесты далеко не уйдут ;)
saver Автор
28.08.2019 07:49+1Позвольте с вами не согласиться.
А иначе зачем мы здесь? :)
Работать с большой кодовой базой это сложно. Разраьотчики это умеют, а тестировщики — нет.
Я бы не был столь категоричен, оценивая навыки тестировщиков программировать. Это не настолько элитарный навык, чтобы его невозможно было освоить за год или два на приемлемом для работы с большой кодовой базой тестов уровне.
Вы все верно говорите, для описанной Вами задачи потребуется и много тестов, и их стабилизация. И без помощи со стороны разработки обойтись будет сложно. Ну, никто и не предлагал запираться в пещере и писать тесты втихую. :)
Без хорошего кода ваши автотесты далеко не уйдут ;)
Как бы круто не были написаны тесты, если они не проверяют реальные юзер-кейсы в достаточном объеме, то, особенно на «немаленьком продукте», их ценность мала. И потому именно покрытие первично, так как оно решает бизнес-задачу. А качество кода вторично. Я это имел в виду.
Вот Вам пример простой (бесплатной) формы с учетом проверенных кейсов, на которой можно оценить все их разнообразие, требующее проверки: ссылка.
О каком количестве этих кейсов подумает человек, не занимающийся тестированием?24twelve
28.08.2019 10:40Про код тестов я с вами не согласен. Даже у многих разработчиков навыки поддержки больших кодовых баз не очень хороши. При том, что они full time работают с кодом. Тестировщикам еще сложнее приобрести эти навыки, потому что кроме кода, у них много других дел и нет опытного наставника-разработчика. А проблемы в больших кодовых базах с тестами — такие же злобные, как в продакшн коде.
Проблемы с покрытием решаются, если не сваливать автотесты только на разработчиков или тестировщиков. Я согласен с вами, что разработчик скорее всего покроет только очевидные сценарии. А тестировщик может подумать после него и дописать тестов. В такой модели и код тестов нормальный, и разработчик добавил тестируемость в систему и покрытие ниче так.saver Автор
28.08.2019 11:04Все так. :)
Просто как менеджер проекта, например… между плохой кодовой базой тестов, но богатым покрытием и наоборот я выберу именно первый вариант. Да, будут проблемы с допиливанием, рефакторингом, внесением изменений и расширением. Особенно если никто в команде этого не умеет. Но это проблемы внутренние, пользователи о них ничего не знают. Зато благодаря покрытию продукт тестируется хорошо и наружу выйдет качественным. И это увидит пользователь.
И я сравнивал это, конечно, с альтернативой — хороший код, но плохое покрытие. Потому что сравнивать это с хорошим кодом И хорошим покрытием как-то глупо. :)24twelve
28.08.2019 11:18Выбирая плохое качество кода в тестах, вы также получаете:
- Долгую поставку фич. Например, потому что тесты писать сложнее и сложнее. Или потому что они нестабильные, надо возиться с их падениями.
- Озлобленных инженеров. «на фичу ушел день, а только на написание тестов еще три дня» — такое бесит людей. Еще людей раздражает писать плохой код, потому что они начинают себя с ним ассоциировать :)
- Длинный цикл обратной связи для разработчиков. Если программисту сложно проверить, как работает его код — он попросит тестировщиков. И о багах в основном сценарии узнает не сразу, а через много времени. Это тоже сильно удлинняет время поставки фич.
Я думаю, что менеджеров проектов должны волновать такие вещи. Как минимум, на долгих проектах.
Хорошее качество обеспечить можно и с ручным тестированием. Между хорошим кодом с плохим покрытием и плохими тестами с хорошим покрытием я бы выбрал первое.
saver Автор
28.08.2019 11:22Между хорошим кодом с плохим покрытием и плохими тестами с хорошим покрытием я бы выбрал первое.
Ваше право. Мои аргументы тут исчерпаны. :)
dimoff66
28.08.2019 07:08-1"Последние всегда писались и должны писаться разработчиками,"
Как только появляется слово должен, или слово обязательно, тема из раздела аналитики переходит в раздел религии, особенно для начинающих, читающих статью авторитета и складывающих как мартышки на задворки бессознательного все эти" должен" и" надо обязательно", не рассматривая все плюсы и минусы и не анализируя. Особенно этим грешат американцы, которым все нужно перевести в технологию, чтобы не страдало их квадратное мышление.
Преимуществом юнит тестов называется быстрота проверки. Но куда вы торопитесь? Вам нужно релизить через секунду после каждого изменения? Вы не в состоянии подождать 10 минут прогон функциональных тестов? А если вы захотите сделать рефакторинг модуля, вы четырежды подумаете, поскольку придется юнит тесты переписывать, при том что логика самого функционала не поменялась ни на йоту.
Так что в каждом конкретном случае нужно думать и анализировать ситуацию на проекте в целом, а не зомбировать незыблемыми заповедями.
dedmagic
28.08.2019 08:52+1Вы спорите с утверждением, что "юнит-тесты должны писаться", хотя автор написал, что "если на проекте пишутся юнит-тесты, то это должны делать разработчики, а не тестировщики".
А если вы захотите сделать рефакторинг модуля, вы четырежды подумаете, поскольку придется юнит тесты переписывать, при том что логика самого функционала не поменялась ни на йоту.
Вот из этого видно, что Вы юнит-тесты никогда не писали. Они пишутся на API класса, а при рефакторинге API не меняется, соответственно, тесты переписывать не нужно.
Более того, при рефакторинге юнит-тесты гарантируют, что ничего не сломалось — ибо поведение класса для внешнего мира не изменилось.
ganqqwerty
28.08.2019 10:22А что с применением всяческих там нейронных сетей для автоматизации труда ручного тестирования? Ну типа, сетка глядит-глядит на то, как человек все прокликивает, а потом начинает сама прокликивать.
saver Автор
28.08.2019 10:24+1Ну типа, а если проект меняется? Добавляется совершенно новая фича? Обратно нанимать отдел тестирования, чтобы обучить нейронку? :)
Kanut
28.08.2019 10:34Как насчёт оставить пару-тройку «QS-инженеров» для таких случаев, а всех остальных заменить на «нейронку» или какой-то другой вариант автоматизации?
П.С. Я совсем не отрицаю необходимость грамотных QSников, но почти во всех фирмах где я работал 50-75% от всех тестировщиков были простые «кликеры» которые тупо тестировали по готовым тесткейсам…saver Автор
28.08.2019 10:59Видимо, в тех случаях, о которых говорите Вы, это было дешевле. Не знаю, тут надо на более определенных примерах смотреть и рассуждать.
Я совсем не отрицаю необходимость грамотных QSников
Именно о них и речь. Грамотные тестировщики против грамотных фул-тайм автоматизаторов. Как только мы говорим, что по одну из чаш весов «кликер» или «быдлокодер», сравнение уже не корректно. Квалификации должны быть соизмеримы для сравнения. Согласны?Kanut
28.08.2019 11:09Если честно, то я до сих пор вообще не проводил грани между «грамотными тестировщиками» и «грамотными фул-тайм автоматизаторами». Для меня «грамотный тестировщик» подразумевает под собой, что он при необходимости умеет и автоматизировать. Ну или как минимум может этому научиться :)
П.С. И наверное опять есть некая путаница в понятиях и разные люди понимают разное под «ручной тест» или «тестировщик».saver Автор
28.08.2019 11:15Для меня «грамотный тестировщик» подразумевает под собой, что он при необходимости умеет и автоматизировать.
Суть моей статьи в одном предложении. Спасибо! :)
Да, именно так и должно быть, кмк. Но увы, рынок сейчас устроен иначе. Есть те, кто по разным причинам занимается только ручным тестированием.
Это не всегда люди ленивые или глупые. Порой проблема кроется в самой компании. Даже в крупных есть разделение на тех, кто занимается автоматизацией фул-тайм, и тех, кто должен заниматься только ручным тестированием и в автоматизацию не лезть никогда, ни за что. Отчасти из-за этого последним и кажется, что автоматизация тестирования — это что-то вроде левел-апа в карьере, следующего витка развития и что-то элитарное. И именно с этим стереотипом хочется бороться или как минимум высказываться против него.
savva_genchevskiy
29.08.2019 19:00+2Лайк!) Полностью согласен) Сразу видно что эту статью писал человек у которого есть необходимые знания и компетенция в тестировании, потому что все всегда начинается с ручного тестирования и тест-дизайна, организации методологий эффективной работы и включения тестирования в цикл… Кто бы там на своих конфах что не говорил, но я точно знаю, когда что-то начнет валиться и разваливаться, все быстро побегут искать тестировщиков))
Terras
1) Мысли правильные
2) Написать каркас тестов + интеграцию с jenkins(teamCity) — трудоемко и сложно.
3) Расширять тесты — легко (там вообще хватает начальных навыков Java + базовое понимание html/css/js + Rest API)
__
Но как правило, если человек более менее начинает разбираться в тестах, он переходит в разработку на Java. Ибо там платят гораздо больше, чем в QA (если ты не тот самый чел, который делает пункт 2)
adante
Хм. По-моему как раз каркас пишется сравнительно несложно, в сети куча мануалов и best practices, если нет особых заморочек специфичных для проекта, то < недели с минимум опыта. Расширять сложнее в плане дизайна тестовых сетов, надо постоянно отвечать на вопросы «надо ли это автоматизировать вообще или быстрее/дешевле оставить на мануале» и «какие конкретно кейсы автоматизировать».
Иначе можно получить портянку автотестов, которые выполняются часами и проверяют, что система правильно складывает 2+2
Volganin5
Мне, например, хочется в DevOps потом двигаться больше. В будущем, прикрутить свои тесты к CI/ CD было бы здорово. Да и вакансий таких все больше появляется.
saver Автор
Мы на курсе по автоматизации как раз учим тому, как написанные тесты для Android и iOS прикрутить к Jenkins. Приходите, если будет интересно. Ссылка есть в профиле.
Volganin5
К сожалению (или счастью), у меня бэкенд на Go + gRPC. Там своя атмосфера (:
vonaburt
Java-разрабов пруд-пруди, а вот толковых qa-специалистов на рынке мало, и их готовы брать на высокие ставки. Не согласен с вашим «как правило» )