Comments 7
Да, цель статьи — познакомить с Майклом и RST, если кто-то его еще не знает.
У них есть своя консалтерская контора, которая ведет тренинги по тестированию. Так что практического опыта ответов на вопрос «если у вас проект А то вы делаете Б» у него предостаточно.
Другое дело, что Болтон — это скорей не про простые шаги «делай А, делай Б», а про то, как думать головой.
(По этому поводу мне почему-то вспоминается доклад другого товарища с Гейзенбага-2016 — No Such Thing as Manual Testing — он доступен прямо сейчас на ютубе).
Вы можете достаточно просто узнать есть ли у Майкла Болтона ответы на такие вопросы. Достаточно зайти в слак комьюнити: https://testersio.slack.com и спросить. Отвечает он там весьма охотно и появляется регулярно.
Как тестировать-то? Все эти посылки и размышлизмы на хлеб не намажешь. Предположим, что я со всем идеологически согласен, как мне теперь выбирать наиболее важные куски функционала для тестирования?
Если касаться конкретно Болтона и конференции — то посмотреть описания докладов (раз, два) и предположить, отвечают ли они на твой вопрос. Еще Болтона можно встретить в дискуссионной зоне и задать вопросы — он консультант, и на вопросы должен отвечать очень хорошо.
Если вообще, то как мы знаем, существует несколько "школ" тестирования. Context-Driven школа (насколько я это понял) говорит, что результаты тестирования — это отображение мгновенного состояния проекта по самым важным для этого момента времени метрикам. Вот тут есть какая-то статья про это. Соответственно, мы приходим к понятию контекста, являющегося функцией от времени, и общего решения "как мне теперь выбирать" не существует. Нужно каждый раз думать головой и решать изобретательские задачи. Компьютер не умеет решать изобретательские задачи — умеет только человек, поэтому нам так нужны тестировщики. Некоторые интересные стратегии можно подсмотреть в докладах, что-то можно понять по какому-нибудь ТРИЗу, но это всегда будут очень "высокоуровневые" идеи, а не скрипты "делай раз, делай два".
Зачем в принципе проводить тестирование ПО? Как ни хочется сказать, что мы делаем его ради уменьшения числа ошибок в каждом очередном релизе нашей программы, правильный ответ звучит иначе: при помощи тестирования руководство проекта получает оценку рисков того, что разрабатываемое ПО поведёт себя не так, как ожидается.
А почему автор выдает правильные ответы за других людей? Может, он сам и тестирует для оценки рисков, но с чего он взял, что другие делают так же? Он опрос какой-то проводил, типа "зачем вы тестируете"? Какая выборка? Какие результаты опроса?
Поэтому, хоть Джеймс Бах своими лекциями и воодушевил меня пойти в тестирование, я не хочу становиться приверженцем его «школы», как в прочем и чьей-то другой.
А самая суть в статье уже дана:
… неуверенность в очевидном, привычка задавать вопросы про вещи, кажущиеся окружающим понятными и неизменными,… способность видеть сложность за видимой простотой, поиск альтернативных интерпретаций всего,… внутренняя вера в то, что баги могут быть во всем
Во время тестирования нужно повторять себе «я ничего не знаю». И когда ты достигаешь этого состояния, ты начинаешь видеть вещи совсем по другому. Мозг перестает цепляться за знакомое, и твое сознание свободно перемещается по приложению.
Смысл тестирования — в процессе, а не в оставшихся артефактах. Майкл Болтон и Rapid Software Testing