Кори сандлер том баджетт гленфорд майерс искусство тестирования программ

Учиться тестированию можно по-разному. Хорошие книги — источник базовых знаний и практического опыта экспертов.

Книги на русском языке

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

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

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

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

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

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

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

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

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

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

Оптимизация ресурсов и временных затрат на тестировании — важная и острая тема для команд разработки. Книга Рекса Блэка через контроль рисков рассказывает о 12 процессах тестирования.

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

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

Рекомендуется ведущим тестировщикам и специалистам среднего уровня.

Без автоматизации в тестировании сегодня никуда: чем сильнее ускоряется темп разработки и растут объемы задач, тем больше командам требуются новые быстрые технологии.

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

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

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

Книги на английском языке

Книга привлекает практической направленностью: авторы с богатейшим опытом собрали 293 урока, где коснулись основных вопросов тестирования ПО. Будет полезна и для новичков, и для опытных специалистов.

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

Классический учебник Бориса Бейзера, хорошо известный за рубежом и у нас. Его отличает целостный и методичный подход к изложению информации, понятный язык и широкий охват тем тестирования.

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

Книга содержит советы и четкие инструкции по тестированию мобильных приложений от практикующих специалистов. С помощью их рекомендаций, скриншотов и понятных объяснений начинающий легко разберется в процессе тестирования продуктов для операционных систем Android и iOS.

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

Ее можно перечитывать много раз и находить новые способы решения насущных задач. Автор рассказывает о различных типах атак: на сервер, на клиент, state based и других. Описание атаки состоит из вводной части, сферы применения и инструкции о том, как ее проводить.

Подходит уже работающим специалистам с базовыми навыками в тестировании в целом, но не знающим ничего о защищенности.

Автор рассказывает о верхнеуровневых классах проверок, например, на уровне кода или GUI, и приводит 19 атак на защищенность приложения. Каждое описание атаки или инъекции состоит из вводной части, описания случаев применения и руководства по нему.

Очень интересная книга, которая понравится всем уже работающим в команде тестировщикам, а новичков может спустить с небес на землю. Увы, только в учебниках и абстрактных компаниях проекты всегда задокументированы, а в архитектуре царит полный порядок. Эта книга рассказывает о жестокой реальности и развенчивает иллюзии в тестировании.

Автор приводит реальные типичные ошибки в подходах, а учиться на ошибках — самое полезное дело. В совместной работе специалисты часто переводят стрелки друг на друга и отказываются фиксить и документировать баг, ссылаясь на то, что это не их зона ответственности. Что с этим делать и как с этим жить — в том числе рассказывает Gerald M. Weinberg.

Заключение

Мы предложили вам 15 испытанных временем книг по тестированию программного обеспечения, которые помогут освоиться в этой профессии. А еще рекомендуем наш обучающий курс по тестированию. Здесь в доступной интерактивной форме под руководством наставников вы изучите актуальный материал, научитесь использовать его на практике и получите новую профессию с возможностью трудоустройства.

[youtube.player]

Тестирование – одно из наиболее стремительно развивающихся направлений в IT сегодня, а спрос на специалистов растёт день ото дня. Однако несмотря на появление всё новых инструментов, главным качеством тестировщика является знание основ и умение мыслить правильным образом. Образовательный портал GeekBrains, автор факультета тестирования ПО, подготовил для вас список наиболее известных книг, которые помогут вам в этом.

Эта книга всеобъемлюще подходит к формированию мышления тестировщика. Вступительная часть рассказывает о том, насколько серьезной может быть даже единственная ошибка в коде, и почему сегодня разработка качественного ПО не обходится без тестирования. Далее закладывается базис: когда проверяется код, каким образом, как всё организуется. Основная же часть – огромное количество кейсов-примеров из веба и мобильных приложений из всевозможных сфер – от прикладного ПО до электронной коммерции.

