Як кажуть “Був час та натхнення” (особливо натхнення) і я дешифрувала цю дуже цікаву і повну корисних порад доповідь Олексія Лупана. Сподіваюсь, що текст стане в нагоді тим, хто хоче поглибити, або структурувати свої знання в області написання тест-кейсів.
Олексію окрема подяка за допомогу в підготовці цього посту!
«Мелочь пузатая или Объем тест кейса против его содержательности»
Алексей Лупан
Доклад с Fun ConfeT&QA 30 октября 2013
Видео-запись доклада можно посмотреть ТУТ
Как правильно писать тест-кейсы?
Тестировщики с рождения учатся писать тест-кейсы, потом утверждают, что умеют это делать профессионально, а потом начинают постоянно доучиваться.
Вообще проблема правильного писания тест-кейсов не в тестировщиках, а в самой человеческой природе. Я хотел бы об этом поговорить так, словно мы все действительно профессионалы, но все таки нужно немного доучиться.
Что такое тест-кейс?
На этот хороший вопрос зачастую отвечают так:
Самым страшным является объяснение не сути того, что такое тест-кейс, а рассказ какого-то антуража, который связан с тест-кейсами. Вроде «Автомобиль — это когда я еду на работу и мне удобно и тепло»… Это приводит к тому, что когда нам, ещё маленьким тестировщикам, ставят задачу «напиши тест-кейсы», мы начинаем её выполнять, не вникая в детали, а утопая в них.
Из-за этой психологической проблемы происходит то, с чем мы сталкиваемся, когда взрослеем и начинаем управлять тестированием. Ведь с точки зрения человека, который должен на основе большого количества тест-кейсов построить логично работающую систему, которая в будущем не будет давать сбоев, всё смотрится совсем по-другому. Сразу видны проблемы.
Проблемы
Абсолютно все новички, которых принуждают к написанию тест-кейсов, по итогам долгих размышлений, творят одну и ту же прогнозируемую ерундовину – под тест-кейсом ими подразумевается запись цепочки действий, которые надо совершить в отношении тестируемой программы.
В чём заключается, с точки зрения новичка, проверка программы? Всего лишь надо убедиться в том, что программа делает именно то, что необходимо ей делать. А для этого нужно последовательно выполнить какие-то действия.
Это достаточно логичное, особенно поначалу, суждение.
Тут же подразумевается, что именно та самая логическая цепочка действий, о которой уже было сказано (тест-кейс — выполнение определенных шагов), являет из себя тест-кейс, который надо выполнить.
Это приводит не к появлению нормальных документов, на которых можно основывать свое тестирование, особенно в будущем. Это приводит к появлению различных «монстриков».
Вот как выглядит, примерно, каноничный тест-кейс:
У такого тест-кейса есть:
• заголовок;
• некоторые инструкции, которые необходимо выполнить;
• результат.
Шаблон очень общий и вольнотрактуемый.
Например, вот маленький тест-кейс, в котором есть, буквально, два шага:
У него есть обязательные поля:
• ID;
• заголовок;
• указание области, к которой он относится;
• указания его приоритета;
• смысл;
• цели и задачи.
Теперь от каноничного перейдём к тому, как обычно бывает…
Начинающий тестировщик впихивает в один документ множество проверок, и это тоже выглядит логично, но только потому, что изначальная постановка достаточно кривая — под тест-кейсом подразумевается именно цепочка действий, которые необходимо выполнить. Действие одно, второе, третье.. постоянные проверки. Вот пример того, что бывает после такой логики:
В вот тест-кейс, который всего лишь разруливает карусельку товаров в интернет-магазинах (это такая цепочка картинок, которые пролистываются влево-вправо). Старательный молодой тестировщик здесь расписал очень точно и детально, что должно появляться после КАЖДОГО клика, который делается по карусельке.
Надо понимать, что хорошо написанный тест-кейс не представляет собой описание того, что надо пошагово сделать с тестируемой программой. Задача более широка и более объемна.
На самом деле тестировщику нужно было подготовиться к тестированию будущей программы, которая к нему придет, и для этого нужно было написать документ, который поможет в будущем.
Картинка, кстати, известная общепитовская, 1954-го года, очень хорошо иллюстрирует эту ситуацию.
Для того что бы сделать удобоваримый документ, нужно по-другому мыслить и соответственно нужно заслужить похвалу.
Прошу обратить внимание на чувака в середине – судя по его улыбке, он понимает, что повар незаслуженно заслужил похвалу, хотя вроде бы делал все правильно.
Почему такие проблемы присутствуют поначалу?
Поначалу молодому тестировщику сложно понять, как нужно правильно делать документ, который называется «тест-кейс». Отсутствует «мышечная память» — собственные маленькие открытия, которые делаются в процессе придумывания того, как написать хороший тест-кейс.
Когда-то я считал, что с самого начала нужно все объяснять, как правильно делать. Потом пришел к выводу, что не очень то и надо.
Лучше с самого начала дать возможность написать всё, что угодно, и как угодно, чтобы предсказуемо получить ерундовый документ, а потом уже объяснить, как нужно сделать «по-хорошему».
Это приходит с опытом. С опытом приходит, скажем так, усталость и чуть более грамотные вопросы.
Например:
• надо ли считать, что один кейс = одна проверка?
• надо ли каждый раз перечислять все шаги в кейсе или достаточно объявить preconditions;
• можно ли вставлять в тест-кейс картинки? (самый часто встречаемый вопрос у новичков вопрос).
Вот вопросы, которые вообще никто не задает по началу:
• Что означает термин «тест-кейс»?
• Что означает слово «кейс»?
• Зачем нужно писать тест-кейсы?
• Как нужно писать тест-кейсы?
Давайте попробуем ответить на эти самые главные вопросы. Может быть, после этого настанет просветление.
Что означает термин «тест-кейс»?
Вам привет из солнечного Индостана, от тестировщика Прадиипа Саундарараяна!
Он давным-давно написал еще небольшой документик, под названием «Правда о тест-планах, которую вы и так знаете, но не хотите признать искренне». Там был такой пунктик, о том, что 90% тестировщиков (а в Индии много тестировщиков) вообще побарабанисто относятся к тому, что означает слово «кейс» в термине «тест-кейс».
Это приводит к искажениям понимания того, что это за документ, зачем он нужен и как его сделать хорошо. Тест-кейсы просто делают (ссылка на источник – это запись в блоге Прадиипа, где это все дело упоминается).
В английском языке, слово «кейс» вообще означает множество вещей и зависит оно от контекста. Слово «кейс» переводится множеством людей как «случай», «ящик» или даже, как «судебное разбирательство».
В тестировании, слово «кейс» следует переводить, как «ситуация»
Просто потому, что тест-кейс — это ситуация, которую нужно создать для проверки какого-то ожидания или утверждения.
Все шаги, которые надо сделать для выполнения тест-кейса, на самом деле, перечисляются для того, что бы можно было, всего лишь, просто создать одну тестовою ситуацию.
Поэтому верны утверждения о том, что:
• один кейс — одна проверка;
• можно перечислять пошагово все действия, которые необходимо сделать, что бы привести программу в заранее продуманное предопределенное состояние;
• это все можно выносить, в так называемые, preconditions – и это будет тоже нормально;
• это происходит искусственным образом.
Вот определение термина «тестирование», сформулированное Алексеем Баранцевым, еще в начале той эпохи, когда он начал делать вебинары про тестирование:
Тестирование — это проверка соответствия программы требованиям, которая осуществляется путем наблюдения за ее работой в специальных, искусственно созданных ситуациях, выбранных определенным образом.
Если считать, что слово «кейс» переводится, как слово «случай», то чисто семантически, ни о каких искусственно создаваемых ситуациях говорить не придется. Все потому что тестовый «случай» — это когда нужно будет сидеть и ждать пока возникнет та ситуация, которую нужно будет воспроизвести для проведения теста.
Часто конструкция тест-кейсов* выглядит так:
1. Зайти на сайт;
2. Найти пару подходящих товаров;
3. Положить их в корзину.
*Мы подразумеваем, как пример, интернет-магазин.
Всё в принципе правильно:
• каждая строчка являет из себя некий приказ. Поэтому все начинается с глаголов – «зайти», «найти», «положить»;
• каждая строчка под собой подразумевает некое действие.
Поэтому вроде бы все правильно, все пошагово — сделай действие и получи определенный результат.
Проблема в том, что описывается только действие, а не суть того, что должно произойти после того, как создана определенная ситуация и начинается проверка того, что нужно было проверить.
Хороший кейс мог бы выглядеть вот так:
1. В бэкофисе создать два новых товара;
2. Через сторфронт (веб-морду 
) положить эти два товара в корзину.
В первом варианте тест-кейса очень много неопределенностей. «Зайти на сайт», мы еще зайдем, а вот «найти пару подходящих товаров» — такое не следует писать. Товары следует создать и очень быстро, для того что бы задействовать конкретно в данном тест-кейсе, а потом положить их в корзину. Или нужно указать товары, которые уже существуют.
Здесь не указано, где именно зайти в бэкофис, не указан алгоритм создания товаров, не сообщается о том, как будут эти товары называться, и соответственно, какие именно товары будут отображаться в корзине. Но тем не менее это задел для нормального тест-кейса в будущем. Кратко, абстрактно, но понятно.
И в данном случае, содержательность начинает превалировать над объемом. Кейс написан более чем просто. Использовано меньше слов, но содержательности в нем уже больше.
Тестировщики не должны писать тест-кейсы, а должны тестировать. Тестировать нужно в любом случае, что с кейсами, что без кейсов.
Ссылка на авторские размышления на тему по этому поводу — bit.ly/16JP0rQ.
Как нужно писать тест-кейсы?
Для начала сначала ответим на вопрос, зачем их нужно писать.
Однозначно тестировщики не должны их писать, а должны их использовать.
Грамотно записанные тест-кейсы, вообще существуют не для того что бы они были написаны. Не в этом заключается суть работы тестировщика.
• В первую очередь, тест-кейсы, как любая проектная документация, помогут для оценки будущего тестирования. Необходимо будет более грамотно и внятно сказать, сколько времени понадобится на тестирование и что именно будет протестировано.
• Отсюда логичный вывод, что тест-кесы могут помочь при подготовке и проведении регрессионного тестирования, которое будет в будущем.
Как нужно грамотно писать тест-кейсы?
Тест-кейсы нужно писать в несколько приемов:
1. Сперва, надо читать документацию, в каком бы виде она не была. Даже если мы знаем что она была где-то у нас в вики-системе, когда-то давно написана, но уже давно не соответствует ситуации. Тем не менее, лучше, когда источник есть, нежели его не будет вообще.
2. Тесты надо придумывать до начала приступа тестирования, не глядя заранее в приложение, не записывая то, что уже видно на экране. Тест надо придумывать в тот момент, когда приложения еще нет. Это логический артефакт.
Есть много ситуаций, когда тестировщика привлекают в проект, на этапе, когда приложение уже существует и переполнено багами, и менеджеры и программисты начинают терять контроль над ситуацией. Баги всплывают повсюду, потому что нет системности в проверках. Поэтому появляется соображение о том, что давайте наймем наконец какого-нибудь тестировщика, который «сядет и будет искать все баги».
Но для того, что бы найти все баги (а это в принципе возможно) нужно сначала знать, что существует в программе, а чего там нет. Вот поэтому документирование будет необходимо всегда. Даже если у нас agile, даже если у нас считается, что все делается на ходу — нет, сначала продумать, потом приступить.
3. Дальше, весь упор нужно делать на идеи. Все что можно в таком реиме продумать это не более чем идеи.
• Будущие тест-кейсы нужно в принципе записать, не задумываясь о том в какие они пойдут направления, не заполняя все эти служебные поля, которые необходимо;
• Нужно сначала работать с идеями. Записанные в блокнот (Notepad в Windows) идеи о том, что можно протестировать, превращаются в отличное поле для рассуждений;
• Некоторые идеи потом можно будет собрать в логические блоки;
• Некоторые идеи отомрут;
• Некоторые, послужат основой для других идей (дополнительные соображения будут появляться всенепременно);
• Те идеи, которые останутся после такой логической работы, будут сами собой, вот уже из ничего, будут представлять нормальный чек-лист, на основе которого уже можно проводить тестирование;
• Идеи, выполнение которых будет очевидно, можно будет оставить в покое. Те, которые потребуют уточнений о том как сделать то, что предложено, можно будет превратить в тестовые сценарии.
И вот вам откровение, истинно говорю, гадом буду — совсем необязательно превращать все тестовые идеи в тестовые сценарии а потом в тест-кейсы.
Тестовые сценарии очень легко превращаются в тест-кейсы, но вообще вся работа будет основана на чек-листе, который состоит из тестовых идей.
Давайте покажу, как это выглядит в принципе.
Есть функционал в интернет магазинах QuickView (на каталоге товаров наводим курсор на какой-нибудь из товаров — появляется возможность открыть окно быстрого просмотра, т.е. мы не переходим на страницу товара, но получаем информацию о нем достаточно объемно).
Вот список идей, что можно протестировать вообще (это примерно то, как происходит работа над идеями):
1. В каталоге навести курсор на иконку любого товара и появится окно QuickView;
2. Сделать поиск по каталогу, и на странице с результатами поиска навести курсор на иконку любого товара — должно появиться окно QuickView;
3. Добавить товар в корзину. В корзине навести курсор на иконку товара — окно QuickView не должно появиться;
4. Проверить содержимое окна QuickView — название товара, цена, цвет, размер, кнопки Add to Favorite и Add to Wishlist, выбор количества товаров, кнопка Add to Cart;
5. Проверить закрытие окна QuickView — по клику на страницу вне зоны окна QuickView;
6. Проверить закрытие окна QuickView — по клику на кнопку Close;
7. Проверить закрытие окна QuickView — по клику на кнопку Add to Cart;
8. Проверить закрытие окна QuickView — по нажатию на клавишу Escapе на клавиатуре.
Некоторые идеи отмирают, некоторые генерируют новые соображения, некоторые становятся основой для тест-кейсов, некоторые тест-кейсами никогда не станут — это нормально, это всего лишь идеи.
И вот у нас, кстати, чек-лист по которому это окно QuickView уже можно взять и проверять. И расписывать тест-кейсы не пришлось, и долго размусоливать тоже не пришлось. Я набросал эти идеи просто потому, что я много раз видел как работает подобный функционал. Если какие-то нюансы взаимодействия с этим окном на определенном проекте всплывут, их всегда можно приписать. Но основа вот она уже написана. Не открывая ни какой браузер, ни ковыряясь по приложению, вот из ничего уже проверки понеслись.
Тестовые сценарии — это некий перечень шагов, которые необходимо сделать для того что бы эту тестовую ситуацию создать. Единственное отличие от тест-кейсов, наверное, в том, что в конце может не быть ожидаемого результата. Потому что сценарий подразумевает результат уже в самом его заголовке.
Проверить закрытие окна QuickView — по клику на кнопку Close:
1. Открыть каталог с товарами;
2. Навести курсор на кнопку любого товара — должна появится кнопка QuickView;
3. Кликнуть по кнопке вызова квик вью — должно появится окно QuickView;
4. Кликнуть по кнопке Close — окно должно закрыться.
Должно быть указанно действие и должно быть указанно сразу ожидание.
Можно это дело упростить. Давайте тот же самый текст напишем проще.
Проверить закрытие окна QuickView — по клику на кнопку Close:
1. В каталоге товаров навести курсор на иконку любого товара;
2. Дождаться появления кнопки вызова окна QuickView;
3. Кликнуть по кнопке закрытия окна QuickView.
Но на самом деле можно еще проще тот же текст написать:
1. В каталоге с товарами вызвать окно QuickView для любого из существующих товаров;
2. Кликнуть по кнопке закрытия окна QuickView.
Тот же самый сценарий но расписанный уже в два шага – его проще читать, понимать и осознавать.
Шаг, который называют «ожидаемый результат» — его здесь нет, потому что это сценарий. И к тому же, заголовок говорит о том, что должно произойти.
Сначала тестировщик прочитает этот текст, а потом начнет тестировать, нежели руководствуясь буквально каждой строчкой, пошагово делать, что то на приложении не совсем может быть понимая, какие произойдут ожидаемые действия и что должно конкретно произойти на экране.
Сначала текст прочитал, осознал, потом его выполил.
Из тестовых сценариев можно делать тест-кейсы.
1. Взять любой тестовый сценарий ;
2. Снабдить его уточнениями и деталями о том, что должно происходить ;
3. Профит.
Основные соображения, по всему вышесказанному:
• писать тест-кейсы, это не задача тестировщика и не суть его работы.
• тест-кейсами надо пользоваться
Если тест-кейсы существуют — хорошо, мы их используем.
Если они не существуют, но их кто-то может написать — пускай напишет. Будем юзать.
Если нужно самостоятельно писать, то мы предпочтём вариант работы с идеями, нежели сразу кидаться писать тест-кейсы.
Пусть даже мы знаем, что сила чек-листов в том, что они гибкие, поддаются быстро изменениям, очень удобные, быстрые в работе. Но слабость их в том, что если отсутствует контекст, другой тестировщик поэтому чек-листу работать не сможет. Но это еще не повод кидаться в написание больших, тяжеловесных тест-кейсов.
Тест-кейсы всегда пишутся итеративно, точно так же, как пишется софт в декларируемых подходах Agile.
Если мы сначала по быстрому напишем идеи и некоторые из них отомрут, а некоторые утвердятся, то это будет намного результативнее, чем если мы сразу начнем писать тест-кейсы.
Писать тест-кейсы не только утомительно, их еще и читать утомительно и рецензировать утомительно.
А если писать идеи, если начать со списка маленьких таких строчек, которые понимаются всеми теми, кто задействован в подготовке тестов, то времени на это уйдет намного меньше, а результативности будет намного больше.
Сначала только кажется, что долго писать тест-кейс по этапам — сначала написать идеи, потом тестовый сценарий, потом собственно тест-кейс.
На самом деле это не долго. На практике такой подход всегда генерирует выигрыш во времени. За один час написания идей, можно нагенерировать в два раза больше соображений о том, что протестировать, чем если сразу начать писать тест-кейсы.
Конечно, логично писать тест-кейсы, потому что по итогам оно и понадобится когда-нибудь, когда будет регрессионное тестирование. Но дело в том, что люди нелогичны и эмоциональны. Удобство и удовольствие нам необходимы больше, чем строгое логичное документирование, какого либо большого процесса.
Тест-кейсы, на самом деле, не приносят контроль над ситуацией (то, что ожидают тест-менеджеры). Тест-кейсы приносят ощущение контроля.
Именно из-за того, что мы нелогичные, эмоциональные существа.
Тестировщик, который умеет записывать все соображения в блокнот, будет намного эффективней, нежели тот, кто будет писать кейсы (с указанием их источника, происхождения, уточнения места, где оно документируется и тд).
Уметь записывать быстро это важно!
Одна идея — одна проверка — один кейс.
Это хороший тест для уточнения хорош ли тест который был написан. Когда соображение происходит о том что можно протестировать, почти всегда возникают соображения о том, что еще можно протестировать или как еще ситуация может развиться, в какую еще сторону она может пойти, начинаются ветвления. Любое ветвление это не повод записи всего в один тест-кейс. Это повод для написания новых идей. Это внятно, четко и грамотно, весомо, грубо и зримо.
Последнее соображение постоянно цитируется за авторством Брюса Ли. Я, к сожалению, не нашел источник этой цитаты, тем не менее мне она очень нравится:
Ответы на вопросы.
— Что делать, если документации нет вообще?
— Если документации нет, это еще не означает, что нет каких-то требований и ожиданий. Это еще Александр Александров тыщу раз говорил. Не пишется софт вообще без требований. Они могут быть не задокументированны, как это мы привыкли видеть в нормальном ворд документе, с заголовками колонтитулами и прочими вещами. Они могут быть неформальными и они скорее всего существуют.
Существуют в мозгах, чатах и переписках, существуют буквально на салфетках. Если тестировщику приходит задание что-то протестировать, а источника требований нет, это значит, что его нужно находить.
Тот кто:
• не умеет находить требования;
• не умеет общаться с программистами;
• не умеет общаться с менеджерами
• или тот, кто поставлен в ситуацию, когда невозможно общаться…
…ну тогда примите это как мужики, и — идите топитесь!
— Действительно ли можно все баги найти?
— Да, это логически следует из любого утверждения о том, что все баги невозможно найти, потому, что мы не знаем, где они могут возникнуть.
Если все учесть заранее нормально и грамотно, если заниматься грамотно тест-дизайном, а не ерундой, тогда можно учесть практически все ситуации, которые могут возникнуть в софте.
Изначально нас учат тому, что в каждой программе есть очень много путей входа и выхода и всех их перечесть можно, но учесть невозможно. И примером приводится всегда довольно дурацкая система с тестированием калькулятора. Но дело в том, что это именно в калькуляторе невозможно и невообразимо продумать все варианты, или же перечислить и сделать все те варианты, которые можно сделать с простой операцией умножения.
В принципе, это можно сделать, если напустить на калькулятор какого-нибудь робота — это раз.
Второе — если считать заранее, что невозможно учесть все варианты использования итд итп в каком-нибудь обычном веб-магазине, то это значит, что некоторые серьезные вещи могут пройти мимо сознания тестировщика, мимо сознания разработчика, мимо сознания всех тех, кто что-то делает. Но обязательно могут появиться там, где появятся пользователи. Или же появится тестирование со стороны заказчика. Заказчик не будет заморачиваться по поводу требований, заказчик просто начнет класть товар в корзину и как-то его там оформлять. Баги могут посыпаться откуда угодно.
Поэтому если тестировщик изначально знает, что нельзя все предусмотреть — топиться! Топиться, пока не придет соображение о том, что можно все предусмотреть, если спокойно и детально и внимательно ко всему этому делу подготовиться.
Однако, если готовиться ко всему этому делу с точки зрения написания тест-кейсов — это опять же будет повод для утопления.
Подготовка должна происходить достаточно быстро, бесконтактным боем, если уж говорим о том, что делал Брюс Ли. Подготовка начинается именно с расписания идей, с общих каких-то направлений, с которых можно прийти позже копать. Те, кто не будут копать до конца, те, кто не докопаются, те кто пропустят мимо сознания какие-то проверки — ну значит плохой тестировщик. Хороший тестировщик докопается до конца!
— Как ты относишься к пасхальным яйцам? Если учесть, что все баги можно найти, то, что делать с пасхальными яйцами?
— Когда я работал в компании GlobalLogic, у нас там был очень грамотный программист, ахиграммотный. Он как-то на кухне сказал, что – «я вас не понимаю, я очевидно в каком-то простом месте делаю маленькую ошибку, которую вы очевидно должны найти. Тестировщики ее не находят, а находят вообще такое, что мои пасхальные яйца просто кукожатся от страха.» Поэтому все нормально, подумаешь, пасхальные яйца…
— Как соотносятся тест-кейсы и чек-листы? Одно заменяет другое? Как их вообще использовать — вместе, по отдельности?
– Одно другое не заменяет. Одно другому может быть преемственностью. Потому, что ориентироваться строго на чек-листы удобно и прикольно только поначалу. Всегда будет проблема, когда придет, во-первых, новый человек, будет читать чек-лист и не сможет понять, что именно там должно происходить. Множество вещей, которые подразумеваются в документах, обычно не записываются (ни в контрактах, ни в требованиях, ни в тест-кейсах). Поэтому тест-кейсы будут необходимы.
Но не для всех абсолютно проверок необходимы тест-кейсы. Даже в самом большом жестокодокументированном проекте.
Тест-кейсы, в принципе, необходимы для описания каких-то ситуаций, которые необходимо проверять ПОСТОЯННО. Т.е. это основа для регрессионного тестирования.
В контексте регрессионного тестирования не всегда необходимо проверять абсолютно всё. Поэтому возможно использовать необходимый задел проверок, которые будут расписаны в виде тест-кейсов — это будет отдельная документация.
И отдельно можно использовать чек-листы, которые могут хранится, что в обычных текстовых документах, что в каких то экселях, если угодно. Или в гуглдоках или даже в каких-то системах хранения тест-кейсов, но только они будут расписаны в виде заголовков.
Просто представьте себе — список кейсов, внутри которых ничего не написано, а написано только заголовки. Заголовок прочитал, понял что нужно сделать, взял и сделал. И можно отметить, что этот тест пройден или там, баг найден, все что угодно.
— У вас, лично, где хранятся тест-кейсы? Вы пришли к чему — в гуглдоках храните или вы отошли от них?
– У нас очень большая компания с множеством проектов, поэтому каждый проект являет из себя часть общей структуры, но тем не менее состоятельную и автономную боевую единицу. Тестировщики пишут кейсы, так как их учили, или как они привыкли, и когда они переходят между разными проектами, они все равно пишут по-своему. Кто привык в гуглдоках писать, тот и на новом месте начнет или постарается писать в все в гуглдоках.
Этого никак не избежать даже если на уровне компании объявить что будем работать по одной схеме. Общего алгоритма нет и быть особо не должно, потому, что должно быть удобно и эффективно работать, а не по определенным стандартам и шаблонам.
Еще у нас большинство проектов очень сильно зависят от заказчиков. Есть проекты, где требования приходят с самого начала, они прекрасно расписаны, они хорошо продуманы, над ними работают грамотные взрослые люди. Их тестировать достаточно удобно.
Есть проекты, где все сначала запускается и требования начинают писаться потом, уже после того, как программисты уже, что-то написали и надо это как-то зафиксировать. На таких проектах тестировщикам работать сложнее намного, но их выручает то, что у них есть чек-листы.
Если они на таких проектах писать тест-кейсы то это фейл однозначно. У нас есть опыт проектов, которые буквально фейлились из-за того, что тест-кейсов было штук 800 расписано. Мы по ним тестирование проводим регулярно, багов там уже практически нет. Баги начинают появляться там, где заказчик без всяких тест-кейсов просто ковыряется у себя в сайте и начинает обнаруживать проблемы.
А проблемы сыпятся одна за другой, так как тест-кейсами они небыли предусмотрены. Потому что в некоторые стороны тстировщики вообще не смотрели (потому, что мы акцентировались не на тестировании, а на написании документа, который покроет какие-то области). Это очень серьезный фейл со стороны тестировщиков, быть уверенным, что все баги не найти что заказчик сам не знает чего он хочет. Заказчик знает, чего он хочет. Проверить все, предусмотреть можно все. По меньшей мере, можно попытаться.
Помните в книге «Пролетая над гнездом кукушки» Макмёрфи попытался психам показать, что можно сдвинуть с места чугунный умывальник (все знали, что это невозможно сделать), он попытался — у него не получилось. Он сказал “ну я хотя бы попытался в конце то концов”. После этого вождь (был такой персонаж, постоянно молчащий, огромный, сильный, но духом слабый индеец) все-таки понял, что это можно сделать и вырвал этот умывальник с места и бросил его в окно.
Окно раскрылось — индеец ушел на свободу.