Простота - один из главных принципов гибкого тестирования. Очень жаль, что книга Лайзы Криспин и Джанет Грегори "Гибкое тестирование. Практическое руководство для тестировщиков ПО и гибких команд" этот принцип игнорирует.
Практическое руководство по гибкому тестированию описывает, как должен быть устроен процесс тестирования в гибкой команде, чем он отличается от традиционного подхода, какие используются типы тестов, как они автоматизируются и т.д. Все тесты разделены на 4 квадранта, каждый из которых подробно описывается. Наибольшее внимание уделяется тестам 3 и 4 квадранта, т.к. они позволяют найти наибольшее количество сложных дефектов и продемонстрировать возможности продукта заказчику.
Особенно хотелось бы отметить главу, посвященную автоматизации тестирования, поскольку оно вызывает наибольшее затруднение. Работа тестировщика пока что больше ассоциируется с ручным трудом, а навыки автоматизации уходят на второй план. Это объяснимо: человек, который владеет языками программирования, вероятнее пойдет в разработчики, нежели в тестировщики. Точка зрения, что тестировщик тоже должен уметь писать код пока что ломает привычную картину мира, причиняя сильную боль тем, кто годами выполнял тестирование вручную.
Еще одна хорошая мысль: тестирование должно уходить позиции "полиции качества" и становиться полноправным участником команды. Участие тестировщиков необходимо в ежедневных стенд-апах, их нужды не должны игнорироваться, а разработчики получат только пользу от сотрудничества с тестированием.
Вот так вот все полезное содержание книги на 450 страниц у меня поместилось в двух абзацах. Далее будут перечислены недостатки, из-за которых читать книгу сможет только крайне заинтересованный в этом человек.
Все начинается с 10 принципов гибкого тестировщика:
1. Обеспечение постоянной обратной связи
2. принесение пользы заказчику
3. готовность к личным контактам
4. смелость
5. простота
6. постоянное совершенствование практики
7. реакция на изменения
8. ориентация на людей
9. самоорганизация
10. удовольствие
Простите, а при чем здесь тестирование? Эти же принципы подойдут и учителю, и сантехнику. Вкратце: делай хорошо и будет хорошо.
Первые страниц 50 текст очень сильно "тошнит" словом "гибкий". Гибкий тестировщик - это тот, кто работает в гибкой команде гибких разработчиков, которые придерживаются гибких принципов реализации гибкого программного обеспечения - к этому сводится суть.
Дальше - полный гротеск. Традиционная модель демонизируется, тестировщики уподобляются "полицейским качества", авторы красочно живописуют разработчиков, которые не понимают менеджеров, и тестировщиков, которые считают неучами разработчиков, не жалея самых черных красок. Но чудо случается, когда все становятся "гибкими" - коллективный разум, самоорганизация и процветания воцаряются в компании. Приверженцы традиционной модели - закостенелые в своем невежестве неудачники, а новые гибкие специалисты - ангелы, несомые лучами солнечного ветра. Переход к гибкой системе непременно пугает, люди берутся за вилы, отстаивая старую парадигму, терпят сокрушительное поражение и, посрамленные, массово увольняются из компании. В то же время гибкий тестировщик представлен редким зверем, которого сложно найти и который свысока поплевывает на тех, кто привык работать в традиционной парадигме.
Вот еще одна цитата, которая поразила меня до глубины души: "Тестировщики привыкли сопровождать описание ошибок большим объемом информации, такой как условия ее воспроизведения, описание среди, в которой они найдены, в среде какой операционной системы и с использованием какого браузера". Звучит очень осуждающе. Даешь дефекты с минимальным количеством информации, и пусть все остальные понимают его как хотят! У меня был случай, когда разработчик сам нашел баг, завел дефект без описания и с названием в духе "Не прикрепляются файлы". Надо ли объяснять, что мне пришлось потратить время на то, чтобы выяснить, что имелось в виду?
Далее мне встретилась такая мысль: тщательно заводить дефекты слишком долго, да и разработчиков большое их количество демотивирует, поэтому не будем заводить дефекты. Мы ж эффективная команда, нацеленная на качество, поэтому и дефектов у нас будет минимальное количество. Я оставлю это без комментариев.
И отдельная история, от которой у меня сводило челюсти на протяжении всей книги, - это безумный фетишизм и пристрастие к бумажкам. Мы будем писать баги на стикерах, и клеить их на доску, а еще мы обклеим стены портретами наших потенциальных пользователей, чтобы не забыть о них. И это в 21 веке, когда идет речь о минимизации использования бумаги...
Сегодня я открыла advego - SEO-анализатор текста - и отправила на анализ 1 страницу из книги. Меня интересовал процент "воды". "Вода" - это незначимые слова в тексте: служебные части речи, устойчивые выражения, вводные конструкции, которые не несут смысловой нагрузки, а служат для связи слов и предложений. Нормальным показателем "водности" является 55-75%. Проанализированная глава состояла из "воды" на 73%. На мой взгляд, для бизнес-литературы "водность" не должна превышать 65%, так что здесь лишними оказались порядка 50 страниц. Это не похоже ни на простоту, ни на принесение пользы, ни на удовольствие, о которых так громко заявляется в самом начале.
P.S. В данной статье 67% воды.