Книжная полка. Cam Kaner "The domain testing workbook"

Как и обещал, делаю обзор на книгу по тест-дизайну. Встречайте - Cam Kaner "The domain testing workbook".

Технико-тактические характеристики:

Год издания: 2013 (Context Driven Press) - ссылка

Страниц: 488

Скорость чтения - 3/5 (средняя)

Время на прочтение:  12-18 часов с упражнениями
Полезность - 5/5 (высокая)

Сэм Канер в представлениях не нуждается: его книгу "Lessons Learned in Software Testing" рекомендуют всем начинающим и продолжающим тестировщикам. За 17 лет с момента первого издания книга не устарела, а Максим Захаров глава за главой в течение 2 лет перевел все 293 урока на русский язык. Затем Сэм Канер в том числе занимался и построением онлайн-системы образования для тестировщиков, критиковал традиционную схему MOOC (онлайн-курсов). Сейчас его онлайн-система работает, состоит из 4 онлайн-курсов, от BBST: Foundations, который является обязательным для доступа к следующим курсам, к курсам "Bug Advocacy" и "Test Design". На мой взгляд, курсы Канера - лучшие из тех, что я видел в онлайн-образовании для тестировщиков.

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

Но доменное тестирование - это не только разбиение на эквивалентные классы и граничные значения. "Прикладные" задачи по эквивалентным классам - одна из составляющих доменного тестирования. Я бы назвал доменное тестирование полноценной техникой с

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

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

Форма обучения и структура книги у Канера построена по спирали из 3 витков, каждый из которых более подробно раскрывает предыдущий:

1. Основные термины и определения, алгоритм доменного тестирования на примере простой задачи сложения двух целых чисел, 
2. Детальный анализ каждого из этапов доменного тестирования. Рассматривается шаг за шагом на 2-3 задачах с возрастающей сложностью. После каждого этапа автор дает 3-4 практические задачи.
3. Сборник из 30 задач с анализом решений по схеме доменного тестирования

В названии книги есть слово "workbook" (рабочая тетрадь), что предполагает работу читателем (решение задач) перед тем, как прочитать авторский ответ.

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

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

Книга не читается за 1-2 вечера. Как и "Lessons learned in software testing", книга по доменному тестированию будет хороша для неспешного чтения по одной-две составные части 4 шагов алгоритма и затем - закреплением на практических задачах в 3 части. Каждый шаг алгоритма прост, но хорош для самостоятельного анализа, так как оставляет читателю поле для маневра или подключения других техник черного ящика.

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

SQA Days-15 в Москве. День второй.

Продолжение. Обзор первого дня - http://qastugama.blogspot.com/2014/04/sqa-days-15-1st-day.html

После первого дня и афтепати пришел второй день, причем с не менее интересными докладами: Объяснение довольно простое - в субботу выступали Александров, Налютин, Руколь, Баранцев, Цепков и Болтон. Причем к докладу Майкла Болтона организаторы поставили в параллель Алексея Баранцева и Максима Цепкова с очень интересными темами, так что казавшийся еще до конференции очевидным выбор - "Ну конечно, Болтон!" - растерял былую уверенность и склонился к нашим гуру: все-таки у нашего трио с Intetics - меня, Сергея Остапенкова и Игоря Бондаренко - еще был впереди целый восьмичасовой тренинг от канадского гуру в мире тестирования. Но обо всем по порядку.

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

Цель тест-дизайнера - подготовить тест-кейсы, которые будут одновременно и для ручного прогона, и для написания на основе их автоматизированных тестовых скриптов. Без "фундамента" таких тест-кейсов вы не получите.

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

Далее от требований переходим к либо чек-листам, либо к непосредственному тестированию "прямо по требованиям", либо к тест-кейсам.

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

• формат тест-кейса: порядковый номер шага, воздействие на систему, ожидаемый результат
• отделяем шаги от данных
• избавляемся от циклов типа "повторить шаги 5-73"
• конструкций типа "любой", "подходящий" и т.п.
• разумный компромисс сложности шагов и наборов данных (пример: UI не должен зависеть от данных в одном тест-кейсе)

