Артём,
 

Есть некоторые вопросы:
1.  В рекомендациях по написанию тест кейсов категорически запрещается ссылаться на другие тест-кейсы (их части).
Как вы тогда на практике решаете следующую ситуацию:
 a) Есть несколько довольно объемных блоков данных  (адрес, место работы и т.д.) и эти блоки в разных вариациях встречаются у большого числа пользователей на большом числе шагов, при этом они могут незначительно отличаться по содержимому
 б) При этом требования к блокам дополняются/изменяются в течение спринта.

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

Как я рекомендую поступать:
В одном тесте полностью расписать проверку блока (значения всех полей, редактируемость, обязательность, форматы и т.д.) а в остальных просто ссылаться на этот тест для проверки данного блока, при этом указывая отличия при необходимости.
Этим мы существенно экономим время на обновление всех X тестов при изменении требований к блоку.

А зачем нам в остальных тестах проверка этого блока, если мы его уже проверили одним тестом?
Тут ведь одно из трёх:
а) Если нам надо В ТОЧНОСТИ выполнить некие действия для нескольких тестов -- делаем набор, выносим эти действия в его пригтовления.
б) Если нам надо "примерно" выполнить некие действия (не важно, как именно, но в стиле "указать верные ФИО") -- снова делаем набор, выносим это в общие приготовления и подчёркиваем, что тут нужна вариативность.
в) Если нам надо выполнить некие специфичные для каждого теста действия, от которых зависят дальнейшее развитие теста и его результат -- тут я бы не ленился и писал в каждом тесте заново (да, даже богомерзким копи-пейстом и правками). Если подавляющий набор шагов/данных одинаков, а дьявол кроется в деталях -- см. выше про единые набор + "патчи".

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

2. В блоке 'Исходные данные' (стр. 122) вы настоятельно не рекомендуете описывать действия по подготовке, которые выполняются в  самом тестируемом приложении.
a) Пример 1: Как тогда вы будете проверять таблицу на отображение только 10 первых строк (если её наполнение происходит средствами приложения): первые шаги теста будут заключаться в наполнении таблицы данными, а не в непосредственном тестировании требования ?

Персонально я вообще бы напрямую через СУБД накидал в БД то, что мне нужно :). Особенно, если строк не 10, а 10 миллионов.
Но если это невозможно или нежелательно, то:
а) Набор из последовательных тестов.
б) Формулировка приготовления в виде предусловия: "В БД в таблице такой-то должно быть столько-то строк". Тесту ставить "невозможно выполнить", если добавить строки не удалось. Но сам тест, если он направлен на отображение, фейлить из-за невозможности вставки... как-то... не по фен-шую.
в) Если цель теста -- "запихнуть N >> 10 и убедиться, что отображается только 10", да, в шагах теста указал бы добавление. Если бы не добавлялось, зафейлил бы тест с чистой совестью.
 

б) Пример 2: Есть некоторый длинный бизнес процесс и у нас в конце есть форма, которую нам надо проверить. И есть сквозной смоук тест, проходящий по данному процессу.

Смоук-тест в виде последовательного сценария или нескольких независимых друг от друга последовательных сценариев.
 

Как я рекомендую поступать: в Preconditons делать ссылку на Smoke (т.к. не факт что каждый из тестировщиков, а тем более новичков понимает как дойти до нужного шага) и указывать шаг процесса, который нам нужен для проверки.

И вот однажды тёмной-тёмной ночью кто-то что-то меняет/добавляет/удаляет в "объекте, на который мы сослались" так, что у него всё логично и работает, а у нас получается бред. Что делать тогда?

P.S. Ещё раз суть: если у нас есть гарантия, что без ведома и позволения "ссылающейся части" никто не поменяет ничего в "части, на которую ссылаются" -- в путь и с песней. Но если такой гарантии нет, я бы предпочёл не создавать хитросплетение из перекрёстных ссылок. Т.е. запретить ссылки вообще. Ниче они начинают плодиться как кролики, и через какое-то время получаем "спагетти-тесты", если можно так сказать по аналогии со спагетти-кодом.

