Обзор книги «Искусство тестирования программ»

Искусство тестирования программ

Сейчас вот сижу, и не могу понять, а зачем я вообще приобрел эту книгу? Стоит она не дешево — 1300 рублей за 260 страниц устаревших методик. Купился на явно липовые отзывы на озоне? Ладно, не могу сказать что книга прямо бесполезна, нового я ничего не узнал (какой сюрприз, я не узнал ничего нового из книги написанной в 1979 году), но кое-что любопытное прочел.

В России книга переиздана (в третий раз) в 2015 году, однако по сути, это все та же книга из 79того. Просто невозможно без умиления читать главу про методы тестирования Инспеции, сквозные просмотры и обзоры программ, подразумевающие собрание из пяти человек и групповое обсуждение за столом(без компьютеров) участка кода, со скоростью 150 строк в час. Я прямо представляю, как я собираю у себя в компании программистов: “Ну ребят, ну отвлекитесь, я там новые 150 строк напечатал, нужно обсудить, ну!!!”.

“Порадовала” глава Высокоуровневое тестирование, которую по хорошему нужно было назвать “Как не закончить проект никогда”. Глава рассказывает о том, как навести в проекте отличную бюрократию в стиле романов Кафки, и явно предугадывая реакцию какого-то “очень умного” программиста из далекого 2015 года, автор рассказал в этой главе про критерии завершения тестов… Ну ни один из этих критериев я бы использовать не стал, тем более, что среди них есть совсем уж бредовые.

Что!?!?

Некоторые главы просто повергают в шок. Например глава Модульное (блочное) тестирование… Возможно, в 1979-ом, под модульным тестированием понималось именно то, что описано в книге. Автор делит программу на условные связанные между собой модули (все правильно, ведь тестирование модульное) и предлагает поочередно тестировать каждый модуль. При этом, модули для которых еще нет тестов — автор заменяет на заглушки (ибо эти модули могут дискредитировать результат, нет им, мол, пока доверия), а уже протестированные модули остаются как есть, без всяких заглушек. Вот, я конечно понимаю, что автор писал книги по тестированию программного обеспечения когда меня еще в планах не было… но ведь не прав он. Ведь любой джуниор скажет, что это интеграционное тестирование, а весь смысл модульного в том, что бы протестировать каждый модуль отдельно, обособленно, независимо от любых зависимостей (мастер слога). И не только потому, что зависимости могут дискредитировать тест, скорее потому, что задача модульного тестирования как раз состоит в том, что бы доказать работоспособность конкретного модуля. К тому же, без зависимостей тесты проходят гораздо быстрее, а это очень важно, как показывает практика — никто не будет запускать тесты, которые нужно ждать.

Последние три главы книги появились в этом, третьем, переиздании, и они ужасны. Я читал, и понимал насколько автор уже не в теме, более того, насколько автору уже все это не интересно. Но издатель сказал надо — значит надо.

Глава Тестирование в среде гибкой разработки состоит из двух частей: в первой автор рассказывает про Экстремальное программирование, во второй про Экстремально тестирование. Зачем мне принципы Agile в книге про тестирование, я не знаю, ну да Бог с ним, еще 20 страниц. Экстремальным тестированием в книге обзывается TDD. Забавно что сам термин Test-Driven Development не упоминается ни разу. Однако справедливости ради, стоит отметить, что в этой главе, автор еще пока с нами, он немного путается в понятиях, но в общем, представляет о чем пишет.

В главе Тестирование интернет приложений автор начинает удивлять. Например он советует нам уделить особое внимание вопросам браузерной совместимости, если мы используем PHP. Ну все верно, ведь PHP встраивается в HTML, а значит выполняется браузером (это моя догадка, в книге нет пояснений тому, как код PHP зависит от браузера пользователя). Здесь же автор пытается дать нам представление о структуре web-приложения (которая, по версии автора, всего одна, для любого web-приложения), рассказывая о чем-то, отдаленно напоминающем MVC.

Ну и к разделу “Что!?!?” я просто не могу не отнести главу Тестирование мобильных приложений. Я долго думал, как бы про нее рассказать… но знаете, я просто выложу вам определение термина “Мобильное устройство и мобильное приложение” по версии автора. Думаю это определение очень красноречиво.

Вода.

Тело человека состоит в среднем на 60% из воды. Текст этой книги из воды процентов на 85. Большинство глав — это сухие длинные списки возможных маразматических ситуаций. Например, открываю наугад и читаю:

Если речь идет о таких системах, как интернет-банкинг, когда к точности предоставляемой пользователем информации предъявляются очень строгие требования, то предусмотрена ли достаточная избыточность входных данных? Например, для проверки того, что доступ к счету осуществляется авторизованным клиентом, а не постороннем лицом, такая система должна запрашивать номер счета, а также имя и персональный идентификатор (PIN) владельца счета.

То есть, если вдруг вы пишете интернет-банк, убедитесь что у вас есть система авторизации. И почти вся книга состоит из таких вот советов, в таком вот стиле изложения и с такой вот степенью полезности. Этот совет, кстати, из главы Тестирование удобства использования, и это не самая плохая глава… она просто написана, потому что нужно было добавить 50 страниц к книге. В остальном полезности от нее 0.

К этой же категории можно отнести главу Отладка. Глава занимает 20 страниц, и несет в себе одну мысль “Прежде чем браться за дебаггер, или разбрасывать по коду отладочные сообщения, сядь и подумай, в чем может быть ошибка”. Как по мне — слишком категорично, иногда быстрее локализовать ошибку именно дебаггером, чем размышлять, где же я мог ошибиться. Однако мнение имеет право на жизнь, в отличие от способа изложения, растягивающего эту простую мысль на 20 страниц.

Ложка меда в бочке дегтя.

Ох, я чуть не забыл про главу Проектирование тестов. Эта та самая глава, ради которой можно было бы купить эту книгу, стой она рублей 250. Здесь описаны различные методологии проектирования тестов. Ведь самое сложно при тестировании — написать правильный тест, который будет покрывать если не все, то самые важные кейсы, тест который будет искать ошибки, а не пытаться подтвердить их отсутствие. Автор рассматривает тестирование методами белого и черного ящиков, применение причинно-следственных диаграмм (не уверен что эти диаграммы применимы к современному ПО), классы эквивалентности и анализ граничных значений. Без сомнения, это важные темы, без сомнения автор писал эту главу со знанием дела.

Общее впечатление.

Не считая главы Проектирование тестов которую я прочел дважды (я иногда так делаю, что бы точно знать, что не пропустил ничего важного), книга постоянно вызывала чувство, что я просто теряю время. Большинство глав написаны для галочки. В главах Тестирование интернет приложений и Тестирование мобильных приложений — просто ересь. Стиль изложения очень сложный, максимально академичный. Примеры программ — максимально скучные (Типа: “Проиллюстрируем … на примере следующей спецификации команды отладки в интерактивной системе”, и потом на две страницы идет спецификация выдуманной команды которую нужно протестировать). И, что бы нас окончательно добить, большинство примеров кода на языке PL/1.
В итоге, очень очень редко, но случается, что мне жалко потраченного на книгу времени. В этот раз — да, жалко.

Не забудьте поделиться статьей с друзьями

Подписывайтесь на меня в соц. сетях

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *