Comments 15
Напомнило метафору из Extreme Programming про езду на машине к цели, при этом меняя траекторию движения по ходу возникновения препятствий
«Вы должны планировать так, как это делает пожарное отделение: там не могут предугадать, где будет следующий пожар, поэтому они формируют энергичную и эффективную команду, которая сможет реагировать как в обычных, так и непредвиденных ситуациях» Эндрю Гроув, «Выживают только параноики»
Согласен. Но у многих тестировщиков почему-то имеется священный трепет перед словом «тест-ПЛАН» :)
Был у нас такой «тест-ПЛАН» на одну АИС… еженедельное тестирование всей системы, которая находилась в разработке, по плану. Тесты могли меняться каждую неделю, в зависимости от разработки. Но ведь главное, чтобы тест-план выполнял свою главную задачу: соответствие функционала системы требованиям ТЗ и корректность его работы, не так ли? :)
Трепет перед тест-планом у тестировщиков бывает в двух случаях:
* если этот план пришел «сверху»;
* если этот план они писали сами.
Не вызывают трепета только тест-планы, которые должны проходить другие тестировщики.
:)
* если этот план пришел «сверху»;
* если этот план они писали сами.
Не вызывают трепета только тест-планы, которые должны проходить другие тестировщики.
:)
Отказ от планов может сэкономить время на планирование, но не позволит оценить степень выполнения работы. Компромиссным решением может быть установка контрольных точек (промежуточных целей), как в авторалли (используя вашу аллегорию).
exploratory testing должно отвечать на вопрос «а что если...»
я б назвала это интуитивным тестированием, когда основные сценарии уже пройдены… и нужен просто взгляд на систему сбоку и иногда сверху. поэтому иногда наверное и цель может быть в тумане но узнаваема)
я б назвала это интуитивным тестированием, когда основные сценарии уже пройдены… и нужен просто взгляд на систему сбоку и иногда сверху. поэтому иногда наверное и цель может быть в тумане но узнаваема)
Любое тестирование должно отвечать на вопрос «а что, если...»
Что касается «интуитивного тестирования» — не надо этим термином называть что-то другое. Вы дали Ваше объяснение того, что представляет собой «интуитивное тестирование» в Вашем понимании.
Я придерживаюсь следующего определения «тестирования методом свободного поиска» (exploratory testing), которое можно найти в трудах людей, развивающих это направление тестирования: «одновременное осознание, проектирование и выполнение тестов». Это же определение приведено в Википедии, так что можно считать его достаточно общепринятым.
Взгляд сбоку или сверху тут ни при чём, этот подход прекрасно работает и при взгляде спереди. А также когда ещё не пройдены основные сценарии. А также если цель не в тумане. Это неважно. Принципиально другое — разделены ли во времени действия по осознанию, проектированию и выполнению тестов, или же все эти три деятельности выполняются одновременно.
Что касается «интуитивного тестирования» — не надо этим термином называть что-то другое. Вы дали Ваше объяснение того, что представляет собой «интуитивное тестирование» в Вашем понимании.
Я придерживаюсь следующего определения «тестирования методом свободного поиска» (exploratory testing), которое можно найти в трудах людей, развивающих это направление тестирования: «одновременное осознание, проектирование и выполнение тестов». Это же определение приведено в Википедии, так что можно считать его достаточно общепринятым.
Взгляд сбоку или сверху тут ни при чём, этот подход прекрасно работает и при взгляде спереди. А также когда ещё не пройдены основные сценарии. А также если цель не в тумане. Это неважно. Принципиально другое — разделены ли во времени действия по осознанию, проектированию и выполнению тестов, или же все эти три деятельности выполняются одновременно.
мне кажется мы с вами говорим щас о разных направлениях exploratory testing. верней о разных ветвях.
очень интересно об этом говорит James Bach: его можно применять для исследования как отдельного дефекта, так и для нахождения наиболее важного из огромной кучи; для того чтоб быстро понять как работает система (имхо тут главное не спутать с smoke testing) и чтобы понять текущий статус продукта. а все к чему… цель туманна, потому что ее не ставят в лоб… например целью может быть: проверить UI на то, что оно отвечает стандартам, скажем, Android приложения.
я не хочу с вами спорить) просто это тот вид тестинга, который как правило не включается в тест планы, который не оценивают вначале проекта, но на него тратят время (что правомерно). он нужен тестерам, но его не понимают менеджеры. потому что для них exploratory testing = freestyle testing в прямом понимании этих слов.
очень интересно об этом говорит James Bach: его можно применять для исследования как отдельного дефекта, так и для нахождения наиболее важного из огромной кучи; для того чтоб быстро понять как работает система (имхо тут главное не спутать с smoke testing) и чтобы понять текущий статус продукта. а все к чему… цель туманна, потому что ее не ставят в лоб… например целью может быть: проверить UI на то, что оно отвечает стандартам, скажем, Android приложения.
я не хочу с вами спорить) просто это тот вид тестинга, который как правило не включается в тест планы, который не оценивают вначале проекта, но на него тратят время (что правомерно). он нужен тестерам, но его не понимают менеджеры. потому что для них exploratory testing = freestyle testing в прямом понимании этих слов.
Давайте Вы приведёте ссылки на статьи упомянутого Джеймса Баха про то, что «это тот вид тестинга, который как правило не включается в тест планы, который не оценивают вначале проекта, но на него тратят время», приведёте ссылки на описание того направления, о котором говорите Вы.
А я со своей стороны дам ссылку на статью тоже же автора «Heuristic Test Planning»: www.satisfice.com/tools/satisfice-cm.pdf
Это статья как раз про стратегическое планирование, про планирование и управление «по целям», а не «по планам».
На самом деле это интересно — почему тестировщикам цель «не ставится в лоб»? Может быть стоит ставить цели чётко, а? А тестировщикам, со своей стороны, прояснять цели? Иначе получается диалог типа «потестируйте тут что-нибудь» — «мы тут кое-что потестировали, вот нашли кое-какие дефеты» :)
А я со своей стороны дам ссылку на статью тоже же автора «Heuristic Test Planning»: www.satisfice.com/tools/satisfice-cm.pdf
Это статья как раз про стратегическое планирование, про планирование и управление «по целям», а не «по планам».
На самом деле это интересно — почему тестировщикам цель «не ставится в лоб»? Может быть стоит ставить цели чётко, а? А тестировщикам, со своей стороны, прояснять цели? Иначе получается диалог типа «потестируйте тут что-нибудь» — «мы тут кое-что потестировали, вот нашли кое-какие дефеты» :)
Мне кажется Вы говорите об регрессионном тестировании.
UFO just landed and posted this here
статью про невключаемый в тест план вид тестинга, я вам не дам… это было не от Джеймса, а от личных переживаний при планировании тестирования. от Джеймса было сказанно выше.
и одно дело как Вы ставите цели себе со стороны тестирования (четко все разжевывая и раскладывая по полочкам, добиваясь ясности от менеджеров) и как «Он» — менеджер эту цель приподносит вам же.
и одно дело как Вы ставите цели себе со стороны тестирования (четко все разжевывая и раскладывая по полочкам, добиваясь ясности от менеджеров) и как «Он» — менеджер эту цель приподносит вам же.
Ладно, оставим терминологические споры, в конце концов заметка была не про это, а про то, что цель важнее плана. Про что, что составив план и действуя в соответствии с ним, если вдруг вы понимаете, что он уводит вас от цели — менять надо план, а не цель. Про то, что план лишь средство для достижения цели. Про что, что плана вообще может не быть, но если нет цели… Тогда, как говорил Чеширский Кот, всё равно куда идти.
Что касается непонимания менеджерами чаяний тестировщиков, мне помнится, мы в Вами уже спорили по этому поводу где-то в другой теме :) И я приводил ровно тот же аргумент — если менеджер чего-то не понимает, это не потому, что он тупой, может быть просто ему про это никто никогда не говорил. Если менеджер не знает, как правильно ставить цели тестировщикам, не умеет этого делать — надо не обижаться на него за это, а взять и объяснить!
Что касается непонимания менеджерами чаяний тестировщиков, мне помнится, мы в Вами уже спорили по этому поводу где-то в другой теме :) И я приводил ровно тот же аргумент — если менеджер чего-то не понимает, это не потому, что он тупой, может быть просто ему про это никто никогда не говорил. Если менеджер не знает, как правильно ставить цели тестировщикам, не умеет этого делать — надо не обижаться на него за это, а взять и объяснить!
Sign up to leave a comment.
Тестирование методом свободного поиска: Отказ от плана не значит отказ от цели