А мне понравилось.
Да, согласен, что книга в многом — «расширенный силлабус ISTQB». Но если к ней прилагается тренер и практические задания, то книга — отличный способ запомнить/упорядочить/уточнить/углубить и т.д., эдакий «конспект лекций».

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

В каком-то смысле, это задачи спецназа, если будет допустимо такое сравнение, а спецназ — это не массовка. Поэтому за год "привести к присяге" 200 человек — нет, "это не наш метод" :)
Поэтому и подготовка другая, всегда личностная.
[skip]
Итого - пять месяцев обучения для людей, которые приходят в тестирование "с нуля", в условиях, максимально приближенных к боевым.

Интересно то, что у нас очень похожая схема.
1) Отбор на т.н. "внешний тренинг" (на группу в 30 человек приходит от 300 до 800 заявок). Тут проходит отбор с рекрутёрами и техническими специалистами. Тренинг длится около 1.5 месяцев.
2) После внешнего тренинга проходит повторный отбор (в среднем, отбирается 20 человек из 30) с участием технических специалистов и тест-менеджеров. Эти отобранные попадают в т.н. "тест-лабораторию", где 2-4 месяца сидят full-time и обучаются на специально разработанных учебных проектах. С ними работают "специально обученные люди" :), которые в т.ч. могут обеспечить достаточно индивидуальный подход.
3) По мере того, как менеджер лаборатории считает тех или иных ребят "готовыми к бою", их показывают менеджерам с продакшн, проходит ещё одно собеседование. Прошедшие это собеседование попадают в продакшн в должности джуниора, где их показывают заказчику, постепенно включают в настоящий рабочий проект и доучивают (в т.ч. через индивидуальных менторов).

Этот подход вполне позволяет привести за год в компанию пару-тройку сотен человек, реально готовых работать (т.е. успешно проходящих собеседование с заказчиками). Проверено годами, результативность крайне высокая.

Святослав, а есть книга в формате fb2? Хотелось бы с телефона почитать, а в pdf не очень удобно :)

 

Ольга, увы, в fb2 нет. В книге есть некоторое количество картинок и таблиц, которые ну никак не "ужимаются" без потери здравого смысла. Потому даже в бумажной версии оставлен формат А4.

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

Антон, с этим утверждением скорее склонен согласиться. Хотя меня не покидает ощущение, что под "начинающий тестировщик" кто-то может понимать "человек, только-только услышавший о тестировании", а кто-то -- "нуу... это всего 1-2 года опыта" :).

P.S. Ваше мнение услышал, воспринял и учёл. Спасибо!

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

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

 

Что до вопросов от стажёров, то:
а) Ещё не вечер :). На широкую аудиторию книга была анонсирована всего неделю назад.
б) Стажёры же не только здесь вопросы задают.

P.S. Я анализирую поступающие отзывы и вообще реакцию сообщества на книгу: в первую очередь для доработок и прочих улучшений. Но заодно через какое-то время можно будет составить объективное представление о том, кому и как этот материал (не) оказался полезен. В общем -- пока ждём-с и читаем отзывы, а время покажет.

Ну, для корпорации я и сам написал бы istqb-like-мануал, но в учебном классе все равно учил бы так, как надо :)
Давайте говорить о принципиальных решениях задачи "как и чему учить начинающих". Все мои претензии именно в этом плане роятся.

