Шесть вещей, которых не стоит делать, говоря о тестировании
Обсуждать тестирование ПО непросто. Это мета-деятельность – непривычный для нашего сознания процесс. Вы выполняете не обычную работу – ваше текущее задание постоянно генерирует целые комплексы новых (например, при нахождении багов, которые нужно поправить, или рисков, которые стоит исследовать). Это работа, которую невозможно завершить, но которая всё же должна быть выполнена.
Заблуждение о сути тестирования ведёт к пустым разговорам и маловажным занятиям, заставляя игнорировать по-настоящему значительные вещи. Вот некоторые ошибки, которые направляют разговор о тестировании в неверное русло:
1. Людей заботит то, сколько они написали тест-кейсов, а не то, насколько было плодотворно их тестирование. Число написанных тест-кейсов (500, 257, да хоть 39345) ничуть не поможет оценить пользу от вашего тестирования. Причина, по которой разработчики не хвастаются тем, как много файлов они создали за день заключается в том, что нелепо считать эти самые файлы, или нажатия на клавиши и тому подобное. По той же причине считать тест-кейсы не менее глупо. Тестирование одного элемента можно описать как через один тест-кейс, так и через миллион. Можно написать программу, которая сгенерирует сто тест-кейсов из одного. Что из этого получится? Сотня средних тест-кейсов? Один качественный тест-кейс? Или просто сто пунктов однообразного текста, набранного разными словами? В следующий раз, когда вам подадут вот такой набор бесполезной писанины, скажите: «этот талмуд мне не говорит абсолютно ничего». И спросите: «Что именно нас интересуют в первую очередь? Какие баги мы ищем? Какие риски наиболее важны?»
2. О тестировании говорят, как об объекте, а не о процессе. Тестирование – не физический объект, хоть оно и включает в себя такие материальные вещи, как документация, данные и код. Тестирование – это процесс, это действие, это что-то, что вы делаете. Говоря о тестировании, как о предмете, а не процессе, вы упускаете из внимания наиболее важные детали тестирования: внимание, мотивацию, погружение и навыки тестировщика. Нет двух тестировщиков, которые выполнят одно и то же тестирование одним и тем же способом. Технически, вы не можете взять тест-кейс и дать его кому-то, ожидая, что не будет каких-то мелких изменений в конечном результате (так, например, хоккеист не сможет сыграть одинаково дважды), хоть эти мелкие изменения особо ничего и не значат.
3. Люди не могут описать свою тестовую стратегию по мере её развития. Стратегия тестирования — это набор идей, которые управляют вашими решениями на тему того, какие тесты стоит разрабатывать и какие применять в любой конкретной ситуации. Стратегию тестирования также можно назвать аргументацией действий, из которых состоит каждый тест. Стратегия тестирования – это ответы на вопросы «Почему эти тесты стоит делать?», «Почему бы не попробовать другие тесты?», «Что мы могли бы изменить, если бы хотели провести более глубокую проверку?», «Что бы мы изменили, если бы хотели тестировать быстрее?», «Почему мы тестируем именно так?» Эти вопросы возникают не только после тестирования, но и в самом начале процесса. Способность разрабатывать и обсуждать стратегию тестирования является отличительной чертой профессионального тестировщика. В противном случае тестирование было бы просто вопросом привычки и интуиции.
4. Говорят, что именно автоматизация производит тестирование, а не тестировщики. Если бы разработчики говорили о написании ПО так, как многие люди говорят о тестировании, они бы сказали, что это их компилятор создал продукт, а не они, и все, что они сделали – нажали на кнопку. Они сказали бы, что продукт был создан «автоматически», а не конкретными людьми, умеющими писать код и затратившими уйму усилий. В этом случае руководство стало бы одержимым «автоматизацией разработки», купив лучшие инструменты вместо найма и обучения настоящих разработчиков.
Говорить о тестировании следует так, как мы говорим о разработке: это то, что делают люди, а не инструменты. Инструменты помогают, но не проводят тестирование сами. Лучшее, что может сделать программа – управлять продуктом согласно сценарию и проверять соответствие ожидаемого результата и фактического. Никакого полёта фантазии от нескольких строк кода ожидать не стоит — лишь работа с готовым чек-листом (хотя, стоит признать, с этим инструменты могут справиться неплохо). Но тестирование – это гораздо большее, чем простая проверка списка фактов, потому что тестировщики должны формировать собственные технические выводы, использовать изобретательность для создания чек-листов для программ, а также для их оценки, поддержки и улучшения. Такое «автоматизированное тестирование» правильнее называть «тестированием с поддержкой инструментов». Когда вы фокусируетесь на «автоматических тестах», вы забываете о навыках, суждениях, решении проблем и мотивации, которая фактически контролирует качество тестирования.
5. Говорят, что есть только один вид тестового покрытия. Существует множество способов покрытия продукта при его тестировании. Каждый метод покрытия отличается и имеет свою собственную динамику. Нет конкретного способа (например, покрытие кода), способного обеспечить всеобъемлющий результат. В качестве примера: если вы протестируете страницу, которая предоставляет результаты поиска по запросу, то вы рассмотрите функциональность, представленную только тем видом запроса, который вы только что сделали (покрытие функции), а охватите вы только конкретный набор элементов данных, который существовал в это время (охват данных). Если вы измените запрос, чтобы вызвать другой тип поиска, вы получите новый функциональный охват. Если вы измените набор данных, вы получите новое покрытие данных. Таким образом, вы можете найти новую ошибку с этим новым покрытием. Функции взаимодействуют с данными; поэтому хорошее тестирование включает не только тот или иной вид покрытия, но и оба вместе в разных комбинациях.
6. Говорят, что тестирование – статическая задача, которая легко формализуется. Тестирование заключается в постоянном обучении. Если вы скажете мне, что вы тестируете, но ничему при этом не обучаетесь, я вам отвечу, что вы не тестируете вообще. Природа настоящего обучения заключается в том, что вы не можете знать, что вам откроется дальше. То же самое происходит со многими вещами в нашей жизни: от вождения автомобиля до управления компанией. Действительно, есть вещи, которые мы можем предсказать, и образцы, которые мы могли бы использовать для организации наших действий, но это не значит, что можно просто пройти всю жизнь, сонно опустив голову и бездумно следуя сценарию. Тестировать — значит постоянно задавать себе вопросы вроде «Что именно я сейчас вижу?», «Что именно я сейчас делаю?»
Процесс профессионального тестирования – это не разработка тест-кейсов и слепое следованием им. Ни один ответственный тестер не работает таким образом. Ответственное тестирование – это постоянный процесс исследования и экспериментирования. Он может включать в себя разработку автоматизированных процедур, систематически собирающих информацию о продукте, но делая что-то подобное, вы должны осознавать ответственность за свои действия прежде всего перед самим собой. Мы часто отклоняемся от автоматизированных процедур, потому что ПО часто бывает очень сложным и способным удивить совершенно неожиданным образом; и потому что потребности заказчика постоянно меняются; а ещё потому что мы постоянно узнаём лучшие способы тестирования по мере работы.
Люди постоянно упорствуют в убеждении, что быть хорошим тестировщиком – это написать побольше тест-кейсов (независимо от того, нужны ли они), автоматизировать их (независимо от того, на что автоматизация не способна), передавать их от одного специалиста другому и предаваться прочему фетишу на число файлов и сценариев вместо того, чтобы следить за тем, как выполняются поставленные задачи.
Текст: Джеймс Бах, тестировщик ПО, автор книг по тестированию, консультант и тренер.
