А может, хватит уже придумывать новые термины, окончательно запутывая людей в том, где заканчивается один термин и начинается другой?
Автоматизированное тестирование – это не тестирование. Исследовательское тестирование – это не тестирование. Сценарное тестирование – это не тестирование. Это подходы в тестировании. Это способы тестирования – всего лишь, отдельные (хотя и важные) составные части.
Нам нужно убедиться в работоспособности чего либо? – Мы это тестируем. Что мы будем использовать в ходе тестирования, и какие подходы – тут уже все зависит и от нас и от конкретной ситуации.
Так как все-таки мы работаем с ноликами и единичками, наверное, понятней всего будет следующая формула тестирования (по мотивам булевой алгебры):
Тестирование = исследовательское тестирование ИЛИ автоматизированные проверки ИЛИ мануальные проверки ИЛИ работающий мозг тестировщика ИЛИ тестирование по сценариям ИЛИ … (перечень любых других подходов)
Все очень просто. Если в ходе тестирования, мы использовали хотя бы один из подходов, например “исследовательское тестирование” = true – то тестирование можно формально считать состоявшемся. Но, это не значит, что, например, исследовательское тестирование – это и есть тестирование. Нет, это лишь один из подходов в тестировании, его составная часть.
“Преподаватель логики не расстроился, когда его друг утонул. Не умел плавать, вот и утонул. Всё логично.”
Тестирование – это обобщенное понятие. А каждая составная часть – это не тестирование в целом.
И каждая такая составная часть имеет свои рамки.
Следовательно, можно уверенно утверждать, что тестирование по сценариям – это не исследовательское тестирование, а автоматизация тестирования – это не тестирование. Все верно, потому что это отдельные составные части общего понятия тестирования.
Разделить «на бумаге» и очертить границы между разными подходами можно очень просто. Для любого подхода можно придумать свою терминологию и задать рамки.
Но, давайте задумаемся, насколько четкими такие границы будут в реальной жизни, на практике.
Например, в рамках «тестирования по сценариям», мы должны отключить мозг и тупо следовать инструкциям в экселке (или где угодно еще). Сценарное тестирование – это проверки в соответствии с документом. Исследовательское тестирование – это включение мозга, изучение приложения, получение новой информации. Самый простой вариант – это когда мы читаем в тест-кейсе: «и ввести в поле Возраст значение 25». Тут мы задумываемся, а что после того как я введу 25, я проверю еще и 0 или -1. Ведь эти кейсы не покрыты.
В данном примере, мы переключаемся от «проверок» к исследовательскому тестированию. Переходим границу двух подходов. И переход этот был абсолютно природным.
А где же граница? – А граница – это всего лишь бумажная условность. Физически ее нет.
Точно также, разберем техники статического и динамического тестирования.
Допустим, вы решили проверить, что работа приложения соответствует тому, что описано в руководстве пользователя. Вы читаете документ, и соответственно выполняете статическое тестирование, потом пробуете что-то сделать в запущенном приложении, а это уже динамическое тестирование. О, ужас, где же граница между статическом и динамическом тестированием?
А граница – на бумаге. В реальной практике ее нет. А ведь анализируя документ, вы не дай бог, можете получить новые знания, и придумать новые эксперименты – а это уже попахивает включением и исследовательского тестирования…
Только не подумайте, я ничего не имею против новых терминов и их определений. Мне не нравится то, что подаются они в запутанной и неоднозначной форме.
«Ручного тестирования не существует»
«Проверки – это не тестирование»
«Автоматизация тестирования – это не тестирование»
«Что-то за рамками определения исследовательского тестирования – это не исследовательское тестирование»
Все эти высказывания – верны, но подаются они в запутанной и неоднозначной форме. А вот это – плохо.
А схематически, я бы изобразил подмножества тестирования в форме следующей картошки:
Upd: Цитата из статьи The Two Sides of Testing (By Elisabeth Hendrickson):
Tested = Checked and Explored
Следуя гибким методологиям, мы ожидаем появления продукта, с завершенными новыми функционалом по завершению итерации, или спринта, или хотя-бы раз в месяц. Но, перед тем, как сказать что функциональность «готова» – она должна быть протестирована.
Я вспоминаю разговор, в котором Франсин и я обсуждали различия в наших подходах к тестированию. Франсин настаивала на проверках, я – на исследовании. Наши подходы стоят в разных частях «уравнения Тестирования»
- Проверки: Система действительно делает то, что должна делать?
Оглядываясь назад, я вижу, что и Франсин и я были правы. И одновременно – не правы.
- Исследование: Существуют ли какие-либо другие риски или уязвимости, о которых мы еще не подумали?
Каждый из нас назвал очень важный аспект тестирования, но ни один из нас не увидел всю картину целиком. Для того, чтобы назвать пользовательскую историю «готовой» , нам необходимо ее проверить и исследовать. Обе стороны тестирования: проверки и исследование, играют решающую роль в выпуске качественного программного обеспечения.
По теме:
Комментариев нет:
Отправить комментарий