От меня
Недавно я попала в творческий рабочий кризис, тот тип кризиса, когда у тебя есть ощущение, что ты уже во всем разбираешься и все знаешь в своей сфере, и уже ничего не интересно. Но это ловушка, ужасная ловушка окостенения мышления, осознание которой подтолкнуло меня вернуться к истокам, начать все сначала, пересмотреть базу, на которую я опиралась до этого момента.
Что самое первое, что мы изучаем в тестировании? - Правильно, тест-идеи, которые являются базой для всего тестирования в дальнейшем! Возможно, кому-то покажется, что это очень простая тема - берем требования, пишем на основе требований тесты и тестируем. НО мой практически опыт (15 лет) показывает, что все не так просто, и тесты на основе требований — это в лучшем случае одна треть из того, что можно и нужно протестировать. А две третьих - то, что не отражено в требованиях, что необходимо собирать по крупицам во всем что окружает проект: окружение, код, домен и т.д. На сколько успешным будет подобный сбор чаще всего зависти от опыта тестировщика, кто этим занимается. Но даже опыт тестировщика не может быть гарантией того, что все возможные области будут покрыты. А если в проекте нет опытных тестировщиков, что же делать? Выпускать проект недотестированным?
К счастью, очень умные люди решили этот вопрос еще в 2012 году. Совместно Rikard Edgren, Henrik Emilsson и Martin Jansson собрали наиболее полный список идей для тестов, который остается актуальным по сей день.
Этот список может помочь как опытному тестировщику проверить себя, так и неопытному подать идеи, где и что еще можно проверить.
Здесь ниже я привожу перевод этого списка. Возможно, вы уже его встречали, и даже встречали его перевод, но я бы хотела, чтобы он появился у вас в закладках на Habr, и вы периодически к нему возвращались в качестве самопроверки, а все ли я покрыл(а), как это делаю я.
37 Источников тест-идей
Мы рекомендуем постоянно собирать идеи для тестов из разнообразных информационных источников. Посмотрите на нижеуказанные моменты, и подумайте о ценностях, рисках, возможностях; найдите возможность быстро покрыть значимые вещи.
Продукт
Возможности. Первые и очевидные идеи для тестов имеют дело с тем, что продукт предположительно должен делать. Хороший старт – это требования, примеры и другие спецификации, или список функций, созданный на основании имеющегося ПО. Однако старайтесь также выявить неявные требования, недокументированные ожидания пользователей. Будьте начеку, не пропустите нежелательные возможности.
Режимы падений. ПО может упасть множеством способов, поэтому задавайте вопросы "что, если" для генерирования идей тестов, выявляющих работу с внутренними/внешними, ожидаемыми/неожиданными, (не)намеренными, реалистичными/спровоцированными отказами. Бросьте вызов устойчивости системы, сломаться может любой объект или компонент.
Модели. Модель состояний помогает выявить идеи тестов состояний, переходов и путей. Карта анатомии системы показывает, что может быть протестирована, и может выявить взаимодействия. Создайте свою модель, используя структуры вроде SFDPOT из Эвристической Модели Тест-Стратегии. Визуальную модель проще показать команде, и моделирование, как правило, дает более глубокое понимание и новые идеи. Множество богатых моделей даст наилучшие идеи для тестов.
Данные. Идентифицировав намеренные и ненамеренные данные (какой-то шум есть всегда), вы получите хороший старт для ряда идей для тестов. Следуйте за простыми и сложными данными в приложении, побывайте внутри и вне границ, бросьте вызов типам и форматам данных, используйте CRUD (Создание, Чтение, Обновление, Удаление), исследуйте зависимости, и посмотрите на данные в разных местах.
Окружения. Продукт – это не остров, поэтому совместимость с окружениями (железом, ОС, приложениями, конфигурациями, языками) – одна из множества важных проблем тестирования. Не забудьте и про действия рядом с вашим продуктом. Понимая общую картину, вы получите надежные тест-идеи, которые нельзя получить, рассматривая изолированную функциональность.
Белый ящик. Применив разрушительное мышление тестировщика к взглядам разработчиков на архитектуру, дизайн и код, вы можете бросить вызов допущениям и найти дешевые в исправлении ошибки. Обращайте особое внимание на решения и пути, которые могут быть непонятными с точки зрения черного ящика. Покрытие кода – штука небесполезная, она может помочь найти еще не протестированные вещи.
История продукта. Старые проблемы с шансами возникнут в новых формах. Поищите по вашему баг-трекеру или в системе поддержки, или же создайте каталог ошибок, запоминайте критические падения и анализ их причин. Используйте старые версии вашего ПО, как источник вдохновения и оракул.
Слухи. Обычно о качестве и проблемах много говорят, и некоторые разговоры вредят продукту и организации. Используйте слухи в качестве идей для тестирования. Ваша миссия – уничтожить слухи или же доказать, что они верны.
Реальный продукт. Взаимодействуя с продуктом, вы получите множество идей о том, что подвержено ошибкам, взаимосвязано, вызывает интерес. Если вы можете опробовать продукт на себе, вы куда лучше поймете, что в продукте значимо. Если "Качество – это ценность для какого-то человека", то с шансами этот человек – "я".
Технологии. Зная внутреннюю кухню технологии, с которой раотает ваше ПО, вы можете увидеть проблемные области и вещи, которые могут пойти не так; понять возможности и аспекты безопасности, то, какие параметры надо менять, и когда. Вы можете опробовать правильные вариации и поговорить о технологиях с разработчиками.
Конкуренты. Рассматривая разные решения похожих проблем, вы можете напрямую получить идеи для тестов, а также чувство того, в каких характеристиках заинтересованы конечные пользователи. Могут существовать и домашние решения (например, таблицы Excel), и аналоговые решения тех же проблем – все это источник вдохновения. Можете ли вы получить интересные идеи для тестов из поддержки ваших конкурентов, "ЧаВо" или другого материала?
Бизнес
Цель. Общее предназначение продукта даст вам цели для ваших тест-идей. Задайте несколько дополнительных "почему", чтобы выявить истинные цели. Это даст вам широкую и благодатную площадку для старта, и вы сможете быстро найти очень важные проблемы.
Бизнес-задачи. Каковы самые значимые задачи для компании (и на уровне подразделения)? Есть ли требования, противоречащие этим задачам? Знаете ли вы общую картину, видение продукта и драйверы ценностей?
Имидж продукта. Запланированное поведение и характеристики продукта могут быть явными или неявными, находящимися внутри умов тех, кто разрабатывал или пользовался продуктом. Если вы знаете и можете продемонстрировать угрозы имиджу продукта – например, противоречие маркетинговым материалам – вы сможете писать убедительные баг-репорты.
Бизнес-знания. Если вы знаете цель продукта и контекст, в котором он работает, вы поймете, принесет ли он ценность пользователям. Если вы не можете завладеть этими знаниями, скооперируйтесь с тем, кто знает потребности, логику и окружения.
Юридические аспекты. Надо ли вам учитывать контракты, штрафы и другие законодательные обязательства? Что будет стоить компании дороже всего в юридическом плане? Есть ли у вас юрист, который может дать вам советы, чего стоит избежать?
Команда
Креативные идеи. Все продукты уникальны и требуют тестов, которых доселе не существовало. Пользуйтесь техниками латерального мышления (Шесть Шляп от Эдварда де Боно, провокативными операциями, методом от противного, рандомной стимуляцией, Google Goggles), чтобы создать креативные тесты. Метафоры и аналогии – хороший способ стартовать в новом направлении.
Внутренние коллекции. Используйте или создайте списки вещей, которые часто бывают значимы в вашем контексте. Некоторые называют это паттернами качества/тестирования, а некоторые создают специфичные для продукта списки быстрых тестов.
Вы сами. Вы пользователь. Вы можете быть заинтересованным лицом. Вы значимы. Получите преимущество от ваших сильных сторон благодаря опыту, навыкам, знаниям и осведомленности о проблемах. Используйте ваше субъективное мнение и ощущения, чтобы понять, что тут значимо. И не забудьте признать свои слабости и слепые зоны.
Проект
Бэкграунд проекта. Причины для существования проекта – источник множества решений, и стоит знать об истории предыдущих (схожих) проектов, дабы провести эффективное тестирование.
Информационные цели. Жизненно важно понимать явные и неявные цели тестирования. Если вы не можете их получить, создайте ваши собственные цели качества, которые направляют идеи для тестирования любой фичи.
Проектные риски. С рядом сложных вещей в проекте тестирование может помочь разобраться. Вам надо знать, с какой функциональностью проблемы у разработчиков – вы скорректируете свое расписание в зависимости от рисков, которые нужно снизить в первую очередь.
Тест-артефакты. Для дальнейшего тестирования можно пользоваться не только вашими собственными тест-идеями, логами и результатами – попробуйте использовать результаты тестов с других проектов, отчеты о бета-тестировании, оценку удобства использования, результаты тестирования третьими сторонами, и так далее. На какие вопросы вы хотите иметь возможность ответить в статусных отчетах?
Долг. Короткие дорожки, которыми мы ходим, часто вызывают постоянно растущий долг. Это может быть проектный долг, управленческий долг, технический долг, долг ПО, долг по тестированию, называйте это как угодно. Если команда следит за списком своих долгов, вы можете сопоставить с этим списком свои идеи для тестов.
Разговоры. Неформальная информация, которую вы получаете от других людей, может содержать более важные по сравнению со спецификациями вещи. Многие могут помочь вам с вашим тест-дизайном, кто-то лучше разбирается в значимости, а что-то могут упомянуть вскользь. Если разработчики знают, что вы можете найти интересные штуки, они дадут вам инсайдерскую информацию о сомнительных частях приложения. Набор вопросов к разработчику может быть невинным "что, с твоей точки зрения, надо протестировать" или "какую часть твоего кода тебе больше понравилось писать?"
Контекстный анализ. Что еще в текущей ситуации должно повлиять на то, что вы тестируете, и как? Знаете ли вы о силах рынка и драйверах проекта? Есть ли что-то изменившееся, что должно привести к новым путям тестирования? Что тестируют другие? Какие силы и слабости у проекта и его команды?
Множество конечных продуктов. Тестировать нужно много чего: сам продукт, инсталляционный пакет, программные интерфейсы, расширения, код и комментарии, свойства файлов, справку, другую документацию, релизные заметки, файлы Readme, маркетинговые и тренировочные материалы, демо-версии, и так далее. Все это также содержит информацию, которая может послужить источником вдохновения.
Инструменты. Если что-то можно сделать очень быстро, то попробовать – хорошая идея. Инструменты – не просто средство достижения цели, они могут также использоваться как стартовая точка анализа.
Заинтересованные лица
Характеристики качества. Характеристики качества всегда важны для успеха проекта, однако эта область может быть как легко достижимой, так и трудной и критичной. Наше определение включает возможности, надежность, удобство использования, харизму, безопасность, производительность, IT-руемость, совместимость, поддерживаемость, тестируемость, ремонтоспособность, портируемость, и множество подкатегорий. Многие из этих характеристик можно использовать как непрерывный поток тест-идей в уме, свободно выполняя их, и будучи наготове распознать нарушения.
Продуктовые страхи. То, о чем действительно волнуются заинтересованные лица, сильнее рисков и не нуждается в приоритезации – оно нуждается в тестировании. Сложно верифицируемые, но полезные для тестирования страхи: потеря имиджа, неверные решения, ущерб, людям не понравится ПО. У разных людей страхи различаются, выясните, что будет самым важным.
Сценарии использования. Пользователи хотят достичь чего-то или ощутить что-то, используя ПО, поэтому создайте тесты, которые разнообразными путями имитируют последовательности в поведении продукта, а не его изолированные характеристики. Чем больше достойных доверия паттернов использования вы знаете, тем реалистичней будет ваша работа. Попробуйте также эксцентричные тесты мыльной оперы для расширения тестового покрытия.
Полевая информация. Помимо знания о проблемах, с которыми столкнулись пользователи, их окружениях, нуждах и чувствах, уделите время пониманию ваших пользователей как в режиме ошибок, так и в режиме успеха. Поговорите с конечными пользователями, предпродажной подготовкой, продажниками, маркетологами, консультантами, специалистами поддержки, или, что еще лучше, немного поработайте там.
Пользователи. Подумайте о разных типах пользователей (люди, которых вы знаете, персоны), различных нуждах, различных ощущениях, различных ситуациях. Выясните, что им нравится, а что нет, что они используют совместно с вашим ПО. Разыграйте сцену в тест-лаборатории, в которой тестировщики будут изображать различных пользователей – к каким тест-идеям это приведет? Лучший вариант, конечно, нефильтрованная информация напрямую от пользователей из их контекста. Помните, что два разных пользователя могут по-разному думать об одной и той же области.
Внешние факторы
Стандарты. Найдите релевантные бизнес-стандарты, законы и требования. Прочтите и вникните в стандарты пользовательского интерфейса, безопасности, политик. Есть статьи, описывающие, как сломать даже что-то соответствующее стандартам – можно ли включить эти способы в идеи для тестов?
Справка. Разнообразные справочные материалы – хороший источник оракулов и тест-вдохновения. К примеру, это атлас для географического продукта. Общие разноплановые знания могут быть вам полезны, а Википедии может быть достаточно, чтобы быстро разобраться в статистическом методе.
Поиск. Использование Google и других способов
Публичные коллекции. Извлеките пользу из общих или специализированных списков багов, ошибок кода илитест-идей. Создавая свой чеклист, подходящий для вашей ситуации, попробуйте эти:
Appendix A of Testing Computer Software (Кейнер, Фолк, Нгуен)
Boris Beizer Taxonomy (Отто Винтер)
Это еще не конец (Майкл Хантер)
Почерпните хитрости и техники тестирования из книг, блогов, конференций, ищите эвристики тест-дизайна или создайте подходящие лично для вас.
