Заменит ли автоматизация ручное тестирование?
Привет, Хабр!
Решил написать свое мнение касательно того, заменит ли автоматизация тестирования, собственно, тестировщиков. Прежде всего потому, что довольно слышу подобное мнение среди 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-инженер должен быть знаком с автоматизацией. Но заменит ли автоматизация ручную проверку и ручное тестирование? Конечно же, нет.
Итог
Такой получилась эта статья. Я поделился своим мнением и своим видением вопроса. Буду рад узнать о ваших, обязательно делитесь в комментариях!
А еще мы с коллегой из Яндекса разработали курс для тех, кто хотел бы погрузиться в автоматизацию мобильного тестирования. Информацию и ссылки можно найти у меня на странице профиля. Курс на Java, достаточность своих знаний можно проверить по ссылке. Ведь все любят тесты, разве нет? :)
Спасибо за внимание!
