Home

Оригинальная публикация: http://www.developsense.com/blog/2017/11/the-end-of-manual-testing

Перевод: Анна Радионова

Тестировщики! Когда мы обсуждаем ручное тестирование, мы помогаем “тонуть кораблю”.

Это сильное заявление, но оно сформировано на основании долгих лет наблюдения за людьми, которые говорят на тему тестирования неосторожно. Опасность заключается в том, что людей, не специализирующихся на тестировании (и даже некоторых из тех, кто специализируется) вводит в заблуждение формулировка, что какой-то вид тестирования называется “ручным”, а какой-то - “автоматизированным”. Они не понимают, что разработка ПО и тестирование в рамках разработки можно сравнить с тонкой дизайнерской работой, а не фабричным выпуском продукции. Эти люди ослеплены скоростью и надежностью автоматизации, внедренной на производстве. Очень скоро они зацикливаются на идее, что тестирование может быть автоматизировано. Ручное тестирование - плохо, автоматизация - хорошо.

Впоследствии тестировщики, обладающие хорошими способностями к критическому мышлению, и навыками выявления проблем, испытывают сложности в поиске работы. Вместо них нанимают тестировщиков с весьма скромными навыками программирования и не внушающими доверия аналитическими способностями, которые месяцами пишут программы, суть которых сводится к нажатию кнопок компьютером. Целью становится отладка автоматизированных проверок, а не выявление проблем функционала, который важен для пользователя. Сложности, связанные с тем, чтобы “заставить” компьютер взаимодействовать с продуктом, отнимают время, которое могло быть потрачено на изучение продукта и наблюдение за тем, как ведет себя система. В результате имеем продукт, который мог быть тщательно или не очень протестирован, но в котором присутствуют дефекты, снижающие или даже напрочь уничтожающие его ценность.

(Не верите? Вот, например, статья под названием “How We Make Our UI Tests Stable“ (“Как мы добиваемся того, чтобы наши тесты были стабильными”) в блоге, посвященном тестированию ресурса LinkedIn.  Замечательно, что UI тесты (на самом деле, правильно называть их проверками) LinkedIn являются стабильными. А кто-нибудь из LinkedIn замечал, что интерфейс их сервиса представляет собой нечто невразумительное и непригодное к использованию, которое к тому же ужасно выглядит. Замечали ли они, что в последнее время стало практически нереально отыскать LinkedIn Groups? И что каждый раз после того, как вы примете заявку на добавление нового коннекта, появляется отвлекающее окно, блокирующее ваши дальнейшие действия, вместо того, чтобы дождаться пока вы закончите принимать или отклонять заявки? И что эти проблемы резко снижают количество желающих присоединиться к LinkedIn и следить за публикуемыми объявлениям?)

Послушайте: не существует “ручного тестирования”. Есть тестирование. Не существует “ручных тестировщиков”. Есть тестировщики. Проверка - элемент тестирования, тактика тестирования, которая может быть автоматизирована, как, например, может быть автоматизирована проверка орфографии. Хороший редактор использует программу проверки орфографии, результаты которой подвергаются тщательному мониторингу и ставятся под сомнение. Мы не называем проверку орфографии “автоматизированным редактированием”, как не применяем термины “ручной редактор” или “редактор-автоматизатор”.  Редакторы (просто редакторы) используют инструменты.

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

Существует семь типов тестировщиков. Для тестировщика-разработчика тестирование продукта является частью его разработки. И хорошие тестировщики-разработчики добавляют тестовый код непосредственно в код продукта. Технический тестировщик разрабатывает инструменты для себя и других, использует инструменты и, в целом, думает о тестировании в контексте кодинга и технологий. Административный тестировщик концентрирует свое внимание на задачах, договоренностях, коммуникации и контроле выполнения работ.  Тестировщик-аналитик разрабатывает модели, ведет учет статистики, рисует диаграммы, использует алгоритмы и применяет эти подходы для регулирования своего исследования продукта. Социальный тестировщик заручается поддержкой других членов команды (включая разработчиков) и помогает команде организоваться для покрытия продукта тестами.  Эмпатический тестировщик сам погружается в реалии выпускаемого продукта и того, как он используется пользователями. Эксперт в области (тестировщик), как правило, привлекается со стороны для оказания помощи ответственным тестировщикам.

Каждый тестировщик взаимодействует с продуктом разными средствами - возможно, явно или косвенно, возможно, верхне- или низкоуровнево, возможно, при естественных или искусственно заданных условиях. Некоторым тестировщикам (небезосновательно) очень нравится использовать инструменты. Некоторым тестировщикам, использующим и разрабатывающим инструментарий, не помешало бы несколько развить навыки критического и аналитического мышления. В свою очередь, некоторые тестировщики, которые фокусируются на анализе, пользовательском опыте и знаниях специфики сферы применения, кажется, боятся технологий. Вероятно, всем пошло бы на пользу, если бы они стали чувствовать себя более уверенно при использовании инструментов.

Тем не менее, что бы мы не рассматривали - набор навыков тестирования, способ мышления или подходы, приходим к выводу: эпитет “ручной” не подходит ни к одному понятию и мы упускаем из вида ключевой элемент тестирования: это больше работа мозга, чем рук. В то же время и сами тестировщики применяют термин “ручное тестирование” даже без намека на шутку. Сообщество профессионалов своего дела и дальше будет подыгрывать этому или сделает что-то для того, чтобы положить этому конец?

Помимо всего сказанного, употребление выражения “ручное тестирование” ведет к появлению заурядных, шаблонных статей-приманок на тему, есть ли будущее у ручного тестирования. Могу сказать, что у “ручного тестирования” нет будущего. Как и прошлого. И настоящего. Просто потому, что не существует ручного тестирования. Существует тестирование. Вместо того, чтобы акцентировать внимание на навыках необходимых для достижения высокого качества тестирования, в этих недалеких статьях читаются советы как, например, “учитесь программировать” или “учите Selenium”. (Интересно, эти статьи написаны “ручными писателями” или “писателями-автоматизаторами”?) Научиться программировать - это хорошо, в целом. Изучить Selenium - тоже, вероятно, неплохая идея, в зависимости от контекста. Спасибо за советы. Давайте дальше. Как насчет изучения принципов моделирования и анализа рисков? Может быть, нужно сделать больший акцент на системное мышление? Что насчет идей описания большего количества типов покрытия, чем кодовое покрытие? Что скажете по поводу осмысленного использования других инструментов, кроме автоматизированных проверок?

(Некоторые могут ответить: “Погодите! Я использую понятие “ручное тестирование” в своем контексте и все члены моей команды знают, что именно я имею в виду. И у меня не возникает внутреннего конфликта, когда я произношу фразу “ручное тестирование”.” Я рад, если так. Я говорю не о вашем контексте и не о вас. Однако, заметьте, что ваш ответ равнозначен ответу “На локалке работает!”)

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

Обсудить в форуме