Новая статья: Составление функционального тест-плана на основе сценари

В библиотеку добавлена статья Андрея Козлова "Составление функционального тест-плана на основе сценариев использования".

Часто приходится видеть, как подчас даже опытные тестировщики спотыкаются на известных граблях – на составлении тест-планов. В своей статье Андрей рассказывает о модели ведения тест-планов, основанной на сценариях использования. Суть её сводится к выделению сценариев использования приложения и наполнению их конкретными данными.

#2 Sapiens

ФИО: Jukeshov Samat
Город: Бишкек

#3 barancev

ФИО: Алексей Баранцев
Город: Россия, Москва

Единственный момент который хотелось бы уточнить это то, что use case должен иметь "актанты"(Actor), которые в статье просто не афишируются. В целом статья хорошая.

#4 Sapiens

ФИО: Jukeshov Samat
Город: Бишкек

#5 Sapiens

ФИО: Jukeshov Samat
Город: Бишкек

#6 Pryanik

Город: МОСКВА

А я вот не понял в чем полезность/ценность данной модели! Автор говорит: ". помогает существенно снизить риски неадекватного планирования". Отсюда вопросы: Что такое риски неадекватного планирования? Как их оценить? В чем существенно разница/выгода между составлением тест-планов на основе требований и сценариев (пока увидел только в названии, можно и требования назвать, как требование к добавлению записей и требования к фильтрации, а содержание останется прежним)?

Цитата : "Суть её сводится к выделению сценариев использования приложения и наполнению их конкретными данными." Аналогично: Выделим группы требований. Добавим в тест-план тест-кейсы разбитые по группам.

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

#7 lorien-julia

ФИО: Юлия Нечаева
Город: Москва, Россия

Кстати озвученный "тест план" в статье это скорее набор тестов (Test Suite). Тест план имеет скорее производственный характер, кто, когда, что и т.д.

Меня тоже удивило называние этого тест-планом. Тест-план - это что у нас есть, что будем тестировать, как, кто, когда и доколе :)

Но автор вначале упоминает, что "Тест-план – в нашем узком смысле, – это список юз-кейсов и тест-кейсов с расставленными приоритетами. Всего того, что касается оформления плана и подготовки тестовой среды мы касаться не будем."

Такой себе thin test-plan

#8 barancev

ФИО: Алексей Баранцев
Город: Россия, Москва

Такой себе thin test-plan

Есть такая практика употребления термина test plan. Посмотрите хотя бы на инструменты управления тестами, от тест-директора до бесплатных. Именно по этой причине я попросил автора добавить явное определение используемых терминов.

#9 barancev

ФИО: Алексей Баранцев
Город: Россия, Москва

#10 Pryanik

Город: МОСКВА

Содержание такое же, как у любого тест-кейса: входные данные, выполняемый набор действий, ожидаемый результат. И оно не меняется при любом другом подходе составление тест кейса. А группировать можно как угодно, удобнее в конкретном случае.Суть в в другом: автор рассказал, что он применяет группировку по "некоему сценарию" (названию группы). Это обычная практика. И у меня сложилось мнение, что статья "для новичков", "азы для чайников"(в хорошем смысле слова). Для себя ничего нового или уникального не подчеркнул. (это лишь мое мнение)

#11 Pryanik

Город: МОСКВА

#12 Oldman

ФИО: Александр

Наконец-то нашлось немного времени зайти на форум :)

barancevДа вот в самой статье которую приводят http://ru.wikipedia. сам не знал что так называют :) Поэтому и в кавычках :)

мда термин на французском ограниченно используемый в лингвистике. Раньше ссылались на словари Даля, БЭС и т.д. теперь на Википедию.

По поводу статьи:1. Использование английских слов написанных русскими буквами.2. Использование термина test plan не в общепринятом значении (да я знаю что некоторые его так употребляют, но зачем потворствовать этому).3. "Я предлагаю модель, которая помогает существенно снизить риски неадекватного планирования." По первой части предложения - это что какая-то новая модель? (собственно и описания какой-либо модели я не увидел). По второй части - за счет чего она снизит риски?

P.S. по поводу "азов для новичков" - ни в коем случае нельзя давать такое читать новичкам.

P.P.S. Надеюсь все написанное выше будет воспринято как конструктивная критика. Для того чтобы научиться что-нибудь делать нужно как минимум это делать затем смотреть на результаты и делать это лучше с каждым разом.

#13 Alfa

Город: Moscow

2. Использование термина test plan не в общепринятом значении

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

Чубака — это вуки с планеты Киши, но живет Чубака на планете Эндо, а теперь вдумайтесь: в этом же нет смысла. С какой стати Чубаке, вуки высотой два с половиной метра, жить среди эвоков, которые чуть выше полуметра. В этом нет абсолютно никакого смысла.

#14 LeshaL

ФИО: Алексей Лянгузов
Город: Saint-Petersburg

Для начала зафиксируем наши юз-кейсы:

1. Фильтрация 2. Добавление

Сейчас же искушённый читатель должен заметить то, чем грешат в своих тест-планах новички - отсутствие конкретных действий и конкретных данных. Уточним:

1. Выбираем в комбо-боксе вид животного, вписываем в текст-бокс его имя, нажимаем «Найти» 2. Нажимаем «Добавить», выбираем в комбо-боксе вид животного, вписываем в текст-бокс его имя, нажимаем «Сохранить»

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

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

Так же излишняя конкретика плоха и в описании тестовых случаев. Напишите "‘//>&<$test#”" - и поверьте, 90% тех кто будет это тестировать введут именно эту строку. Напишите в задании "введите несуществующее в базе имя животного" - каждый будет немного думать. Здесь это не очень показательный пример, но случалось находить баги там, где их никто не находил годами(!), потому что делали именно то что написано. Если написаны конкретные инструции, то люди склонны их выполнять. Дайте небольшую свободу в описании тестов - пускай человек выполняющий тестирование думает, ищет, изучает, а не тупо выполняет придуманные кем-то и когда-то шаги.

Не делайте, так же, и привязку к вполне конкретным специфицированным вещам. Лучше дать ссылку на спецификацию, чем дублировать ее в описании теста. Например, в имени животного запрещены символы ""!";%:?" - не надо их перечислять в тестовых случаях, т.к. они могут измениться, а у вас останется никому ненужный тест. Проще написать: "Попытайтесь добавить животное в имени которого ипользуются запрещенные символы (см. спеку)-> должно появиться соотв. сообщение об ошибке, запись не должна быть добавлена", чем: "введите 'мурка @^&$!' в поле 'имя' -> должен появиться MessageBox с сообщением об ошибке 'некорректное имя животного 'мурка @^&$!''"

📎📎📎📎📎📎📎📎📎📎