Тестирование программного обеспечения. Базовый курс

Представляем книгу Святослава Куликова «Тестирование программного обеспечения. Базовый курс.».

В основу книги положен десятилетний опыт проведения тренингов для тестировщиков, позволивший обобщить типичные для многих начинающих специалистов вопросы, проблемы и сложности. Эта книга будет полезна как тем, кто только начинает заниматься тестированием программного обеспечения, так и опытным специалистам — для систематизации уже имеющихся знаний и организации обучения в своей команде. Книга распространяется под лицензией Creative Commons.

А мы просим всех, кто прочитал книгу поделиться своими отзывами у нас на форуме.

#2 astenix

ФИО: Лёша Лупан
Город: Кишинев

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

Это "самое то" для istqb-oriented мидлов. Для начинающих КОТЭгорически не подойдет. Запутает. А мидлам напомнит о некоторых детальках, которые "забываются", и напомнит еще раз, что тестирование — это очень просто, но когда понадобится грамотное тестирование, тогда извините, уже не каждый сумеет.

В этом контексте главы про тест-кейсы и дефекты местами шикарны.

Весь раздел 2.3 ("Классификация видов тестирования") — невероятно унылая копипаста из istqb-мануалов. Начинающих именно так и надо отпугивать от тестирования.

Термины надо ОБЬЯСНЯТЬ, а не просто толковать.

Пример жути, которая встречается в этом учебнике:

☆☆☆ Попарное тестирование (pairwise testing) — техника тестирования, в которой тест-кейсы строятся по принципу проверки пар значений параметров (переменных) вместо того, чтобы пытаться проверить все возможные комбинации всех значений всех параметров. Эта техника является частным случаем N-комбинационного тестирования (n-wise testing) и позволяет существенно сократить трудозатраты на тестирование (а иногда и вовсе сделать возможным тестирование в случае, когда количество «всех комбинаций всех значений всех параметров» измеряется миллиардами). Попарное тестирование (pairwise testing) — это НЕ парное тестирование (pair testing) ☆☆☆

Кагбэ, все правильно, не придраться. Но "выдавать" это новичкам? В разделе 2.7.4 приведено обьяснение pairwise, но ставлю золотой канадский доллар против медной турецкой лиры, что врубиться в это обьяснение сможет только тестировщик, ноги которого уже наполовину закатаны в асфальт колумбийской мафией. ISTQB, одним словом.

Удивило описание Exploratory testing: предлагается использовать этот подход, если нет времени на придумывание тест-кейсов. А именно:

Набросать список идей (чек-лист),
Протестировать приложение по этим идеям,
ПРОФИТ!
.

Японская япона мать, разве это — исследовательское тестирование? Разве это "одновременное проектирование и выполнение тестов"? Это же пример прекрасного классического тестирования, с непременным (ибо логично), хотя и несколько ускоренным и усеченным, но все-таки предварительным приготовлением идей о том, что надо тестировать ДО ТОГО, как взяться за, соппсно, тестирование.

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

Software Testing Glossary - простыми словами о непростых словах.

#3 svyatoslav

ФИО: Святослав Куликов
Город: Минск

[skipped]

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

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

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

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

#4 Tishka

ФИО: Ахрамеев Антон

2.2.2. Важность требований

Продуктная документация (product documentation, development documentation49) используется проектной командой во время разработки и поддержки продукта.

o План проекта (project management plan50) и в том числе тестовый план (test plan51).

o Требования к программному продукту (product requirements document, PRD52) и функциональные спецификации (functional specifications53 document, FSD54; software requirements specification, SRS55).

o Архитектуру и дизайн (architecture and design56).

o Тест-кейсы и наборы тест-кейсов (test cases57 , test suites58).

o Технические спецификации (technical specifications59), такие как схемы баз данных, описания алгоритмов, интерфейсов и т.д.

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

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

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

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

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

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

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

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

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

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

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

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

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

Спросил отдел разработки о таком кол-ве документации. На что получил от сеньеров внятный ответ:

"пункты 2 и 5 достаточно часто бывают, 3 реже, но тоже делают"

Так же один из фронтендщиков сказал такое: "А зачем вся эта документация для сайта-визитки?".

Вроде бы он пошутил, но на самом деле стоит задуматься.

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

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

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

P.S. Все это исключительно личное мнение и наблюдение за своими стажерами.

#5 astenix

ФИО: Лёша Лупан
Город: Кишинев

Ну, для корпорации я и сам написал бы istqb-like-мануал, но в учебном классе все равно учил бы так, как надо :)

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

Программа ISTQB, которая предполагает учить новичков, строится на следующих уровнях: Уровень 1: Запомнить. Уровень 2: Понять. Уровень 3: Применить. Уровень 4: Анализировать.