Тогда я бы разделил "как" и "чему". И ещё добавил "кого и когда". При проведении тренингов для "совсем начинающих" в EPAM мы требуем, чтобы кандидат на зачисление в группу обязательно прочитал Савина перед подачей анкеты. Ибо Савин тут прекрасен. Есть (ох, сколько же их есть!) и те, кто совершенно ничего не понимает в книге Савина. Есть много тех, кто понимает. Есть достаточно тех, кто понимает много. И т.д. Надеюсь, логика ясна :). Дальше наступает тренинг длительностью 1-2 месяца, где ребятам надо дать основы и показать, куда двигаться. И тут тоже получается очень по-разному, т.к. все люди разные, и чем больше хороших разнообразных подходов мы можем использовать и источников информации предоставить, тем большее число ребят получат что-то, что им "зайдёт". Дальше наступает следующий этап обучения (2-4 месяца full-time) с уже своими нюансами... Но это тема совсем другой беседы :).
 

Программа ISTQB, которая предполагает учить новичков, строится на следующих уровнях:
Уровень 1: Запомнить.
Уровень 2: Понять.
Уровень 3: Применить.
Уровень 4: Анализировать.
Имхо, это неправильно для обучения начинающих. Взрослым - ок. Но начинающим надо сперва ПОНЯТЬ.
А чтобы понять, надо сперва ПОЩУПАТЬ.
А чтобы пощупать, надо сперва ДОГАДАТЬСЯ о том, что "в ящике есть что-то полезное".
А чтобы догадаться, надо сперва НАЧАТЬ ПОИСК РЕШЕНИЯ ЗАДАЧИ.
А чтобы искать, надо сперва столкнуться с ЗАДАЧЕЙ, которая требует решения.

... а чтобы начать решать задачу, надо сначала узнать о её существовании и знать о хотя бы каких-то направлениях "куда копать". При всей верности концепции получаем два неприятных недостатка:
1) Длительность и неочевидность процесса.
2) В предельном случае -- замкнутый круг: "я не знаю, как и что можно решать, и потому я не знаю, что можно решать и как".

Потому я вижу более оптимальный (исключительно с моей точки зрения!) процесс чуть-чуть иначе:
а) Демонстрация. Вот проблема, вот типичные пути её решения. Вот для того и того это нужно, такие-то плюшки приносит.
б) Расширение проблемной области через информирование: проблемы бывают ещё такими-то и такими-то, а решения -- такими-то и такими-то.
в) Практическое закрепление (почти один-в-один ваш алгоритм) через серию заданий, первые из которых почти сводятся к самостоятельному повторению показанного в пункте "а", а каждое следующее ставит всё более сложные задачи (но в рамках той информации, которая уже была донесена). И, наконец, ставятся задачи, способ решения которых надо найти совершенно самостоятельно. Но к этому моменту объём имеющихся у тренингуемого знаний позволяет ему понять, что искать, где искать, и как применить найденное.

 

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

 

В данном случае не имею ни тени возражения. Так оно и есть. Но что делать, когда за год нужно привести на работу 150-250 человек? Не "пропустить через тренинг", а именно отдать в проекты. И отдать не как камень на шею, а как вполне толковых "молодых бойцов", способных толково решать задачи своего уровня. Здесь, конечно, тоже применяется индивидуальный подход в рамках работы менторов с новичками, но продакшн вполне справедливо требует некоего стандарта: чтобы собеседуя джуниора на проект иметь некий универсальный базис, обязательный минимум для всех и каждого. Смею утверждать из десятилетнего опыта, что т.н. "ISTQB-подход" при всех своих понятных недостатках работает.
 
Лирическое отступление: самая жёсткая критика способа обучения, сторонником которого я являюсь, поступала и поступает из "педагогической среды", где предлагают использовать свой огромный арсенал технологий, в предельном случае позволяющий за 700 лет научить попугая автоматизировать тесты с WebDriver. Но это не работает, когда нужно:
а) Дать много людей.
б) Дать их быстро.
в) Дать их готовыми к работе.

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

Про альтернативный опыт:
[skip]

 

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

Отдал сегодня своим стажерам это на прочтение, на что получил закономерные вопросы:

- "А как тогда тестировать если всей этой документации нет?"

- "Бывают ли вообще проекты со всей этой документацией?"