Григорий Сенин "Waterfall revisited: практические метрики тестирования"

Пошел на доклад, потому что это Люксофт: метрики в нем считать умели. И неожиданно для себя открыл, нет не Америку, но тоже интересную и наглядную идею и лабораторную формулу расчета качества продукта ("Менеджер, показать тебе качество?" - "Покажи!")

Q = P3 * P2 * P1

• P3 - коэффициент багов = количеству закрытых багов ко всем найденным (Closed / All Found). "Третий (красный) стакан" системы.
• P2 - процент выполненных тестов из числа написанных (Test Executed / Tests Desinged). "Второй (синий) стакан" системы.
• P1 - процент написанных тестов из числа всех тестов (Test Designed / Test Planned). "Первый (серый) стакан" системы.

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

• Разработка в разгаре (Р3 = 0, дефекты не исправляются)
• Разработка на финише (Р1 = 1, кейсы написаны)
• Шлифовка подсистем (Р2 = Р3, все найденные баги исправляются)
• Разработчики задерживают тестирование (Р2 близко к нулю, Р3 равно нулю)
• Требования задерживают разработку (Р1 = Р2 = Р3)

После этого докладчик на практических примерах показывал работу с показателями, взаимосвязь "стаканов" с burndown-chart'ом в Agile (прогноз скорости исправления, "зазор качества" и тем, откуда взять данные для подсчета коэффициентов-"стаканов".

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

Игорь Бондаренко "Crystal Agile, или как мы приспособили процесс разработки для обеспечения максимального качества".

Лучший "процессный" доклад конференции. Как мне кажется, он бы не затерялся и на менеджерской конференции, и на Agile-конференции. О том, как процесс из "классического" скрама из-за особенностей проекта и процесса (один тестировщик на проекте, и больше заказчик не хочет) превращается Crystal-процесс, при этом сохраняя требования к Crystal: ориетирован на людей, легкий и "stretch-to-fit". Процесс перехода занял 5 лет и все еще продолжается, поэтому не бойтесь экспериментов и работайте над качеством всей командой. И да, будьте человеком, который недоволен текущим процессом: кто как не мы должен быть рупором для улучшений. Авторские шаги получения данной методологии:

• Отказываемся от TDD в пользу BDD;
• Планирование - "метод взвешенных экспертных оценок";
• Формируем резерв спринта: загружаем спринт на 9 из 10 дней. Если появляются "горящие задачи" - тратим время на них, либо по приоритету, на уменьшение технического долга;
• Митинги - стэндапы не нужны
• Автоматизация: "наличие некрасивого теста лучше, чем его полное отсутствие"
• SOAP UI - для сервисов
• Вовлечение разработчиков в автоматизацию

Александра Ковалева "Планирование трудозатрат на тестирование"

Отметил для себя хороший и доступный уровень подачи доклада Александры еще на конференции SQA Days-12 в Минске, затем у нее был доклад про тестирование локализаций, вошедший в десятку на SQA Days-13 в Питере. Да и тема была для меня актуальная, поэтому мой обед ушел ко второй смене, а внимание - к планированию трудозатрат от Александры.

Планирование тестирования состоит из следующих шагов:

• Определение требований к тестам
• Оценка рисков
• Разработка стратегии тестирования
• Оценка ресурсов
• Разработка тест-плана
• Создание графика работ

Все шаги были доступно и с долей юмора преподнесены, информация есть на слайдах, а видео я порекомендую ждать тем, кто хочет увидеть реальный пример составления графика работ по тестированию на MS Project. Баланс теории и практики на 40 минут, хотя изначально, как я понял, он был составлен на 1 час 30 минут. Но... время ограничено, а другие докладчики тоже постарались, поэтому на конференции было всего 2 полуторачасовых доклада: упомянутый в первом дне конференции доклад Катерины Овеченко и завершающий второй день и всю конференцию Майкл Болтон.