Имхо, это неправильно для обучения начинающих. Взрослым - ок. Но начинающим надо сперва ПОНЯТЬ.

А чтобы понять, надо сперва ПОЩУПАТЬ.

А чтобы пощупать, надо сперва ДОГАДАТЬСЯ о том, что "в ящике есть что-то полезное".

А чтобы догадаться, надо сперва НАЧАТЬ ПОИСК РЕШЕНИЯ ЗАДАЧИ.

А чтобы искать, надо сперва столкнуться с ЗАДАЧЕЙ, которая требует решения.

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

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

я пошел именно по этому пути. Обучение в группах — редкость, раза два в год, когда надо готовить группу новичков, из которых впоследствии только 60% получат офферы. В течение всего года обучение индивидуальное и личностное с каждым нашим тестировщиком. Иногда они пересекаются, и в течение дня у меня могут случиться по два митинга на одну и ту же тему :)

Вкратце: у меня есть план обучения для двух уровней, условно Junior и Middle. "Студент" работает на проектах, как обычно. Когда у него есть время — назначает мне митинг на очередную тему из плана, по которому он сейчас "проходит". Таким образом кто-то учится быстро, кто-то медленно, кто-то вообще выпадает со временем. Но важнее то, что обучение происходит каждый раз в тот момент, когда ученик к этому готов. И разговоры получаются всегда личностными.

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

Оценки: я их не ставлю нигде и никому. Поначалу менеджеры это очень просили, даже таблицу подсовывали, мол, давай оценивать успеваемость. Но это лишнее. Оценочность у нас происходит раз в полгода, когда затевается очередной performance review по всей компании. Оценку крутости каждого тестировщика делают его и окружающие, и тим-лиды (что важнее). Тим-лид точнее может сказать, стал ли тестировщик за прошедший период сильнее\умнее\веселее\понятливее.

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

Блэк и сподвижники затеяли правильную и нужную систематизацию и каталогизацию информации о всех аспектах, из которых складывается тестирование, и постарались сделать систему, по которой можно знания квантовать на малые доли и оценивать. Но они сделали "Университет", если угодно, со всеми понятными преимуществами и последствиями. Там учат ЗНАТЬ. А начинающих тестировщиков надо учить ДЕЛАТЬ.

Начинающие, которые учатся по канонам ISTQB, в какой-то момент приходят к ощущению "Я не согласен, я не понимаю, я фигею, но чтобы получить сертификат, мне надо согласиться и принять все как есть, не особо рассуждая, поэтому ладно. ". В контексте обучения новичков — это ужасно. Канер по этому поводу вообще хорошо сказал:

"ISTQB creates syllabi and exams that can be graded in a standardized way. Prep courses help students prepare for an exam that will be graded in a standardized way. This leaves less room for variation that reflects personal judgment.

I can respect this as exam preparation. However, many testers take only a few courses. If what they get is simplified and disambiguated, in my view, they are learning the wrong lessons about a field that relies (in my view) intensely on individual judgment".

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

Вот если уже взрослый дядька\тётька читает силлабус, и распознаёт, и понимает, что и почему в каких контекстах применимо, тогда ок. Взрослый дядька вообще понимает, что общая канва, которая прослеживается в ISTQB, относится к подходам, которые уже можно характеризовать как "Да пусть они скорее отомрут, сикока можно-то!". Дайте тестировщикам требования, дайте тестировщикам время, дайте тестировщикам ресурсы, и они дадут вам тест-кейсы. Это же Factory school, если этот канеровский термин будет принят. Это жесткач! Это же пресловутое "тестирование принтеров" из трудов Канера Фолка и Нгуена, на которое анадысь Роман Савин жаловался, дескать, фу, засыпаю. Конечно, засыпаю. Это же основы всех сферических велосипедов в вакууме! Но мне кажется невозможным становление мастера, который не изучает основы.

Материалы ISTQB вообще хороши на адвансед уровнях (не для детей). В сфере тест-дизайна их материалы вообще прекрасны, рекомендую каждому тестировщику таки врубиться в тест-дизайн не по блогам, и не ныть, что "в проекте не хватает времени, и вообще, никто же не просит делать этот pairwise". Конечно, не просят. Чистить зубы по утрам тоже никто не просит. Но до адвансед уровней кто доходит? Кто вообще берется за учебу, если в финале не светится вывеска "Тута сертификат дают! Бабла дадут! Тайтл дадут!"?

Посему, учить новичков сразу по ISTQB — нехорошо это :)

К слову, у программистов картинка с сертификациями несколько иная - http://www.nh.lv/it/. ru/519/681/692/

Software Testing Glossary - простыми словами о непростых словах.

📎📎📎📎📎📎📎📎📎📎