Джеймс Уиттакер - Как тестируют в Google

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

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

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

1. Для самых рискованных возможностей и пар «атрибут/компонент», отмеченных красным, напишите набор пользовательских историй, сценариев использования или руководство по тестированию. В Google ответственность за наиболее рискованные возможности лежит на тестировщике. Он может координировать свою работу с коллегами, использовать разные инструменты, но личная ответственность все равно на нем.

2. Внимательно изучите все то, что делалось по тестированию разработчиками и разработчиками в тестировании до вас. Как результаты повлияли на риски, выявленные с помощью GTA? Хорошо ли это тестирование было организовано с точки зрения управления рисками? Стоит ли добавить новые тесты? Тестировщику может понадобиться дописать эти тесты самому или обратиться к разработчикам. В конечном счете важно, чтобы тесты были написаны, а не кто именно их напишет.

3. Проанализируйте баги, обнаруженные у каждой пары атрибут/компонент высокого риска, и убедитесь в том, что соответствующие регрессионные тесты написаны для каждого из них. Баги имеют свойство возвращаться при изменении кода.

4. Будьте внимательнее к областям высокого риска — поинтересуйтесь механизмами восстановления и отката. Учтите возможное негативное влияние на пользователя, когда он столкнется с наихудшим сценарием. Обсудите такие ситуации с другими инженерами, проверьте реалистичность этих сценариев. К тестировщику, который часто кричит: «Волк!», вскоре перестанут прислушиваться. Громкие предупреждения о вероятных опасностях допустимы только в отношении сценариев с высоким риском, которые к тому же признаны реалистичными и уже были покрыты тестами.

5. Вовлекайте в работу как можно больше людей, заинтересованных в успешности проекта. Внутренних пользователей следует тормошить на тему обратной связи, иначе они будут просто использовать систему, игнорируя те или иные ошибки. Просите их проводить конкретные эксперименты, задавайте им вопросы типа «А как это работает на вашей машине?» или «Как бы вы использовали такую фичу?». Сотрудники Google много участвуют в тестировании, и их нужно активно направлять именно тестировать, а не просто пользоваться продуктами.

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

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

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

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

Главное в пользовательских историях — ценность продукта для пользователя. Это не тест-кейсы с их определенными вводными данными и ожидаемыми результатами. Хорошая практика — создавать отдельные учетные записи. Мы в Google часто создаем помногу тестовых учетных записей для пользователей, описанных в историях. Старые аккаунты могут быть полезны по-другому: при тестировании Google Documents мы выявили самые интересные баги как раз для старых учетных записей — при загрузке в новой версии документов, созданных в предыдущих версиях.

Мы стараемся, чтобы тестировщики, исполняя такие сценарии, менялись. Чем больше разных способов прохождения — тем лучше.

Мы не будем слишком придираться к возможностям с низкими рисками. Мы можем решить, что писать тест-кейсы для этих областей — слишком затратное занятие. Вместо этого мы можем ограничиться исследовательским тестированием или оставить на откуп краудсорс-тестированию. Чтобы управлять работой тестировщиков из внешнего сообщества, мы часто пользуемся концепцией туров — это высокоуровневые инструкции для исследовательского тестирования. [38] Подробнее о турах можно почитать у Джеймса Уиттакера в «Exploratory Software Testing: Tips, Tricks, Tours, and Techniques to Guide Test Design» (Addison Wesley, 2009). Проще говоря, такой подход дает вашему запросу нужную конкретику. Например, попросив сообщество: «Проведите FedEx-тур для такого-то набора возможностей», — мы получим намного лучший результат, чем просто отдав приложение и понадеявшись на лучшее. Мы сразу определяем фичи, которые нужно протестировать, и даем инструкции, как это делать.

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

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