Pull to refresh

«Что желаете на гарнир к тестам?»

Reading time 4 min
Views 1.7K
Original author: Майкл Болтон
Так получилось, что завершение перевода этой статьи Майкла Болтона удачно совпало с появлением на хабре заметки Натальи Руколь «Почему тестирование — это тупо и скучно?», которая вызвала достаточно бурное обсуждение. Эта статья призвана в какой-то степени объяснить, почему одним тестирование кажется скучным, а для других людей это самое интересное занятие в мире.

Когда мне было лет двадцать с небольшим, я решил быстро научиться вкусно готовить. Нашел книгу «Гурман за 60 минут» Пьера Фрейни, и пошел читать.

Выяснилось, что мистер Фрейни описывал не технику, а свою философию приготовления еды.

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

Эти истории научили меня намного большему, чем сами рецепты. Рецепты уделяли основное внимание технике, а истории учили навыкам и заставляли меня думать.

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

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

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

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

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

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

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

Итак, что же нам делать, если у нас нет навыков?

Учиться :)

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

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

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

Он слышал про тестирование методом свободного поиска (exploratory testing), но вместо нацеленного поиска он будет просто бессмысленно блуждать, и в результате сочтет бесполезной саму технику.

А вот если у тестировщика есть навыки:

1. Он начнет тестирование с выяснения цели своей работы. После этого он начнет действовать независимо, но в нужном направлении.
2. Если спецификация нечеткая или недоступна, он сделает разумные заключения о продукте. Здравый смысл еще никто не отменял.
3. Он выберет и разработает тесты, выявляющие риски, и рассортирует их по важности.
4. Он не будет ограничиваться только спецификацией, а сможет найти и другие источники, которые помогут выявить проблемы.
5. Он будет уделять внимание и другим критериям качества – удобству и простоте использования (usability), производительности, надежности, тестопригодности.
6. Вместо того чтобы думать об абстрактном «пользователе», он создаст набор различных профилей пользователей.
7. Он посмотрит на продукт как на часть более крупной системы и подумает о целях тестирования достаточно широко.

Эта широта очень важна.

Думая о покрытии только в терминах покрытия кода или покрытия спецификации, можно упустить другие важные показатели качества.

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

Тестирование, как и приготовление еды – это то, что мы делаем для удовлетворения нужд других людей.

Ну, так вы кем хотите быть: шеф-поваром тестирования, разумно использующим доступные инструменты и ингредиенты, или обычным продавцом, который переворачивает «тестбургеры» на плите в ожидании новых покупателей?

Об авторе

Майкл Болтон является одним из наиболее активных евангелистов школы контекстно-ориентированного тестирования. Он имеет более чем 20-летний опыт работы в области тестирования. Майкл регулярно выступает на конференциях, проводит тренинги и семинары, с 2005 года является постоянным колумнистом одного из самых популярных журналов в области тестирования Better Software (где и была впервые опубликована вышеприведённая статья) и ведёт замечательный блог о тестировании www.developsense.com/blog.shtml

17-18 ноября Майкл Болтон проведёт в Санкт-Петербурге двухдневный тренинг «Rapid Software Testing», разработанный им совместно с Джеймсом Бахом. Подробности тут: habrahabr.ru/blogs/testing/105133
Tags:
Hubs:
+31
Comments 27
Comments Comments 27

Articles