Андрей Ладутько "Организация времени в тестировании".
Мой доклад, засветившийся только в обзоре моего коллеги Игоря Бондаренко, поэтому моя оценки субъективны и могут не соответствовать реальности :) Первая версия этого доклада завоевала третье призовое место на ConfeT&QA в октябре 2013 года, а затем, анализируя отзывы по докладу, меня посетила идея попробовать хронометраж в своей работе и рассказать подробнее об этом мощном и недооцениваемом инструменте тайм-менеджмента. Отброшенной оказалась еще часть теории, я добавил обзор хронометража и его эволюцию, как для себя, так и для коллег с поправкой на специфику работы каждого тестировщика.

Ask 100 testers to describe their job and you'll get 100 different answers.
Lucas Dargis.

Таким образом, от первоначального доклада осталась лишь треть, в пожеланиях к докладу, прозвучавших на репетиции доклада в минском QA Club'е, были еще больше практики и личного примера. Надеюсь, мне удалось этого добиться в выступлении, а пока я поставлю в планах подготовить текстовую версию данного доклада в блоге, как я в свое время делал с докладом по организации времени в тестировании на SQA Days-13: первая и вторая части.

Станислав Башкирцев, Юлия Атлыгина "Тестирование в опенсорс" (блиц).

Живой и увлекательный доклад о том, как же организовать тестирование там, где нет денег и нереально большая текучка кадров. Список используемых инструментов есть в презентации ниже (и он очень хорош, я хочу сказать), но меня как преподавателя курсов по тестированию
больше заинтересовал тот факт, что в таком вот опенсорсном проекте можно получить первый полезный опыт работы тестировщиком в команде, и затем найти первую работу. Сейчас уже, чтобы стать Junior QA, одного желания и одной прочитанной книжки Савина может оказаться недостаточно, и опыт в реальном опенсорсном проекте может пригодиться. Взял координаты коллег, если кого заинтересует стажировка в этом проекте - спросите у Стаса и Юлии :)

Дарья Костюк "Путь к трассировке требований: от идеи к инструменту" (блиц).

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

Алексей Баранцев "Тестирование на основе моделей: "ужас-ужас" или всё не так страшно?"

Сначала Алексей немного "потроллил" менеджерские доклады конференции и заявил техническую тему: Model Based Testing, или тестирование на основе моделей. С помощью Selenium Webdriver'a Алексей в прямом эфире закодировал простейший кейс с одним cостоянием системы и двумя возможными переходами "login-logout" и используя "магию" неизвестного фреймворка, генерирующего тесты на основе моделей (вместо традиционных линейных тестов). Но вот в "магии" вопрос остался открытым: то ли это бесплатная свободно распространяемая библиотека (что очень хотелось бы), либо новейшая закрытая разработка. Но подход интересный, а доклад оказался не таким уж сложным для понимания: я бы вместо трех заявленных звезд сложности оставил две. Но в целом, доклад и подход интересный, что тоже ожидалось, если вы были раньше или смотрели видео докладов Алексея.

Рина Ужевко, Андрей Мясников, Максим Цепков "Вы и Заказчик: решаем проблемы, а не отрабатываем требования".

Последний доклад московской конференции, партия, разыгранная на 3 докладчика, причем каких! Все имеют опыт выступления на конференциях, являются призерами конференций, и каждый со своей стороны - игры, продуктовая и заказная разработка - показывал на кейсах проактивно-сотрудническую работу с заказчиком. Итого, самая эмоциональная часть получилась у Рины (досталось же ленте малоизвестной соцсети Лицокнига), самая аналитическая - у Максима, а самая суровая и "мемистая" - у Андрея: мем про путиницу с большим отрывом занял второе место после боевого тестирования данных на проде работником Сбера, набравшего к моменту написания статьи 202 ретвита. Ну а суровость Андрею за правду жизни: "если в продукте есть косяки, которые появились из-за непонимания заказчиком и разработчиком друг друга, то не заказчик дурак, а ты виноват. Виноват всегда исполнитель." Так вот. Ну а вместе - отличный "тройной" доклад.

