Хабрахабр

Заменит ли автоматизация ручное тестирование?

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

Прежде всего потому, что довольно слышу подобное мнение среди Junior QA, кто только делает свои первые шаги в тестировании и уже боится, что чего-то не успел. Решил написать свое мнение касательно того, заменит ли автоматизация тестирования, собственно, тестировщиков.

Довольно часто считается, что автоматизация — чуть ли не единственный путь развития ручного тестировщика. Справедливости ради, подобное мнение бытует и среди ребят постарше. Обо всем этом и многом другом под катом.

Вся речь далее будет идти о функциональных автотестах.
Небольшое уточнение, прежде чем мы начнем. Последние всегда писались и должны писаться разработчиками, а где это не так — это предмет уже совсем другого обсуждения. Это именно UI-тесты, которые не стоит в данном контексте путать с unit-тестами.

Коротко об истории автоматизации

Я довольно давно работаю в тестировании и видел несколько этапов развития автоматизации тестирования. С ее развитием и отношение к ней тоже менялось. Давайте посмотрим, как оно было, и попытаемся понять — к чему все это идет?

На тот момент в ходу была его первая версия, которая называлась Selenium Remote Control. В далеком 2010 году, когда я только делал свои первые шаги в мире IT, такой инструмент, как Selenium был известен далеко не каждому.

Этот инструмент тогда был довольно простой, мог кликать по невидимым элементам, иногда ошибался в поиске локаторов и даже при получении текста некоторых хитрых элементов. Я помню, как мы автоматизировали наш первый проект на Selenium.

Видя, как мы сидим и пишем эти тесты, он так и говорил: опять тыкалки свои пишите? До сих пор помню, что наш шеф называл их “тыкалками”. Мол, нет бы руками давно проверили и зарелизили.

Сначала была вторая, а теперь и третья его версия. Но время шло, Selenium развивался, у него появлялись новые возможности. Появился стандарт (производители браузеров стали сами писать драйверы), Selenium оброс несколькими протоколами, обзавелся конкурентами на рынке и сейчас про него уже знает практически любой работающий в IT специалист независимо от его принадлежности к QA.

На данный момент существует много решений для автоматизации тестирования как веб, так и мобильных приложений.

Теперь это уже не просто тыкалки, теперь средний разговор с HR на QA-позицию выглядит так (утрированно, конечно):

По Вашему резюме не понятно, Вы умеете писать автотесты? — Добрый день.

— Нет, но я хорошо разбираюсь в…

— *трубку уже повесили*

Или не нанимать. А если это позиция лида, то ты слышишь, что им бы хотелось в первую очередь настроить автоматизацию, а уже потом нанимать QA-инженеров. Это ж экономия какая. А вдруг не надо? И разработчиков, когда все сделают… Оставить бы на сайте одну кнопку “Плати сюда” и укатить в закат… Что-то меня понесло не туда. Еще и тебя после того, как напишешь все тесты, уволить бы.

И когда это случиться? Конечно, при таких тенденциях возникает вопрос: заменит ли автоматизация ручное тестирование?

Автотесты глазами разработчиков

Чтобы ответить на этот вопрос, стоит в первую очередь подумать — а кто пишет автотесты? Я видел компании, в которых автотесты пишут сами разработчики. И видел компании, где автотесты пишут QA-инженеры. Как думаете, в чем принципиальная разница?

Мол, раз они разработчики, то и код пишут лучше. Хочется предположить, что разница в коде. Но это не совсем так. Следовательно — тесты их лучше.

И потому выделить на него много времени они не могут. Качество кода, несомненно, важный параметр, но у самих разработчиков тестирование — это не основное занятие. И это нормальная ситуация, повторюсь — это не то, на что они должны тратить существенный отрезок своего рабочего времени. Тесты пишутся на скорую руку и код довольно часто оставляет желать лучшего.

Куда важнее то, какие кейсы эти автотесты покрывают. Тем более хороший код — это не самое главное в автотестах. И вот тут уже мышление QA-специалиста существенно отличается от того, как продукт видит разработчик.

Надо покрыть автотестами регистрацию на сайте. Рассмотрим пример. Зашли, забили форму из пяти-шести полей ввода, прошли какие-то дополнительные этапы вроде подтверждения через почту или смс — тест готов, вы прекрасны! Ясно, что в первую очередь мы будем покрывать позитивный кейс.

Часть кейсов они не опишут потому, что считают их ничем существенно не отличающимися от уже покрытого. Я утверждаю, что 90% разработчиков, на которых свалились обязанности по написанию автотестов, на этом остановятся. Да и вообще “я же сам писал продакшн-код, там все надежно и на века”. Часть просто не учтут.

Классы эквивалентности, граничные значения, негативные кейсы — все это остается где-то в стороне.

Подход QA-инженера

QA-инженер использует другой подход. За его плечами опыт, понимание принципов тест дизайна, достаточное количество времени и, главное, искать баги и заниматься проверкой его прямая обязанность. Плюс, чаще всего, таким людям просто интересно что-то проверять. Что будет, если ткнуть сюда вне очереди? А если ввести данные сюда некорректно?

И его формирует не умение автоматизировать тестирование, а образ мышления. Именно подход отличает QA-инженера от разработчика. В этом случае хороший тестировщик обнаружит больше проблем при ручной проверке, чем плохой с его кучей непродуманных тестовых сценариев. Плохой тестировщик напишет плохие тесты.

Все очень просто. Какой вывод я хотел бы из этого сделать? А не инструменты, которыми он пользуется. QA-специалист — это в первую очередь понимание принципов тестирования и опыт тестирования, который имеет человек.

Без знания основных инструментов, таких как bash, Git, SQL и т.д эффективно работать в любой компании невозможно. Конечно, быть просто хорошим тестировщиком недостаточно. Их обязательно надо изучать.

Он не сделает вашу работу эффективнее просто потому, что вы взяли его в руки. Автоматизация — это такой же инструмент, он сам по себе не хороший и не плохой. К нему еще необходимы определенные навыки.

Ну а что там с ручной проверкой?

Ручная проверка никуда не денется. Так или иначе, когда мы видим перед собой новую фичу или целый продукт, мы будем изучать его руками. Нам все равно необходимо разобраться с тем, как он устроен, какие кейсы считать приоритетными и вообще, работают ли они сейчас. Какой смысл кидаться писать тест, если продукт сломан?

Сначала будет этап ручной проверки. И так будет всегда, с каждой новой фичей или внесенным изменением. И только потом — покрытие или актуализация тестов вокруг него.

Не знаю, это уже зависит от особенностей того, как построен процесс именно в вашей компании. Будет лучше, если ручную проверку и написание автотестов будет выполнять один специалист или поделить обязанности? А где-то — нет. Где-то это будет эффективно и, следовательно, выгодно.

QA-инженер должен быть знаком с автоматизацией. Так что на вопрос, стоит ли изучать автоматизацию тестирования, я категорически отвечаю да. Но заменит ли автоматизация ручную проверку и ручное тестирование? Обычно, у специалистов с этим навыком в резюме и ЗП побольше, и на рынке они ценятся выше. Конечно же, нет.

Итог

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

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

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть