Форум тестировщиков: Новая статья: Меньше слов - больше смысла - Форум тестировщиков

На тренингах по тестированию методом свободного поиска каждый раз возникает обсуждение вопроса о том, нужно ли делать описания тестов, а если нужно, то насколько подробные. Я обычно начинаю с радикального совета -- не пишите :) Потому что во многих случаях действительно можно не писать, и никаких потерь от этого не случится, напротив, сплошная экономия.

Разумеется, каждый раз находятся слушатели, которые приводят аргументы в пользу того, что писать надо. Тогда я даю второй совет -- пишите, но как можно меньше. Записывайте не сценарии, а идеи, в результате опять таки экономия -- сначала тратится меньше времени на написание, а потом тратится меньше времени на переписывание.

Но экономия времени при написании -- это ещё не всё. Едва ли не более важным фактором является то, что в многословных описаниях теряется смысл, который туда пытался заложить тест-дизайнер. Поэтому опытному тестировщику работать с короткими описаниями проще, чем с подробными длинными сценариями.

И сегодня я хочу представить вашему вниманию перевод небольшой заметки Роба Лэмберта (Rob Lambert), в которой он описывает эксперимент объясняющий этот феномен.

Итак, читаем: Less Is More, или Меньше слов -- больше смысла

Ответила на хабре, не сдержусь и продублирую здесь - наболевшее, так сказать.

Меня всегда удивлял такой подход. Сначала сказать «Я приверженец Context-based тестирования», а через пару минут добавить: «Exploratory лучше всего, чем меньше кейсы тем лучше» и т.д.
Очень похоже на реализацию аджайла в российских компаниях, когда на стендап-митинги собирают как на линейку, участники стоят на вытяжку, а биг-босс шествует как на параде, раздаёт задачи и говорит «У нас аджайл!».

Так и в этой заметке.

Какие у нас тестировщики?
Какой у нас продукт?
Насколько он критичен, это игра или софт, управляющий ядерным боеголовком?
Какая методология разработки?
Какая распределённость команд?

Нужны ли нам тест-кейсы и как много в них нужно писать, зависит от этого и ещё минимум от 10-ка параметров. Не бывает best practices, которые можно переиспользовать в разных командах и проектах. Не бывает «хороших тестов».

Попробуйте, примените советы из статьи, когда вы разрабатываете софт для ВВС США, а команда по тактическим соображениям распределена по трём континентам (пример из личного опыта).

Иногда я организовывала процесс exploratory, потому что это однозначно лучший выбор. Иногда у меня был мега-структурный script-based, и по-другому точно было нельзя. Есть шкала, по которой в рамках контекстной школы мы определяем оптимальный подход. Если диапазон узкий, и мы ограничиваемся какими-то предпочтениями (типа того что «исследовательское тестирование — это хорошо»), то мы НЕ МОЖЕМ выбирать оптимальные подходы.

Надо расширять границы, диапазоны, вариативность используемых техник. Только тогда можно говорить про контекстность.

Ага, давай сюда перенесём продолжение дискуссии, на хабре я ответ написал, тоже продублирую тут:

Наташа, ты возражаешь против моего «радикального совета», про который я написал во введении, или против основного тезиса автора переведённой заметки — «избавляйтесь в описаниях тестов от избыточного текста, несущественных подробностей, очевидных вещей, словесного мусора и прочих игнорируемых элементов»?

Где в заметке упоминается слово «exploratory» (кроме моего введения) или «лучшая практика»? :)

Но раз пошёл об этом разговор, думаю, следует уточнить контекст спора, то есть пояснить, что я подразумеваю под тестированием методом свободного поиска (aka explotatory testing), чтобы дискуссия не напоминала известную поговорку про дядьку в Киеве и бузину в огороде.

Тестирование методом свободного поиска — вещь иного порядка, нежели вопрос о том, писать тесты или не писать. Взгляни на «официальное» определение, сформулированное Кемом Канером — там нет никаких упоминаний про конкретные техники. Это своего рода манифест:

Цитата

Отличие scripted от exploratory по своей сути заключается не в использовании (или неиспользовании) тех или иных техник, приёмов, инструментов, а в следовании инструкциям (как завещали наши отцы и деды).

Так вот, оптимизация тестов (ужимание, выкидывание ненужных, рефакторинг) — это характерные признаки наличия элементов exporatory. Что не мешает, конечно, иметь документы, содержащие описания тестов, причём иногда достаточно подробные. Настолько подробные, насколько это необходимо, но не более того.

Написал в комментариях к статье, о так и не смог увидеть - продублирую здесь ))

сначала история )
скинул сегодня с утра в студийную qa-рассылку -

рекомендую к прочтению статьб Баранцева "Меньше слов — больше смысла" о "кошерных" тестах.
Общий посыл  - "Вычистив всю «вату», вы получите то, что я называю «направляющими тестами», то есть нечто вроде чек-листа, который направляет 
действия тестировщика, а не руководящий документ, который управляет его действиями."

Это сильно расходится с принятой у нас  точкой зрения -" тест должен быть полным, детальным и гарантировать обнаружение ошибок"

Буду рад услышать аргументы в защиту вариантов
- он абсолютно прав, а мы тупили
- он не шарит
- и мы, и он правы

первое место занял ответ -

А я вот не вижу никакого расхождения.
Мы уже давно применяем подход "кртк сстр тлт" в части своих тестов.

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

Есть тесты схематичные (пример - общепроектный тест на чужой/поврежденный сейв). Дадим мы такой тест новому неопытному человеку? Нет. 
Есть смысл дорабатывать его до состояния "любой взял, понял и сделал"? Я не вижу такого смысла, это слишком затратно. 
Мы даем этот тест опытному тестировщику, он делает все как надо и попутно обнаруживает баги, 
обращая внимание на что-то не описанное прямо в тесте (но любой натасканный боец это просто обязан заметить).

Весь вопрос в целевой аудитории каждого конкретного теста.

А, да. Было в комментариях (слава богу, это не автор поста додумался до светлой мысли) вопиющее: "Я предпочёл бы написать просто: 
«проверить сохранение в файл там-то». Хороший думающий тестировщик проверит при этом: 
как ведёт себя программа при отмене диалога, при записи файла с тем же именем, при записи на защищённый от записи или заполненный диск,
 и т.д. и т.п." Вот ТАКОЙ подход нам не нужен. Надеюсь, не докатимся.

Юля

Теперь сижу и горжусь отделом ))

Мне статья понравилась, посыл верный. Обилие воды (комментариев, деталей, уточнений) может сильно испортить тест и затруднить работу.

Предположения, что

# он прочитает всё описание до самого конца, чтобы понять его суть и осознать, для чего предназначен этот тест
...
# он будет при этом опираться на весь свой опыт и багаж знаний, а не только на саму инструкцию 

конечно хорошие, и опытный тестировщик обязан так делать...

но идея, что признак хорошего тестировщика -

он не станет выполнять инструкцию шаг за шагом 

меня пугает )

да, обладая экспертизой в продукте и среде я могу "скипнуть" часть теста или проверить утверждение чуть отличным образом, чем предписывает тест. Но даже обладая обоими экспертизами (продукта и среды) я рискну сделать это ТОЛЬКО со своим тестом. Сколько бы времени я не потратил на

прочитает всё описание до самого конца, чтобы понять его суть и осознать, для чего предназначен этот тест 

без общения с автором теста я не рискну что-либо менять (исключение - я уверен низком качестве теста)

barancev (03 Ноябрь 2010 - 12:45) писал:

Исходя из моего опыта не обязательно так.

Вот у нас есть строго обратный пример - есть несколько комплектов тестов, проверяющих соблюдение требований платформы (playstation). Любой проект должен соответствовать, так что выполняем мы их регулярно. За несколько лет использования и апдейтов эти тесты стали оптимальны с точки зрения "ужимание, выкидывание ненужных, рефакторинг". Но врядли стали близки к exploratory ;-)

