Новая статья: Меньше слов - больше смысла

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

“Exploratory software testing is a style of software testing that emphasizes the personal freedom and responsibility of the individual tester to continually optimize the value of her work by treating test-related learning, test design, test execution, and test result interpretation as mutually supportive activities that run in parallel throughout the project.”

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

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

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

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

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

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

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

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

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

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

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

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

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

Юля

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

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

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

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

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

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

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

меня пугает )

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

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

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

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

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

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

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

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

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

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

К тому же, навязывается вера в мифического "настоящего тестировщика", который ...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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