На этом я заканчиваю с докладами, в следующей статье я напишу о семинаре Майкла Болтона. Коллеги, было очень приятно завести новые знакомства, встретить старых знакомых, пообщаться в кулуарах и баре, побывать в Москве, обменяться идеями, послушать ваши интересные доклады, поделиться своим опытом. До встречи на следующей SQA Days!

Fun ConfeT&QA Осень-2013. Третий день. Обзор.

Отзвучали выступления последнего 31 3 дня Fun ConfeT&QA, а пока идет голосование за лучшего докладчика, давайте вспомним первый, второй дни, а ниже - поговорим о третьем, тем более что доклады стоят быть отмеченными.

Стартовал Алексей Лупан "Мелочь пузатая, или Объем тест-кейса против содержательности" - одно из  самых длинных названий доклада из представленных, и самая краткая аннотация. Алексей говорил о том, как надо писать тест-кейсы. Холиварная тема, чтобы не сбиться с идеи докладчика, рекомендую прослушать доклад в спокойной атмосфере, вдумчиво, попробовать на своих проектах, обсудить. И ... прослушать еще раз. Для начала - авторская ссылка http://bit.ly/16JP0rQ. И плюс тезисы доклада:
- как нужно писать тест-кейсы:
  - сперва нужно читать документацию
  - тесты надо придумывать до начала приступа (отличная фраза!) тестирования
  - весь упор нужно делать на идеи (идеи - основа всего)
- тест-кейсами надо пользоваться (а не писать)
- слабость чек-листа - отсутствие контекста, что делать
- тест-кейсы пишутся итеративно
- нужно уметь быстро записывать свои соображения в блокнот
- 1 идея - 1 проверка - 1 кейс