Если вы собираетесь сделать карьеру в области тестирования программного обеспечения, или если вы – разработчик, который хочет расширить свой кругозор, то это, безусловно, одна из лучших книг для вас

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

ATDD – методика разработки через приёмочные тесты. Это очень полезная философия для тех, кто хочет создавать стабильное качественное программное обеспечение в минимальные сроки, максимально избегая баги. Книга – начальный уровень погружения, однако и здесь вы сможете найти уйму кейсов с использованием разных языков и каркасов, наглядно показывающих, почему ATDD методика не просто полезна, а иногда необходима вашей команде. Разумеется, книга рассчитана на начинающих тестировщиков, однако ощутимую пользу найдут в ней и бизнес-аналитики, и руководители проектов из мира IT.

Тим Райли – один из руководителей Mozilla, ответственный за надёжность программного обеспечения. За свою карьеру, а это более 20 лет, он тестировал все, от симуляторов космических аппаратов до локальных веб-приложений с открытым исходным кодом. Он руководил командами по тестированию от 3 до 120 человек в 6 странах мира. Эта книга не о том, как тестировать код в том или ином случае (хотя это тоже есть), она посвящена вопросом организации работы как одного отдельно взятого исполнителя, так и большой команды. Формально книга написана для IT-руководителей, но с точки зрения формирования психологии она будет не менее полезна для исполнителей и тех, кто делает свои первые шаги в тестировании.

Книга логически поделена на 5 основных частей. Первая посвящена тестированию, как неотъемлемой части разработки ПО, здесь буквально на пальцах показывается его важность и место в жизненном цикле. В части второй затрагиваются математические и логические аспекты деятельности, в частности таксономия, построение блок-схем, разбиение кода на анализируемые составляющие. Третья часть уже посвящена непосредственно практике: генерации тестовых данных, определению функциональных и структурных критериев. В следующем разделе подробно описывается, как правильно анализировать результаты тестирования, а в заключении автор знакомит читателя с метриками и всевозможными инструментами. Таким образом, книга крупными мазками охватывает все важные темы профессии, легко читается, но всё же не стоит воспринимать её в качестве учебника.

Данному экземпляру уже очень много лет, первое издание было выпущено задолго до того, как тестирование стало столь важным направлением в IT. И во многом именно поэтому книга попала в этот список. Это, пожалуй, наилучшее пособие для тех, кто хочет перестроить образ мышления – от разработчика к тестировщику. Здесь очень много простых и понятных примеров, которые помогут сформировать правильную психологию. Кроме того, благодаря им вы поймёте основные принципы автоматизации, ведь большинство ошибок в коде имеют систематический характер, а значит могут отлавливаться общими алгоритмами.

А какую книгу по тестированию порекомендуете вы?

[youtube.player]

Тестирование, обучение, менеджмент и не только

вторник, 18 июня 2013 г.

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

Технико-тактические характеристики:
Год издания: 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 с примерами вопросов по тест-дизайну. Для более продвинутых тестировщиков я бы рекомендовал обратить внимание на причинно-следственные диаграммы: великолепный пример построения диаграммы с использованием базовых знаний математической логики, не сильно усложненный, как у Бейзера, но и не слишком упрощенный, где диаграмма "притягивается за уши" к тривиальному примеру.

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

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

[youtube.player]

Продолжая отдавать должное вопросам психологии в процессе тестирования, мы можем определить набор витальных (читай, чертовски жизненных) принципов тестирования. Многие из них покажутся очевидными, что, однако, не мешает зачастую ими пренебрегать. Вот они, а дальше – подробное их рассмотрение:

