Мой опыт руководства функциональным тестированием можно в большей степени отнести к аналитической (Analytic) и стандартной (Standard) школам тестирования в классификации Bret Pettichord. Эти школы тестирования проповедуют строгий контроль тестового покрытия и соблюдения всех предусмотренных процедур при выполнении тестирования.

Процесс тестирования в этом случае выглядит следующим образом:

• Анализ функциональных требований (текст -> мозг)
• Формирование вопросов и замечаний (или тестовых требований) по функциональным требованиям (текст <- мозг)
• Изучение актуализированного функционального (или тестового) требования (текст -> мозг)
• Разработка ручного тестового сценария (текст <- мозг)
• Прочтение текста тестового сценария (текст -> мозг)
• Выполнение действий изложенных в тестовом сценарии (действия <- мозг)
• Анализ результатов выполненных действий (текст и изображения -> мозг)
• Документирование результатов выполненных действий (текст <- мозг)
• Регистрация дефекта (текст <- мозг)

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

Если развернуть перечисленные выше пункты в одну цепочку преобразований, то получится следующая картина:


ФТ — функциональные требования
ТТ — тестовые требования
ТС — тестовые сценарии
результаты' — задокументированные результаты

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

В настоящий момент есть следующие идеи:

• Автоматическая регистрация дефектов на основе выполненных действий (реализовано в Microsoft Test and Lab)
• Генерация тестовых сценариев на основе формализованных функциональных требований (пример реализации: http://dmugtasimov.scienceontheweb.net)
• Генерация тестовых сценариев на основе исходных функциональных требований (например, по ключевым словам)
• Использование типовых проверок для типовых сущностей информационных систем (пример типовых проверок для экранных форм: http://dmugtasimov-pro.livejournal.com/974.html)

Существует еще другой, более радикальный вариант — это исключение всех промежуточных артефактов и сокращение процесса до следующего вида:


К сожалению, этот вариант не подходит, когда нужно осуществлять строгий контроль процесса тестирования. Конечно отдельный вопрос: а нужно ли такой контроль осуществлять? :)

© 2010 Дмитрий Мугтасимов

Перепост, оригинал здесь: dmugtasimov-pro.livejournal.com/1549.html