Привет, Хабр!

Решил написать свое мнение касательно того, заменит ли автоматизация тестирования, собственно, тестировщиков. Прежде всего потому, что довольно часто слышу подобное мнение среди 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-инженер должен быть знаком с автоматизацией. Обычно, у специалистов с этим навыком в резюме и ЗП побольше, и на рынке они ценятся выше. Но заменит ли автоматизация ручную проверку и ручное тестирование? Конечно же, нет.

Итог

Такой получилась эта статья. Я поделился своим мнением и своим видением вопроса. Буду рад узнать о ваших, обязательно делитесь в комментариях!

А еще мы с коллегой из Яндекса разработали онлайн-курс для тех, кто хотел бы погрузиться в автоматизацию мобильного тестирования. Информацию и ссылки можно найти у меня на странице профиля. :)

Спасибо за внимание!