Home

Автор: Рикард Эдгрен (Rikard Edgren)
Оригинал
Перевод: Ольга Алифанова

Аналитическая ^[1]часть тест-дизайна отвечает на вопрос, что нам надо протестировать. Это включает идентификацию и изучение различных информационных источников, а также искусство выяснения, что важно или может быть важным.

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

Кейнер называет это обучением, Майкл Болтон (и Джеймс Бах) в дополнение используют термин "факторинг" – "Факторинг – это процесс анализа объекта, события или модели с целью определить элементы, из которых он состоит^[2]".

У Эдварда Де Боно есть общая техника латерального мышления – фракционирование, и она явно включает креативный аспект.

"Мы не стараемся найти реальные компоненты ситуации – мы стараемся создать эти компоненты^[3]".

В тестировании эта концепция включает не только математическую факторизацию^[4], анализирующую и ищущую точные компоненты целого.

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

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

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

Эвристики анализа

Анализ широкого и релевантного тестового пространства – это трудный для освоения и оттачивания навык; он связан с пониманием целого, деталей, и значимого. Однако существует множество эвристик ^[5]и устоявшихся правил, которыми можно пользоваться для усиления взаимосвязанных процессов анализа и дизайна. Вот несколько примеров:

1. Как можно быстрее (ASAP) – маленький кусочек информации о системе может сильно повлиять на тестирование (а обратная связь может сильно повлиять на разработку).
2. Копайте глубже – Требования или риски – неплохой старт, но это всего лишь начало пути.
3. Хм? Серьезно? – вы можете что-то не понимать, ваше понимание может быть неверным, истина может быть не важна, или может значить больше, чем вы думаете^[6].
4. Эвристика "У Мэри был барашек" – возьмите каждое слово, вникните в него, оспорьте его, используйте синонимы, антонимы и комбинации^[7].
5. Оспаривайте все, особенно это заявление – в случае с важными вещами бросьте вызов утверждениям.
6. Спрашивайте людей о деталях, пояснениях и ожиданиях^[8].
7. Анализ противоречий ^[9]– ищите противоречия, дыры и то, что можно неправильно понять.
8. Эвристика "если только не…" – возьмите любое утверждение о вашем продукте, процессе или модели, и добавьте к нему "если только не…". Посмотрите, куда это вас приведет^[10].
9. Применение бизнес-знаний – изучите бизнес, а если не можете, поработайте с тем, у кого эти знания есть.
10. Суждение о важности – думаете ли вы, что это важно? Думает ли так кто-то еще? Может ли это стать важным? Будет ли пользователь ^[11]огорчен или выведен из себя проблемой?
11. Что, если? – мозговой штурм о том, что может произойти, или что можно будет испытать.
12. Латеральное мышление – искусственное фракционирование, аналогии, генерация альтернатив, противоположностей, рандомная стимуляция – все полезное подойдет^[12].
13. Триггеры тест-идей – ознакомьтесь с информацией или ситуациями, которые, по вашему мнению, могут генерировать хорошие идеи.
14. Приближение/отдаление – перейдите выше или ниже на уровень детализации, исследуйте содержимое.
15. Новые связи – скомбинируйте разнообразные знания важным образом, сопоставьте детали и общую картину, что нуждается в дополнительном изучении?
16. Конкретизация обобщений – сделайте идеи, пришедшие из общих тестов, таксономий, чеклистов (Хендриксон^[13], Хантер^[14], Кейнер^[15], Сабурин^[16], Software Quality Characteristics) контекстно-зависимыми.
17. Создайте рисунок, диаграмму или таблицу – проще поделиться с другими, может спровоцировать новые идеи.
18. Загадочное молчание – "Если что-то интересное или важное не описано и не задокументировано, оно может быть не продумано до конца, или дизайнер может скрывать проблемы^[17]".
19. Разнообразие – подумайте об этом разным образом^[18].
20. Эвристика "Длинный поводок" – "Дайте себе отвлечься… потому что вы никогда не знаете, что вы найдете… но периодически сверяйтесь со своим статусом по отношению к миссии^[19]".
21. Нырнуть и уйти – начните с самой сложной части, посмотрите, что произойдет, бросьте, когда захотите^[20].
22. Эвристика Румсфельда ^[21]– исследуйте известные неизвестные, подумайте над неизвестными неизвестными.
23. Не останавливаться – когда вы нашли то, что искали, подумайте еще – возможно, за углом ждут находки получше.
24. Всегда делайте паузы – анализ (и дизайн) – это длительная деятельность, делайте паузы всегда и никогда.
25. Сделано другими – выясните, какие типы тестирования проводятся другими людьми, их можно пропустить или затронуть лишь слегка^[22].
26. Контекстный анализ – выясните, какие факторы в нынешней ситуации могут направить ваше тестирование^[23].
27. Фрейминг ^[24]тестирования – привяжите свое тестирование к миссии тестирования, и узнайте об этой связи больше.
28. Мои домыслы – объясните свое тестирование и оспорьте его^[25].

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

Невидимый анализ

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

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

Креативность очень важна – чем больше вы знаете о продукте и думаете о нем, тем больше элементов и идей у вас появится. Составьте их список, включая всякие безумства – их всегда можно удалить. Как сказал Роберт Сабурин, "Соберите все идеи для тестов, которые можете найти! По моему опыту, лучше сознательно пропустить тест, чем пропустить его, потому что ваше время истекло, или вы просто про него забыли^[26]!"

Заметки

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