Мне кажется, происходит некая спекуляция со стороны автора.
Декларируется: "избавляйтесь в описаниях тестов от избыточного текста, несущественных подробностей, очевидных вещей, словесного мусора и прочих игнорируемых элементов".

На самом же деле, предлагается оказаться совершенно от другого - от детализации шагов тестов.

К тому же, навязывается вера в мифического "настоящего тестировщика", который:
1. знает досконально бизнес-процессы системы.
2. протестирует именно то, что от него требуется недетализированным сценарием.
3. правильно оценит неописанную в тесте реакцию системы на действия пользователя.
И т.д.

Целиком поддерживаю ответ Наталии (Natalya Rukol).

Alexander_A (10 Февраль 2011 - 12:32) писал:

Да, идеал труднодостижим. Но это не означает, что нужно кидаться в противоположную крайность и низводить тестировщиков до статуса биороботов, способных лишь исполнять детальные инструкции, созданные Высшим Разумом.

barancev (10 Февраль 2011 - 13:48) писал:

Не Высшим, но тем Разумом, который поставлен на изучение всех изменений в текущей версии. И,соответственно, ответственным за изменение сценариев.
Иначе - либо всем 20-ти тестерам (которые периодически рожают, уходят в отпуск, болеют, меняют место работы и т.д.) придётся изучать бОльшую часть из 150-ти файлов постановки (у нас примерно столько), либо все "настоящие постановщики" допустят одну и ту же ошибку, например: признают верным, сообщение "Транзакция завершена", хотя оно заменено в новой версии на сообщение "Операция завершена успешно" (см. файл 54_Common infrastructure design, стр. 114).

Поэтому, всё же, остаюсь "фанатом" Наталии. Мои извинения Робу.

Alexander_A (16 Февраль 2011 - 16:19) писал:

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

Во-вторых, один человек, которому нужно перелопатить сотни тестов (ибо надо обеспечить работой 20 биороботов), может в каком-нибудь из тестов пропустить сообщение "Транзакция завершена", хотя оно заменено в новой версии на сообщение "Операция завершена успешно", и никто этого не заметит, потому что остальные ВООБЩЕ про это не знают, до их сведения даже не было это доведено (зачем? исполняйте тесты, там всё написано).

В-третьих, потому они и меняют постоянно место работы -- им просто неинтересно заниматься неинтеллектуальной работой. Они бы может с удовольствием изучили все 150 файлов, входящих в поставку, и придумали ещё новых тестов, которые перегруженный Главный Тестировщик не может придумать, потому что глаз замылился, если им дать такую возможность. Тестировщики -- это мозги, а не руки!

barancev (16 Февраль 2011 - 17:52) писал:

Согласен, горлышко есть. Поэтому и ставят на эту должность ответственного человека. (У нас крайне редки отпуска более 10-15-ти рабочих дней.)
Если же он уволняется или умирает, то нет проблем его заменить.

barancev (16 Февраль 2011 - 17:52) писал:

Перелопачивать сотни (около 400) тестов мне лично приходилось всего раз 5-6 за 4 года - когда в процесс добавлялись новые окна\модули. И заняло это - часов 6 работы каждый раз.
Все остальные изменения тестов (в существующих описанных модулях) выполняются 1 раз в одном месте, а уж соответствующие тесты обращаются к этому месту и автоматически получают изменения.
Если это не так, то мои тесты написаны неверно.

barancev (16 Февраль 2011 - 17:52) писал:

Тестирование 5,6,7.... версий (у нас это уже 50-я) одного и того же продукта - скучно и неинтересно по определению. Особенно, если очередная версия несёт в себе преимущественно исправление ошибок старой версии.
Если же эта "скука" будет мешать человеку в работе, то он просто не подходит для работы тестировщиком и с ним лучше расстаться как можно скорее.

PS. Извините, я человек новый на Вашем форуме и не знаю - требуется ли каждый свой бред помечать "ИМХО" или это подразумевается?