Home

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

Selenium! Playwright! Cypress! Postman! Вокруг этих инструментов, в основном сконцентрированных на проверках вывода, всегда много шума – и сейчас нарастает гвалт насчет малокодовых или безкодовых инструментах проверки вывода. (В прошлом году я проводил ревью некоторых из них, тут и тут. Использовали ли эти компании свои собственные инструменты для тестирования своих инструментов? Как ответ «да», так и ответ «нет» прозвучат обескураживающе).

Хотите эвристики для выбора подобных инструментов? Их можно найти здесь.

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

Вот выжимка из статьи A Context-Driven Approach to Automation in Testing, уточненная в статье A Rote Less Travelled. Так мы смотрим на тест-инструменты в Rapid Software Testing.

В тест-дизайне мы используем инструменты, чтобы:

• Получить тестовые данные (инструменты вроде таблиц (почему некоторые тестировщики так любят оскорблять Excel? Это же швейцарский армейский нож тестирования); генераторы состояний и переходов; симуляции Монте Карло; генераторы случайных чисел).
• Обфусцировать или очищать данные прода из соображений приватности (перемешиватели данных; заменители имен)
• Генерировать интересные комбинации параметров (all-pairs или генераторы комбинированных данных)
• Генерировать потоки в продукте, покрывающие конкретные условия (генераторы моделирования состояний или путей)
• Визуализировать элементы продукта (ментальные карты, диаграммы)

При взаимодействии с продуктом мы используем инструменты, чтобы:

• Настроить и сконфигурировать продукт или тест-окружения (вроде инструментов непрерывной поставки; контроля версий; виртуализации; клонирования системы)
• Передавать транзакции и привязывать их ко времени; возможно, длительное время; в большом объеме; под нагрузкой (инструменты профилирования и бенчмаркинга).
• Кодировать процедуры взаимодействия с продуктом и сравнение их результатов с расчетными (это и есть автоматизированные проверки)
• Симулировать ПО или железо, которое еще не разработано, или же недоступно нам прямо сейчас (имитаторы и заглушки)
• Исследовать внутреннее состояние системы и анализировать ее трафик в ходе тестирования (инструментарий; анализ логов; монитор файлов или процессов; инструменты дебага; «инструменты разработчика» в браузере).

При оценке мы используем инструменты, чтобы:

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

Записывая и отчитываясь, мы используем инструменты, чтобы:

• Записывать нашу деятельность и документировать процедуры (инструменты создания заметок; записи видео; встроенное логирование; инструменты работы с текстом; инструменты записи пользовательского взаимодействия)
• Готовить отчеты для клиентов (ментальные карты; текстовые редакторы; таблицы; презентации).

Управляя тест-задачами, мы используем инструменты, чтобы:

• Разметить наши стратегии (и снова ментальные карты, системы обработки структурированных текстов, текстовые редакторы)
• Идентифицировать, что было и не было покрыто тестированием (инструменты покрытия; профилировщики; анализ логов)
• Сохранить информацию о продуктах и помочь будущим сотрудникам поддержки и разработки (вики; базы знаний; файловые серверы).

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

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

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