Начало: пост.
Юнит-тестирование (unit testing) — это тестирование, производимое самим программистом. Здесь нужно подчеркнуть, что неправильный подход к введению юнит-тестирования вызовет справедливое раздражение программистов, так как за тестирование платят тестировщикам, а отсутствие требований к юнит-тестированию вообще увеличит стоимость багов.
Рекомендации:
- Юнит-тесты должны планироваться в письменной форме ДО написания кода. На самом деле это, возможно, было бы полезнее делать и нам, или просто несколько корректировать сценарии использования.
- Требования к юнит-тестам должны быть формализованыв стандартах о юнит-тестировании
Кстати, перед началом тестирования нужно убедиться, что
• код заморожен (обычно релиз-инженеры посылают соответствующий е-мейл);
• версия продукта на внутреннем сайте, на котором вы будетепроизводить тестирование, является именно той версией,которую вам нужно протестировать.
Ещё в конце первой части очень много полезной информации о ветках, однако я с этим знаком и даже описывать здесь не буду.
Цикл тестирования ПО
Цикл тестирования ПО состоит из трех этапов:
1. Изучение и анализ предмета тестирования. Тестирование интерфейсов, скорости работы, документации.
2. Планирование тестирования. Тест-документация с тест-кейсами.
3. Исполнение тестирования. Суть исполнения тестирования — это практическийпоиск багов в написанном коде с использованием тест-кейсов, созданных ранее. Сначала идет тестирование новых функциональностей (new featuretesting), а позднее – регрессивное тестирование (regression testing) или тестирование старой функциональности. Мы исполняем тест-кейсы, рассчитывая найти баги.Давайте еще
Есть ещё проверка работы функциональностей называется функциональным тестированием (functional testing). Им часто занимаются аналитики.
Для полноты картины приведу все виды тестирования:
1. По знанию внутренностей системы:
• черный ящик (black box testing);
• серый ящик (grey box testing);
•белый ящик (white box testing).
2. По объекту тестирования:
• функциональное тестирование (functional testing);
• тестирование интерфейса пользователя (UI testing);
• тестирование локализации (localization testing);
• тестирование скорости и надежности (load/stress/performancetesting);
•тестирование безопасности (security testing);
• тестирование опыта пользователя (usability testing);
• тестирование совместимости (compatibility testing).
3. По субъекту тестирования:
• альфа-тестировщик (alpha tester);
• бета-тестировщик (beta tester).
4. По времени проведения тестирования:
• до передачи пользователю — альфа-тестирование (alphatesting);
– тест приемки (smoke test, sanity test или confidence test);
– тестирование новых функциональностей (new featuretesting);
– тест сдачи (acceptance or certification test);
• после передачи пользователю — бета-тестирование (betatesting).
5. По критерию “позитивности” сценариев:
• позитивное тестирование (positive testing);
• негативное тестирование (negative testing).
6. По степени изолированности тестируемых компонентов:
• компонентное тестирование (component testing), тестирование одного компонента;
• интеграционное тестирование (integration testing), тестирование взаимодействия пары компонентов системы;
• системное (или энд-ту-энд) тестирование (system or end to-end testing), полное тестирование системы.
7. По степени автоматизированности тестирования:
• ручное тестирование (manual testing);
• автоматизированное тестирование (automated testing);
• смешанное/полуавтоматизированное тестирование (semiautomated testing).
8. По степени подготовки к тестированию:
• тестирование по документации (formal/documented testing);
• эд хок-тестирование (ad hoc testing).
Покрытие возможных сценариев — это одна из частей архиважнейшейконцепции, называемой тестировочное покрытие.
Тестирование с разными браузерами называется кросс-браузер-тестированием (cross-browser testing). Тестирование с разными ОС называется кросс-платформ-тестированием (cross-platform testing).
Дальше лучше читать целиком, однако, я для себя сделал копипаст выводов автора, выкинув то, что для меня очевидно. Они есть после каждой главы и очень удобны.
В отношении методов генерирования тестов:
• при использовании метода Черновик-чистовик: Черновик —это полет мысли и вдохновения, “мозговой штурм”, не ограниченный суетными приличиями бренного света. Чистовик —это подчищенный, причесанный и классифицированный Черновик;
• матричная раскладка может быть лишь простой классификацией элементов на табл. 1, а может и бесконечно углублятьсяв дебри комбинаций и комбинаций. Главное помнить, что матричная раскладка создается для тестирования, а не тестирование было придумано для матричной раскладки;
• блок-схемы — это дочери добродетели под именем “Наглядность”.
Правильный формат заведения бага.
Правильный формат заведенного бага в системе типа JIRA или Redmine и т.п.:
Если есть номер спека, то можно давать краткое описание в таком формате:
<номер спека> : <само краткое описание>, например:
7422: неверное значение баланса Switch после покупки.
Description:Полезная информация о баге: описание, комментарии, нюансы и т.д.
Steps to reproduce:Конкретные шаги для воспроизведения проблемы.
Bug: Фактический результат.
Expected: Ожидаемый результат.
Пример:
Ещё очень полезно выписать типы объектов страницы и как они должна работать и включать их в описание.
В книге есть ещё продолжение и рекомендации по прохождению собеседования. Я же приведу фрагмент тест-кейса:
Pingback: QA terms and questions | Alexey Kiselev