На днях прочитала, так что делюсь впечатлениями.
Сложновато было читать, постоянно сбивался фокус из-за того, что не всегда было понятно, что хотел сказать автор. Терминология была непривычная: летучка (стендап), продуктивная система / продукция (реальная система, продакшен) и т.п. Со многими идеями и утверждениями я бы прямо поспорила.
А еще мне показалось, что в книге про Agile-тестирование как-то маловато Agile-тестирования.
Автор обещает раскрыть тему тестирования в контексте Agile подхода:
В этой книге мы рассматриваем не столько Agile-подход сам по себе, сколько Agile-тестирование. (Стр. 12)
При этом книга включает
- Обзор методологий. Agile - с бОльшими подробностями, остальные - с мЕньшими)
- Верхнеуровневые описания различных видов тестирования, техник тест-дизайна и т п (общие сведения о «тестировании вообще», которые не являются специфичными для Agile)
- Психологические аспекты работы в команде
- Типология людей по «стилям общения»
- и т. п.
Глава «Agile-тестирование» занимает 14 страниц из 200.
Ниже приведу некоторые цитаты (с моими комментариями и без).
…Кроме того, тестирование - это свобода, по крайней мере в выборе используемых средств. Профессионал способен автоматизировать свою работу без внешних ограничений, которые необходимы при разработке. Он имеет больше свободы. Поскольку здесь важен результат. (Стр. 10)
У меня сразу возник вопрос - а что, разве для программиста результат
не важен? И свободы у него нет?
Какие внешние ограничения есть у программистов, которых нет у тестировщиков? Они точно так же могут выбирать используемые средства (а иногда - не могут. Как и тестировщики!).
С сегодняшними инструментами <…> каждый человек с развитым здравым смыслом может быстро стать профессионалом. Но хорошим специалистом его сделает только знание предметной области.
Это все равно, что сказать «только тот тестировщик хорош, который хорошо умеет автоматизировать».
Мне все же кажется, хорошими специалистами нас делает довольно много всего. Знание предметной области играет в этом роль среди всего прочего.
Исключать потери. Продвигаться небольшими шагами, будучи всегда готовыми откатиться назад. Принимать возможность неудачи и разрабатывать планы так, чтобы провал, если он произойдет, мог быть выявлен как можно раньше. Стремиться увеличивать скорее производительность, чем эффективность. (Стр. 25)
Тут я опять не поняла, что хотел сказать автор, так как до того шла речь о том, как Agile помогает повысить эффективность. Что конкретно тут имеется в виду под производительностью, не указано.
…создайте условия, обеспечьте поддержку и полностью доверьтесь «мотивированным профессионалам». Этот принцип сформулировали как раз они. (Стр. 21)
Общеизвестный обмен информацией за кофе часто очень эффективен. (Стр. 22)
Выпуск работающего продукта на каждом спринте… (стр. 23)
Когда старая бюрократия сменяется новой или теперь Scrum-мастер навязывает мелочную опеку вместо менеджера, то бесполезно ожидать увеличения эффективности. (Стр. 25)
…в конце книги есть список терминов, понятия которых, естественно, даны в контексте этой книги. (Стр. 14)
…что-то из этого является общеизвестным, но необходимым для создания полной гомогенной картины… (стр. 13)
Возможно, автор имел в виду «непротиворечивой»?…
Эта методология в принципе является воплощением прикладного эмпиризма…(стр. 38)
Во-первых, следует снижать идеальные ожидания и требования к производительности всех команды. (Стр. 40)