- "А можно ли требовать это документацию?"

- "У кого ее требовать?"

 

На основе своих наблюдений пришел к выводу:

Начинающий тестировщик, прочитавший данную информацию, придет на свое первое место работы и просто впадет в ступор.

Впадет в ступор потому, что:

- документации всей может не быть

- вообще может не быть документации

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

- восприятие такой информации он может принять за общепринятую стандартизированную практику, которая применяется везде,

но в действительности это далеко не так.

 

[skip]

 

Так же хочу отметить, что 8 этапов в разделе "2.1.2. Жизненный цикл тестирования" перенасыщает начинающего тестировщика

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

 

Антон, по первому пункту про отсутствие (или низкое качество) документации ситуация явно выходит за рамки обсуждения книги :). Если вернуться к контексту, то:
1) Я рассматриваю обучение "совсем начинающих" по аналогии с автошколой: сначала учим ПДД и "как правильно". Если есть желание ездить как в "Mad Max: Fury Road", то это это будет потом, в особых случаях при понимании и осознании всех условий и последтвий.
2) У начинающих тестировщиков и так часто бывает ступор, но информация о документации даёт хотя бы какой-то ориентир. Даже если документации нет: появляются идеи о том, какие вопросы задавать.

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

4) Всё же мне кажется, что чем крупнее фирма, тем больше в ней шансов встретить проекты с худо-бедно пригодной документацией. В фирмах поменьше отсутствие документации компенсируется иными решениями, но вот это обсуждать откровенно не хочется.

5) При этом я не отрицаю справедливость вашего замечания: да, возможно, стоило описать и ситуации работы без документации (и уж тем более подчеркнуть ещё раз, что с ней могут быть проблемы). Признаю, посчитал это самоочевидным (отмечу на будущее для апдейта).

 

По второму пункту (о жизненном цикле): как вы верно заметили, у Савина это описано проще, и я решил не писать ещё одно "Тестирование.com" :).

 

P.S. Коллеги, я ещё ниже вернусь к конкретике, но уже сейчас хочу отметить одну вещь: мне кажется, некоторая часть критики книги происходит из представления картинки "взяли совсем-совсем новичка, дали прочитать книгу, бросили в бой". У большинства из нас есть опыт обучения "подмастерьев" и проведения тренингов, и мы прекрасно понимаем, что там допустим и даже необходим куда более упрощённый (и более индивидуальный) подход. Но! Начиная с какого-то момента джуниоры просят "почитать чего-нибудь посерьёзнее". Вот пусть и читают -- хоть Канера, хоть Коупленда, хоть Куликова: что-то всегда будет понятно одним, и непонятно другим -- это нормально. Пусть подойдут, спросят. Вот здесь автор очень точно подмечает: "отрасли критически не хватает компетенции ". И если изначально с первых же дней не давать правильных ориентиров и понимания необходимости в дальнейшем развитии, получается беда. Я насмотрелся на неё в самых разных проявлениях настолько, что уже больно почти физически. И написанная книга -- одна из попыток улучшить ситуацию. Хотя бы частично. Хотя бы для отдельных людей и отдельных компаний.

[skipped]

Система обучения, которой придерживается автор http://svyatoslav.bi...jste_trainings/ мною разделяется почти полностью, за исключением проповедничества подхода ISTQB к тестированию.

 

Алексей, спасибо за отзыв: по многим пунктам согласен и разделяю те же опасения и сожаления. Кроме ненависти :) к ISTQB: часто от заказчиков поступает прямым текстом обозначенное требование, чтобы в команде знали и понимали именно ISTQB-подход (и отклонения от него вызывают гримасу боли и/или непонимание).

 

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

 

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

 

P.S. Положенные в основу книги материалы за десять лет претерпели очень сильное изменение именно в сторону ISTQB. Сначала всё было "красиво, пушисто и самобытно", но потом пришёл "злой энтерпрайз" и всё стандартизировал :).