Вы можете использовать кодирование – к примеру, описать тэги – во всех ваших релевантных документах, чтобы иметь возможность вернуться к ним и перекомбинировать информацию^[27].

Типичные области, для которых подходят (и многим полезны) периодически обновляемые заметки:

• Наши источники тест-идей
• Пользовательские конфигурации
• (Пользовательские) обходные пути
• Корневые причины проблем из службы поддержки
• Найденные в ПО ХХХ баги
• Наши наиболее важные характеристики качества
• Тесты, которые нужно прогнать в первую очередь
• Типичные баги в юнит-тестах.

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

[1] Анализ можно также назвать факторингом, потому что анализ в тестировании = Факторинг + Латеральное мышление + Понимание, что важно + Множество решений.

[2] Майкл Болтон, презентация Confirmation Bias, http://www.developsense.com/presentations/2010-04-ConfirmationBias.pdf

[3] Страница 135 в книге Эдварда Де Боно Lateral Thinking - Creativity Step by Step, Harper & Row, New York 1990 Perennial edition

[4] Wikipedia: Factorization, http://en.wikipedia.org/wiki/Factorization

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

[6] Эвристика Баха/Болтона для критического мышления в курсе Rapid Software Testing, http://www.satisfice.com/rst.pdf

[7] Глава 10 в статье Mind your meaning книги Donald C. Gause/Gerald M. Weinberg, Are Your Lights On? How to Figure Out What the Problem REALLY Is, Dorset House Publishing Co. 1990 (впервые опубликовано в 1982)

[8] "Вопросы вне контекста" перечислены в книге Exploring Requirements (Gause/ Weinberg), и у Майкла Болтона есть статья Context-Free Questions for Testing на http://www.developsense.com/blog/2010/11/context-free-questions-for-testing/

[9] Слайды 73-78 в презентации Кема Кейнера Developing Skills as an Exploratory Tester, Quality Assurance Institute Worldwide Annual Software Testing Conference, Orlando, FL, November 2006, http://www.kaner.com/pdfs/ExploratorySkillsQAI2007.pdf

[10] Эвристика "Если только не" описана Майклом Болтоном, http://www.developsense.com/blog/2007/03/white-glove-heuristic-and-unless/

[11] Понимайте "пользователя" в широком смысле, если хотите найти проблемы в областях вроде поддерживаемости, тестируемости и ремонтопригодности.

[12] Эдвард Де Боно - Lateral Thinking - Creativity Step by Step, 1990 Perennial edition

[13] Элизабет Хендриксон, Test Heuristics Cheat Sheet, http://testobsessed.com/wp-content/uploads/2011/04/testheuristicscheatsheetv1.pdf

[14] Майкл Хантер, Это еще не конец

[15] Приложение А, Common Types of Errors Cem Kaner, Jack Falk, и Hung Q. Nguyen, Testing Computer Software, Second Edition, John Wiley & Sons, Inc., New York 1999. Доступно по адресу http://www.testingeducation.org/BBST/testdesign/Kaner_Common_Software_Errors.pdf

[16] Роберт Сабурин, 10 Sources of Testing Ideas, http://www.amibugshare.com/articles/Article_10_Sources_of_Testing_Ideas.pdf

[17] Воркшоп Кема Кейнера и Джеймса Баха, Risk-Based Testing: Some Basic Concepts, QAI Managers Workshop, QUEST Conference, Chicago 2008, http://www.kaner.com/pdfs/QAIRiskBasics.pdf

[18] Много хороших примеров в статье Джеймса Баха и Майкла Болтона, Exploratory Testing Dynamics v2.2, http://www.satisfice.com/blog/wp-content/uploads/2009/10/et-dynamics22.pdf

[19] Эвристика Баха/Болтона для критического мышления в курсе Rapid Software Testing, http://www.satisfice.com/rst.pdf

[20] Страницы 100-103 в книге Джеймса Баха Secrets of a Buccaneer-Scholar, Scribner, New York 2009

[21] Оригинальная цитата Румсфельда: "Есть известные известные. Есть вещи, про которые мы знаем, что мы их знаем. Мы также знаем, что есть известные неизвестные, то есть мы знаем, что есть вещи, которые мы не знаем. Но есть и неизвестные неизвестные – мы не знаем, что мы о них не знаем".

[22] Хороший пример: "Одна техника – проверка единичных переменных и их комбинаций на граничных значениях – часто хорошо применяется в юнит-тестах и низкоуровневых интеграционных тестах. Они гораздо эффективнее системных тестов. Если разработчик тестирует именно таким образом, системные тестировщики должны концентрироваться на других рисках и других техниках" – Кем Кейнер, статья в блоге Updating some core concepts in software testing, http://www.satisfice.com/kaner/?p=11

[23] Хорошее руководство – раздел Project Environment section в статье Джеймса Баха, Heuristic Test Strategy Model, http://www.satisfice.com/tools/satisfice-tsm-4p.pdf

[24] Майкл Болтон, Test Framing, http://www.developsense.com/resources/TestFraming.pdf

[25] Алан Ричардсон, статья в блоге Challenge your assumptions and presuppositions to identify useful variation, http://www.eviltester.com/index.php/2008/04/18/challenge-your-assumptions-and-presuppositions-to-identify-useful-variation/

[26] Роберт Сабурин, Just-in-time testing, EuroSTAR 2010, http://www.amibugshare.com/courses/Course_Just_In_Time_Testing.zip

[27] Если вы хотите углубиться в вопрос, попробуйте пробную версию инструмента качественного анализа Atlas.ti. Вы можете использовать любой текстовый инструмент с функциями поиска, вики или блога.

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