Следующий доклад - Николай Москаленко "Юзабилити анализ интерфейса с карандашом в руке". Николай предложил новую методику, как оценивать юзабилити, и на простых примерах продемонстрировал, как это работает. Вся "соль" этого доклада - в примерах, алгоритмы простые и понятные для начинающего usability-тестировщика. Отлично структурированный и преподнесенный доклад с правильными мыслями. Неожиданный фаворит Конфетки, в плюс - и отзывы в Твиттере во время и после доклада.
Учимся видеть usability-баги:
- различие между главным и остальным (четкая иерархия, главное - только одно)
- отсутствие инструкции
- дайте подышать (интерфейс не перегружен)
- меньше - лучше (только нужное в настоящий момент, нет элементов "на всякий случай")
- принцип пяти секунд (смотрим на интерфейс 5-7 секунд и спрашиваем себя:
  - куда я попал?
  - что я должен здесь сделать?
  - почему я должен это сделать?
Основные принципы дизайна:
- контраст
- акцент
- приближенность (группировка, количество элементов в группе - не более четырех)
- выравнивание
- повторение
- целостность

И "совиной песней" конфетки прозвучал доклад Ирины Винокуровой "Мы не баги, или как научить программистов тестированию". Красивые слайды, формат "story telling" о жизни тестировщика и программиста, как найти общий язык, говорить "так делать можно, а так - нельзя", "мир-дружба-шоколадка".

Вот и закончилась конфетка, не буду говорить долгие красивые речи, как Гусман на КВН, просто скажу, что с нетерпением жду следующую Конфету, возможно, опять подготовлю доклад, идеи в пороховнице есть. И спасибо докладчикам за эти три дня, за Funтастическую конференцию и атмосферу. QA show must go on!

Обзор 4. Никита Постолакий "Разработка тест кейсов по методике pairwise"

И опять - продолжение серии постов-обзоров. Доклады в подборке получаются разноплановые: были на русском и на английском, доклад-пазл с набором фишек для тест-менеджера, классический от гуру, story-telling... Теперь посмотрим мастер-класс по тест-дизайну с конференции SQA Days 11.

Сегодня у нашей рубрики виртуально в гостях Никита Постолакий "Разработка тест кейсов по методике pairwise". Pairwise testing или техника тестирования попарных комбинаций - один из методов черного ящика, применим для оптимизации количества проводимых тестов.

Однозначно must see для тест-дизайнеров, отличный доклад, будет полезен для ознакомления с этим замечательным методом, его применением и использованием одной из возможных бесплатной специальной тулы для моделирования тестов по pariwise - PICT. Полный список тулов для pairwise можно найти, например, здесь.

Еще к плюсам выступления Никиты можно отнести подачу материала в доступной форме, с ответами на вопросы прямо по ходу доклада. И еще, кроме самого pairwise, интересен сам процесс программирования модели из полученных входных данных.

Pairwise использует предположение (по докладу - исследование IBM), что к 97%  ошибок в ПО приводит взаимодействие всего двух параметров между собой. Поэтому, в случае если у вас, например, 3 параметра, у каждого из них 4, 5, 7 возможных значений соответственно, то не всегда имеет смысл проводить полный перебор всех возможных триад-комбинаций, количество которых в нашем примере равно 4 * 5 * 7 = 140. А что, если параметров не 3, а намного больше? А если увеличить не только количество параметров, но и возможных значений? Полный перебор займет очень много времени, и будет не очень эффективен в плане нахождения всех ошибок, так как...

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

В заключение, я дам вам еще несколько полезных ссылок на источники по pairwise-тестированию:

• http://www.amibugshare.com/pict/help.html - инструкция по PICT
• Доклад Алексея Баранцева на осенней Confet&QA-2012
• Книга Рекса Блэка "Advanced Software Testing - Vol. 1", раздел 4.3.
• http://hexawise.com - Сайт для генерации тестов по pairwise, довольно удобная альтернатива PICT. Очень удобная встроенная система обучения пользованию этим сайтом, рекомендую к прохождению.

Видео доклада:

Конспект:

• "К 97%  ошибок в ПО приводит взаимодействие всего двух параметров между собой" - исследование IBM
• Предварительная оптимизация данных: классы эквивалентности + граничные значения
• При добавлении сложных условий для пар - используем тулы (автоматизируем генерацию пар)
• Алгоритм разработки модели pairwise: сбор входных данных, оптимизация данных, описание зависимостей, автоматическая генерация тестов
• Требования к pairwise-инструменту: условия, типы данных, алиасы, негативные тесты, приоритизация (предпочтительные значения, наиболее приоритетные для проверки), регрессионные наборы (повторное использование при расширении набора)
• PICT, построение модели

Презентация доклада:

Книжная полка. Гленфорд Майерс "Искусство тестирования программ"

Прочитал книгу Гленфорда Майерса "Искусство тестирования программ", третье издание. Книга отличная, рекомендую.

Технико-тактические характеристики:
Год издания: 2012
Страниц: 272
Переплет: Твердый переплет
Формат: 170х240 мм, увеличенный
ISBN: 978-5-8459-1796-6
Скорость чтения - средняя
Ориентировочное время на прочтение: 8 - 10 часов

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

Большой плюс книги Майерса - ее объем: всего 270 страниц, на разбор самых важных 11 тем. Ничего лишнего, написанного для "утолщения" книги. Все углубления в тему к месту. Великолепная книга для закладывания "фундамента".

В аннотации книги автор рекомендует эту книгу трем категориям: программистам, менеджерам проектов и студентам ИТ-специальностей. Занимательно, что тестировщиков в этом списке нет :) Но кто, если не мы, объяснит этим трем категориям важность тестирования, заразит "качеством" всю команду? Кроме того, продвинутых знаний программирования для освоения приведенных в книге примеров, не требуется. Да и "командного" подхода к тестированию и чисто менеджерских глав в этой книге нет. А что касается третьей категории - студентов ИТ-специальностей - то среди них есть как будущие программисты, так и будущие тестировщики. Главное - что проблема качества это проблема не только тестировщика, но и всей команды. Поэтому либо читаем все вместе проектной командой, либо читаем сами, а затем "помогаем" менеджеру и программистам в борьбе за качество.

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

