Home

Автор: Дэн Эшби (Dan Ashby)

Оригинал статьи: https://danashby.co.uk/2016/03/08/information-and-its-relationship-with-testing-and-checking/

Перевод: Ольга Алифанова

Непонимание того, что автоматизация не в состоянии заменить тестирование – это одна из самых больших проблем индустрии тестирования на сегодняшний день. Майкл Болтон, Джеймс Бах и другие лидеры отрасли вложили много труда в развенчание этого мифа, но я все еще вижу, как он силен в ряде компаний. Ему подвержен не только менеджмент, разработчики и другие участники проектных команд, но и сами тестировщики/автоматизаторы в этих организациях.

Многие тестировщики считают, что они обязаны научиться автоматизировать, чтобы не потерять работу. Люди, считающие себя экспертами по тестированию, тоже верят в это и пропагандируют этот подход в обсуждениях в Интернете.

Я читал статью Майкла и Джеймса, которая объясняет, в чем разница между "тестированием" и "проверками", а также то, как школа контекстно-управляемого тестирования рассматривает автоматизацию. Мне нравится статья, и я пытался познакомить с ней компании, страдающие от вышеописанной проблемы – но эти проблемы никуда не делись. Когда я интересовался, прочитали ли люди статью, они обычно отвечали, что она "слишком длинная", или что им не нравится термин "проверка" (многие автоматизаторы рассматривают этот термин как уничижительный для своей работы – они относятся к нему примерно так же, как я к "ручному тестированию").

Как же помочь людям понять, о чем я говорю, как упростить мои объяснения?

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

Несколько раз это обсудив, я пришел к выводу, что куда проще будет показать взаимоотношения информации, тестирования и проверок, используя модель.

Итак, вот она:

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

Она может казаться вторичной или очевидной, но ее суть в том, что я намеренно ставлю информацию во главу угла. Давайте разберемся в этой модели:

Информация

Информация – это валюта проектов по разработке ПО. Она может относиться к требованиям, дизайну и артефактам, функциональности и продуктам, платформам, процессам… Информация – это центр нашей IT-вселенной.

Тестирование

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

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

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

Проверки

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

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

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

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

Автоматизация помогает нам тестировать

Ричард Брэдшоу давно уже использует термин "тестирование при помощи инструментов" – это то, о чем Майкл и Джеймс говорят в своей статье. Раньше я пользовался понятием "одноразовых скриптов", но сейчас предпочитаю терминологию Ричарда. Важно помнить, что автоматизация может помочь нам с генерацией данных и манипуляциями с ПО с целью попасть из точки А в точку Б и начать тестировать в точке Б с целью получить новую информацию, но она остается вспомогательным инструментом. Автоматизация – это не тестирование.

Все это связано с "5 степенями незнания", относящимися к информации

Я все чаще говорю о 5 степенях незнания, обсуждая эту модель с другими людьми. Поясню:

• 0 степень незнания: ЗНАНИЕ. Это то, что нам известно, наша явная информация. Мы можем использовать ее для создания проверок.
• 1 степень незнания: НЕХВАТКА ЗНАНИЯ. Это то, что нам неизвестно, и мы понимаем, что оно неизвестно нам. Когда мы задаем вопросы вроде "А что, если…" или "А как насчет…", то мы знаем, что ответ нам неизвестен, и мы тестируем, чтобы найти этот ответ. Для тестирования нам нужно задать вопрос, и неважно, задаем ли мы его владельцу продукта про требования или самому продукту, взаимодействуя с ним и наблюдая за результатами.
• 2 степень незнания: ОТСУТСТВИЕ ИНФОРМИРОВАННОСТИ. Это наше "неизвестное неизвестное". Мы не в курсе, что чего-то не знаем, и поэтому не можем задавать вопросы. Мы даже не знаем, что их вообще можно задавать. Причиной тому третья степень незнания.
• 3 степень незнания: ОТСУТСТВИЕ ПРОЦЕССА. У нас нет процесса или вида деятельности, который позволял бы нам находить информацию (повышать нашу информированность) о нашем "неизвестном неизвестном". Таким процессом будет, например, тестирование.

Если вы исследуете требования, то Роб Ламберт писал отличный пост про то, как он спрашивал свою команду про все возможные способы использования кирпича. Если бы это было требование, и я бы закричал "кирпичом можно бить стекла в машинах", то это, скорее всего, заставило бы вас задуматься о том, что можно бить и другие стекла по другим причинам (к примеру, окно, чтобы попасть в дом), или о том, что кирпич можно использовать вместе с машиной другим образом (зажать педаль газа, например). Но если бы мы вообще не устроили подобное упражнение, задумались бы вы о таких способах использования? Или возьмем программный продукт – представим, что мы работаем в паре, и я предлагаю ввести двойную фамилию через дефис (например, Хардинг-Роллс) в поле "Фамилия". Возможно, это заставит вас задуматься о фамилиях с другими спецсимволами, например, апострофом (О'Брайен), или об иностранных фамилиях (張). Все это могло лежать в области "неизвестного неизвестного" (второй степени), но благодаря тестированию оно перешло в область "известного неизвестного" (первая степень), и теперь мы можем задать этот вопрос продукту, чтобы перевести неизвестное в область знания (нулевая степень).

• 4 степень незнания: МЕТА-НЕЗНАНИЕ. Она немного сомнительная – это незнание пяти степеней незнания. Эту степень мы можем в данном случае проигнорировать.

Учитывая все вышесказанное: последнее, о чем надо не забыть – это КОНТЕКСТ. Проект, продукт, пользователи, потребители, организации, сообщества, окружающая среда – все они формируют контексты, в которых мы работаем, и повлияют на тестирование.

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

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

(Огромное спасибо людям, давшим обратную связь по моей модели: Ричарду Брэдшоу, Тони Брюсу, Марку Уинтеринхэму, Аугусто Евангелисти, Лаурен Брейд).

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