Home

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

Тестировщики часто задают мне два вопроса:

Как мне продемонстрировать ценность тестирования менеджменту?

Как получить больше времени на тестирование?

Начнем со второго вопроса. Чувствуете ли вы себя очумевшим от объема продукта, который вам надо покрыть, в сравнении с выделенным на это временем? Беспокоитесь ли вы, что вам не хватит времени на поиск значимых проблем?

Как тестировщики, мы должны пролить свет на риски бизнеса. Некоторые бизнес-риски связаны с проблемами, выявленными нами в продукте. Эти проблемы могут привести к разочарованным пользователям, плохим отзывам, издержкам на поддержку… Больше рисков возникает из-за более глубоких проблем, которые мы еще не обнаружили, потому что тестирование недостаточно покрыло продукт, чтобы выявить эти проблемы.

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

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

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

-    По ходу дела проводите быстрое тестирование, чтобы найти поверхностные баги.

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

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

Моргни. Загрузите страницу в двух разных браузерах и быстро переключайтесь между ними. Замечаете какие-либо серьезные различия?

Внезапный стресс. Перегрузите поле ошеломляющим объемом данных (воспользуйтесь PerlClip, BugMagnet или иными легковесными инструментами, или просто используйте текстовый редактор для создания огромной строки путем копирования и вставки); затем попробуйте сохранить или завершить транзакцию. Что произойдет?

Патологические данные. Введите в поле данные, которые должны вызвать фильтрацию ввода (зарезервированные HTML-символы, эмоджи…). Правильно ли поле справляется с такими данными?

Кликомания. Быстро и беспрерывно кликайте в одном месте (или разных). Нет ли странного поведения? Обработки проблем (особенно на уровне бэкэнда)?

Обзор экрана. Прекратите делать то, что вы делаете, и посмотрите на экран; нет ли там чего-то очевидно странного?

Наводнение. Заполните каждое поле до пределов. Все ли данные видны? Каковы были реальные пределы? Устраивают ли они команду, или она с удивлением про них слышит? Что будет, если вы сохраните файл или завершите транзакцию?

Пустой ввод. Оставьте “обязательные” поля пустыми. Появится ли сообщение об ошибке? Внятное ли оно?

Упс. Намеренно совершите ошибку, выполните еще несколько действий, а затем постарайтесь ошибку исправить. Позволяет ли система исправить вашу “ошибку”, или же ошибка застывает навечно?

Земля уходит из-под ног. Начните процесс, а затем прервите его или как-то ему помешайте. Захлопните крышку ноутбука, закройте сессию браузера, выключите wi-fi. Если процесс не завершился, грациозно ли восстанавливается система?

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

Снять пробу с документа. Быстро откройте спецификацию или руководство пользователя, или API-документацию. Нет ли несоответствий между артефактом и продуктом?

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

Зум-зум. Увеличьте или уменьшите окно браузера (помните, что многие не очень хорошо видят, а другим хочется увидеть как можно больше). Не исчезло ли чего?

Многие склонны отмахиваться от поверхностных багов. “Это граничный случай”. “Ни один пользователь так не сделает”. “Так продукт не используется”. “Пользователи должны читать руководство”. Иногда это даже может быть правдой. Однако беспечный пропуск поверхностных багов без их исследования может быть ошибкой.

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

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

Если менеджмент ставит вам такие задачи, вы можете почувствовать микроменеджмент, но так ли это? Подумайте вот о чем: если бы менеджеры действительно бдили за вашей работой, то с шансами они бы ужаснулись затратам вашего времени на бумагомарание, или на борьбу с тест-инструментами, или на попытки научить машину распознавать кнопки на экране только для того, чтобы несколько раз их нажать и продемонстрировать, что что-то работает. И они, возможно, занервничали бы, увидев, как легко проблемы проскакивают мимо этих подходов, и удивились бы количеству багов, найденных вами без их помощи - особенно если вы не рассказываете им, как на самом деле находите баги.

Поскольку менеджеры не следят за вами ежеминутно и ежедневно, у вас наверняка есть возможности для быстрого тестирования благодаря “лишнему времени”.

“Лишнее время” в терминологии Rapid Software Testing - это термин для времени, которое вы можете потратить на что хотите, не нажив себе проблем; время, когда менеджмент не наблюдает за тем, что вы делаете, моменты, которые можно инвестировать с большой выгодой. Вот статья о “лишнем времени”.

У вас практически наверняка есть какое-то доступное лишнее время, однако вы не решаетесь его использовать.

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

Возможно, менеджмент настаивает, чтобы вы создавали автоматизированные проверки GUI - политика, которая стала только хуже благодаря неискоренимым “codeless”-инструментам автоматизации GUI, переполненным ограничениями и багами. Я не говорю, что автоматизированные проверки - это плохо. Напротив, это вполне разумная идея для разработчиков - автоматизировать низкоуровневые проверки вывода данных, чтобы получить быструю обратную связь о нежеланных изменениях. Это может быть хорошей идеей для тестировщиков - испытывать продукт через API или скриптованные интерфейсы. Но почему тестировщики должны имитировать низкоуровневые проверки разработчиков, натравливая машину на недружелюбный к машинам GUI? Как говорит мой коллега Джеймс Бах, “Когда дело доходит до технического долга, GUI-автоматизация - это злобный ростовщик”.

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

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

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

Несколько лет назад я слушал воркшоп Джеймса Баха “Если я найду достаточно важных проблем достаточно быстро”. Он сказал, что “менеджеры и разработчики будут слишком заняты спорами, как исправить то да се до релиза; они слишком заняты, чтобы заниматься микроменеджментом меня; они оставят меня в покое”.

Вы можете добиться значительной свободы в управлении своим кораблем тестирования, если регулярно возвращаетесь с золотом для разработчиков и менеджеров. Золото тестировщиков - это знание и доказательство существования проблем, заставляющих менеджеров сказать “Божечки… но слава небесам, что тестировщик нашел это до релиза”.

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

И это возвращает нас к первому вопросу - “Как продемонстрировать менеджменту ценность тестирования?”

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

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