Глава 1. Тест для самопроверки. Короткое, на пару страниц, введение и вышеупомянутая задача про треугольники.

Глава 2. Психологические и экономические аспекты тестирования. Психология, связанная с определением тестирования; невозможность полного тестирования и использование стратегий "белого" и "черного" ящика; десять принципов тестирования ПО. Это базовые вещи, с которых надо начинать знакомство с тестированием.

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

Глава 4. Проектирование тестов. Самая объемная глава, целых 45 (!) страниц :) Наиболее общие техники белого ящика (покрытие операторов, покрытие решений и покрытие логики) и черного ящика (эквивалентное разбиение, граничные значения, причинно-следственные диаграммы). Для новичков можно посоветовать читать целиком, затем, по необходимости, "добивать" эти темы Канером и уже упомянутым ISTQB с примерами вопросов по тест-дизайну. Для более продвинутых тестировщиков я бы рекомендовал обратить внимание на причинно-следственные диаграммы: великолепный пример построения диаграммы с использованием базовых знаний математической логики, не сильно усложненный, как у Бейзера, но и не слишком упрощенный, где диаграмма "притягивается за уши" к тривиальному примеру.

Глава 5. Модульное тестирование. Пожалуй, лучшая практическая и "уникальная" глава в книге: чаще всего объяснения про МТ сводятся к простым примерам, например, как в Википедии: пишем тесты для функции сложения, используем предикат Assert. И да, модульные тесты должны писать программисты - гуглим. Майерс предлагает использовать методики белого ящика для проектирования тестов, а затем дополнить набор тестов тестами "черного ящика". В дополнение к проектированию, очень важно, как мы объединяем модули в работающую программу - для этого используем неинкрементное или инкрементное тестирование (автор показывает преимущества и недостатки обоих методов и предлагает использовать инкрементное тестирование,  на следующем шаге мы выбираем одну из возможных стратегий инкрементного тестирования - восходящее или нисходящее тестирование).
Хорошая новость для тех, кто хочет ознакомиться с этой главой - в бесплатном доступе есть возможность пролистать ее - http://oz.by/books/more10264179.html

Глава 6. Высокоуровневое тестирование. Рассматривается процесс разработки ПО как Получение требований -> Постановка целей -> Внешняя спецификация -> Проект системы -> Проект структуры программы -> Спецификация интерфейсов модулей -> Код. Затем мы используем три взаимодополняющий подхода, которые позволяют предотвращать и (или) обнаруживать ошибки:

• повышение точности разработки
• в конце каждого этапа вводим стадию верификации
• ориентируем конкретные процессы тестирования на конкретные процессы разработки

Третьему подходу и посвящена эта глава: рассматривается функциональное, системное, приемочное тестирование. Отдельно рассматривается инсталляционное тестирование и планирование и контроль тестирования. Модель Майерса напоминает V-модель тестирования ПО c небольшими отличиями.

Глава 7. Тестирование удобства использования. Общие рекомендации по тестированию юзабилити БЕЗ привязки к особенностям интерфейса различных ОС, user interface guide'ам и моделям GOMS в сочетании с законами Фитса и Хика. В книге рассматриваются только основы и процесс тестирования удобства использования с использование анкет.

Глава 8. Отладка. Глава скорее для программистов. Неэффективность метода "грубой силы" и принципы эффективной отладки, разбитые на 2 этапа: локализацию ошибок и их устранение.

Глава 9. Тестирование в среде гибкой разработки. Общие принципы Agile-методологий. Экстремальное программирование и тестирование. И все. Не рассматривается тестирование в скрам-командах, автоматизированное тестирование.

Глава 10. Тестирование интернет-приложений. Рассматривается архитектура e-commerce приложений, проблемы тестирования в веб, стратегия тестирования веб-приложений на трех уровнях: слой представления, бизнес-логика, слой данных.

Глава 11. Тестирование мобильных приложений. Структура главы аналогична предыдущей: архитектура сетей мобильной связи, стратегия тестирования мобильных приложений.

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