1. Обязательная часть тестирования – определение ожидаемого результата;
2. Программистам следует избегать тестирования их собственных программ (и участков кода);
3. Организациям, создающие программы, следует избегать тестирования их собственных программ;
4. Процесс тестирования должен включать в себя тщательную проверку результатов каждого теста;
5. Тест-кейсы должны быть составлены как для корректных и ожидаемых входных условий, так и для некорректных и неожидаемых;
6. Исследование Системы на предмет того, что она не делает того, что должна, — лишь пол дела. Вторая часть – разобраться в том, чего недолжного она делает;
7. Избегайте одноразовых тест-кейсов, только если сама программа не является одноразовой. Одноразовые тест-кейсы для одноразовых программ. В остальных случаях следует избегать таковых;
8. Не занимайтесь процессом тестирования с предустановкой, что вы не найдете ошибок;
9. Вероятность наличия ошибок в определенной части Системы пропорционально количеству уже найденных здесь ошибок;
10. Тестирование – это вызов вашим творческим и интеллектуальным способностям. Тестирование – это невероятно творческое и интеллектуальное занятие.

— описание входных данных
— точное описание корректных выходных данных для указанных входных данных.

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

Каждый писатель знает – или должен знать – что редактировать свою собственную работу – это плохая идея. Они знают, что именно должна сказать, к примеру, определенная глава книги, и поэтому могут не увидеть то, что она говорит нечто другое. И они как-то не хотят искать ошибки в своей работе. То же можно сказать и об авторах программных продуктов.

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

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

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

Это не значит, что путь тестирования собственных программ для программиста закрыт. Просто лучше (эффективнее), чтобы это делал кто-то другой. Разработчики могут быть полезными участниками команды тестирования, когда проводится оценка спецификации и самого программного кода.

И еще. Речь не шла о процессе дебаггинга. В этом случае автор кода является наиболее эффективным участником процесса.

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

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

Это очевидно, но это часто упускается. Мы знакомы с большим количеством случаев, когда ошибку не удавалось обнаружить даже тогда, когда ее симптомы были четко различимы в выходных списках (результатах). Если выразится по-другому, ошибки, которые находят в последующих тестах, часто не замечают в результатах предшествующих тестов.

Это естественная и здравая тенденция – концентрироваться на допустимых и ожидаемых условия в процессе тестирования. Пренебрегать недопустимыми и неожиданными условиями также естественно, но не также здраво. Много ошибок может выявится, когда программный продукт используется неким новым или неожиданным путем. Невозможно определить все сценарии, какими пользователь будет работать с продуктом, однако что-то отличное от спокойного, привычного течения программы, кажется, имеет все шансы на успех (в деле поиска ошибок).

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

Эта проблема, кажется, часто проявляется в различных системах для тестирования программ. Типичная практика – сидеть у компьютера и разрабатывать тесты на лету, и далее проводить эти тест-кейсы в программе. Суть в том, что тест-кейсы представляют собой ценные инвестиции, которые в рамках конкретного окружения могут исчезнуть, как только процесс тестирования будет завершен. И всякий раз, когда возникнет необходимость в повторном тестировании ПО (в регрессионном тестировании или при улучшении системы), тест-кейсы могут потребовать новой разработки. Это дополнительная, сложная работа, встречаясь с которой тест-инженер может волить избегать ее. Так получается, что последующие усилия на работу редко столь же объемны и качественны сколь объемны и качественны первоначальные. И если, к примеру, изменение функциональности влечет за собой ошибки, вновь разработанные тесты могут их не обнаружить.

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

Может показаться, что эта штука сомнительна, но такой феномен наблюдается во многих программах. На пальцах это вот как: предположим, что программа состоит из модулей А и Б. В модуле А было найдено 5 ошибок, а в модуле Б – всего лишь одна. И если модуль А еще не подвергся тщательному тестированию, тогда принцип говорит: вероятность найти еще больше ошибок в модуле А выше, нежели вероятность найти еще больше ошибок в модуле Б.

Другой способ проиллюстрировать указанный принцип такой: ошибки имеют волю к объединению в группы, и в типичном случае, определенные программные блоки больше подвержены ошибочности, нежели другие. Хотя это похоже на магию… ничем не подкрепленную магию. Она может быть полезна, поскольку дает некое понимание и обратную связь в процессе тестирования. Если какой-то участок программы кажется больше подверженным ошибкам, нежели другие участки, этот феномен намекает нам, что лучше бы нам потестировать здесь чуточку дольше. И это вопрос об инвестициях.

