Home

Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова

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

Я считаю этот спор бессмысленным по двум причинам.

1. "Ручное" и "автоматизированное" – антонимичные определения, которые в действительности ничего не значат. Если я пишу скрипт на Python, генерирующий для меня тестовые данные, я теперь инженер-автоматизатор? Если я авторизуюсь в приложении и кликаю по нему перед тем, как написать тест в Selenium, я ручной тестировщик?
2. Весь смысл тестирования, если грубо, в том, чтобы сделать максимум возможного, дабы убедиться, что наше приложение – не кусок мусора. Мы часто ограничены по времени, и поэтому должны пользоваться всеми доступными нам стратегиями, чтобы протестировать максимально тщательно за минимально возможное время.

Рассмотрим, к примеру, трех тестировщиков: Марсию, Синди и Яну. Каждого из них просят протестировать Superball Sorter (гипотетическая фича, созданная мной и описанная здесь).

Марсия очень гордится своей ролью "Инженера по разработке в тестировании" (SDET). Когда ее просят протестировать Superball Sorter, она решает, что отличной идеей будет создание инструмента, рандомно генерирующего правила сортировки для каждого ребенка. Она работает над этим несколько дней, а затем пишет Selenium-тест, задающий эти правила, прогоняет сортировщик, и убеждается, что все отсортировано как надо. Затем она настраивает запуск теста на каждую ночь и каждый новый билд.

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

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

После первичного тестирования она создает регрессионный тест-план, который религиозно прогоняет при каждом релизе. К сожалению, на это нужно около часа, и вкупе с прочими фичами, которые она тестирует вручную, ей нужно три часа на полный регресс-набор. Когда команда выпускает ПО, то этот прогон тормозит весь релиз. Более того, она не может прогонять эти тесты каждый раз при выходе билда, и поэтому новые баги зачастую ловятся только спустя несколько дней.

Яна – тестировщица, которой все равно, как ее там называют. Она внимательно слушает всех на митинге, посвященном фиче, чтобы разобраться, как будет работать Superball Sorter, еще до того, как он будет готов для тестирования. Как и Синди, она создает большой тест-план со множеством пермутаций правил сортировки. Однако она также выясняет, какой API-вызов используется для установки правил сортировки, и начинает разрабатывать коллекцию запросов, которые позволяют быстро создавать правила. При помощи этой коллекции она может в рекордные сроки прогнать все свои ручные тесты, и по ходу дела находит ряд багов.

Она также изучает API-вызов, начинающий процесс сортировки, и вызов, возвращающий данные о том, какой мячик достался какому ребенку после сортировки. При помощи этих трех вызовов и использования переменных окружения она создает коллекцию запросов, задающую правила, вызывающую сортировку, и убеждающуюся, что дети получили правильные мячики.

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

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

Кто из тестировщиков создал наиболее эффективный процесс тестирования качества ПО? Кто с большей вероятностью найдет баги в будущем? Ставлю на Яну. Яна – не просто "ручной тестировщик", но она и не "инженер по разработке в тестировании". Яна тратит время на изучение фич, создающихся командой, и на поиск инструментов, наилучшим образом подходящих для тестирования этих фич. Она не программирует просто ради того, чтобы программировать – но и не прячется от кода. Инструменты и навыки, которыми она пользуется – это средства, помогающие удостовериться, что команда создает максимально качественный.

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