[youtube.player]

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

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

Гленфорд Майерс — компьютерный инженер и ученый, работал в Институте исследования систем компании IBM. Соучредитель и бывший исполнительный директор корпорации RadiSys.
Том Баджетт имеет богатый опыт руководства группами разработчиков ПО для крупных компаний. Автор более 60 книг на компьютерную тематику, работал техническим редактором в ряде компьютерных журналов.
Кори Сандлер — один из пионеров компьютерной журналистики. Начинал свою карьеру в агентстве Associated Press, после чего стал первым главным редактором журнала PC Magazine. Автор более 150 книг на компьютерную и деловую тематику. . more

Get A Copy

Friend Reviews

Reader Q&A

Be the first to ask a question about Искусство тестирования программ

Lists with This Book

Community Reviews

I have very mixed feelings about this third edition of what was clearly a landmark book when the first edition came out, over thirty years ago. I first read this book, way back in 1979. It was a godsend and I and relied on it very heavily to cover the testing topics in what was the first undergraduate software engineering course ever taught at the university I was at. Reading the third edition after putting aside the first edition for about a decade, I was immediately struck by how much my I have very mixed feelings about this third edition of what was clearly a landmark book when the first edition came out, over thirty years ago. I first read this book, way back in 1979. It was a godsend and I and relied on it very heavily to cover the testing topics in what was the first undergraduate software engineering course ever taught at the university I was at. Reading the third edition after putting aside the first edition for about a decade, I was immediately struck by how much my thinking on testing owes to Glenford Myers and to this book in particular.

However, as I continued reading, I became more and more uneasy. In a sense, how do you update a classic book? If the book purports to cover a field, you update it by keeping up with the field, adding heavily and judiciously pruning stuff which becomes obsolete. This has worked pretty well for Ian Sommerville´s or Roger Pressman´s massive tomes on Software Engineering, but this goes counter to Myer´s whole approach, which aimed at the heart rather than the body of the field and struck thrilling insights into the psychology of testing. The book had its faults, of course, such as Myers dutiful, plodding but ultimately not very convincingly coverage of cause-effect graphing and of higher-order testing, which though striking at first, slowly collapsed in time.

The worst of the new chapters is the one on agile development, which spends a great deal of time repetitively telling us what agile development is, but very little discussing its impact on testing and barely managing to slip in the JUnit tool. The chapter on web application testing devotes some time to the classic three-tier architecture (presentation, business and data levels) and goes on to provide a brief and sometimes repetitive overview of testing issues for the three levels. However, I fail to understand why the authors failed to tie the ideas on testing the presentation layer more strongly to the chapter on usability and why they skimped so much on testing the data layer -if there is a chapter on usability, I don´t understand why theey failed to add a chapter on database testing. The chapter on mobile application testing provides a good introduction to the topic but falls into the temptation, as in the chapter on usability, of mentioning so many topics, that the reader is left feeling helpless in the face of so many shadowy hinted-at complexities. Some of these new chapters have been edited rather carelessly -there is, for example a typo ("donstraints" instead of "constraints") and a spelling mistake ("shear" for "sheer") in just one page (page 215) and they are not as tightly written as the best of Myers.

Even twenty years ago, I would have recommended this book without hesitation, now I am not so sure. Some readers will still enjoy the key insights from both old and new chapters, others will simply yawn and pass them by. Glenford Myers´ book was a landmark, but like many landmarks, the sheer volume of new developments has severely eroded it -however, the perceptive reader should still be able to appreciate its legacy. I wavered between giving the book three or four stars, but Sandler and Badgett deserve recognition for bravery and Myers still has my gratitude for introducing me to testing, so four it is. . more

[youtube.player]