Erhalten Sie Zugang zu diesem und mehr als 300000 Büchern ab EUR 5,99 monatlich.
- Herausgeber: Питер
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Russisch
Хорошими тестировщиками не рождаются — ими становятся благодаря упорному труду и постоянному общению. На этом пути таится множество ловушек, способных сорвать самые смелые планы и привести к отставанию проектов от графика. Кем Кейнер, Джеймс Бах и Брет Петтикорд очень хорошо об этом знают. За их плечами более 50 лет опыта, и они понимают, что необходимо для достижения успеха в тестировании. Они собрали 293 проверенных совета, которые вы можете использовать в своих проектах. Каждый урок начинается с утверждения, относящегося к тестированию программного обеспечения, за которым следует объяснение или пример, показывающий, как, когда и почему применяется этот урок.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 453
Veröffentlichungsjahr: 2024
Das E-Book (TTS) können Sie hören im Abo „Legimi Premium” in Legimi-Apps auf:
Ähnliche
Переводчик С. Черников
Кем Кейнер, Джеймс Бах, Брет Петтикорд
Тестирование программного обеспечения: контекстно ориентированный подход. — СПб.: Питер, 2024.
ISBN 978-5-4461-2165-6
© ООО Издательство "Питер", 2024
Оглавление
Брайану Марику и Сэму Гакенхаймеру, подсказавшим идею этой книги.
Дэйву Гельперину, поверившему в нас и создавшему сообщество.
Джерри Вайнбергу, жизнь и работа которого воплощают самые высокие идеалы эксперта-тестировщика.
Памяти Анны Эллисон, коллеги и друга, 30 сентября 1952 г. — 11 сентября 2001 г.
Отзывы о книге
Откройте эту книгу на любой странице, почитайте пару минут — и у вас в копилке появится новый совет. Станьте профи по планированию, управлению и стратегиям тестирования.
Джоанна Ротман, компания Rothman Consulting Group, Inc.
Как бы вы ни тестировали ПО: сами или отдавая на аутсорс, прочитайте эту книгу. Каждая ее страница содержит полезные советы по решению ежедневных практических задач.
Сэм Гакенхаймер, старший директор по технологиям автоматизированного тестирования, корпорация Rational Software
Определенно, эта книга стоит того, чтобы прочитать ее и держать под рукой. Она толковая, имеет глубокий практический смысл и заставляет задуматься.
Росс Коллард, Collard & Company
Три выдающихся профессионала в области тестирования написали четко сформулированную и заставляющую задуматься книгу. В ней предложен особый взгляд на тестирование и управление тестовыми проектами.
Рекс Блэк, автор книг Managing the Testing Process и Critical Testing Processes
Эту книгу сообщество тестировщиков искало долгие годы. Ее следует прочесть всем руководителям и инженерам в сфере тестирования.
Джордж Хэмблен-младший, директор по обеспечению качества ПО крупной финансовой компании
Это не учебник. Это гораздо лучше. В книге описаны реальные примеры, обсуждаемые в рамках исследований. Я рад, что так много советов на тему тестирования собрано в одном издании. Думаю, оно породит множество замечательных дискуссий.
Стив Толман, менеджер по качеству ПО, PowerQuest
Уроки в этой книге представляют собой бесценные практические советы по тестированию ПО, полученные от ведущих экспертов. Если вы тестируете ПО или работаете в команде с тестировщиками, то эта книга — отличный источник знаний.
Алан Мирвольд
Четко и лаконично. Книга внесла ясность во многие ситуации из моего учебного опыта и породила множество новых идей.
Фран Маккейн, менеджер по тестированию ПО, компания Hewlett-Packard
Рецензирование этой книги стало для меня одним из самых ярких впечатлений. Я настойчиво рекомендую приобрести ее и держать под рукой всем специалистам по тестированию.
Ханс Бувальда, автор книги Integrated Test Design and Automation
Это золотой самородок, возникший как результат многолетнего практического опыта. Одна только глава, посвященная автоматизации тестирования, способна заменить все известные мне книги по данной теме. Глава о техниках содержит мощные идеи, изложенные простым языком!
Дуг Хоффман, консультант в компании Software Quality Methods, LLC
Эту книгу обязательно должны прочесть начинающие специалисты, занятые поисками проверенных и рабочих решений, а также практикующие менеджеры по тестированию, изучающие новые возможности усовершенствования рабочего процесса для своей организации.
Крис Денардис, руководитель отдела разработки ПО компании Rockwell Automation
...Предлагает бесценную коллекцию реальных практик, основанных на многолетнем опыте, которым поделились авторы и их коллеги. Абсолютно необходимая книга для всех, кто серьезно интересуется тестированием ПО.
Хунг К. Нгуен, президент и генеральный директор компании LogiGear Corporation, автор книги Testing Applications on the Web
Уроки просты и лаконичны — как раз то, что нужно для планирования тестирований поздним вечером. В других книгах много теории, и они отлично подходят для учебы, а в этой много реальных примеров, практического смысла и непосредственной пользы.
Мэри Ромеро Суини, автор книги Visual Basic for Testers
Превосходная книга. У меня был опыт, аналогичный описанному здесь, но не было возможности извлечь уроки, находясь в центре проблемы.
Стеле Амланд, Amland Consulting, Норвегия
Предисловие
Представьте, что держите в руках бутылку 50-летнего портвейна. Есть правильный способ пить портвейн. Он не единственный, но большинство людей, которые наслаждаются портвейном долгие годы, следуют определенным рекомендациям, которые помогают им получить максимально приятный эффект от его употребления. Вот лишь некоторые из них.
• Урок 1. Не пейте из горлышка. Если у вас нет ни бокала, ни другой посуды, то налейте немного портвейна на ладонь и пейте с нее. Делая глоток, вы должны ощущать аромат портвейна. Дайте напитку растечься по языку. Не пейте портвейн большими глотками.
• Урок 2. Не выпивайте всю бутылку сразу. Если вы пьете из-за того, что вас мучает жажда, то отставьте портвейн в сторону и выпейте воды. Вы получите максимальное удовольствие от портвейна, только если будете пить его маленькими порциями.
• Урок 3. Не портите портвейн. Если кто-нибудь посоветует вам попробовать коктейль из апельсинового сока, морской воды и портвейна, вежливо откажитесь. С широкой улыбкой скажите: «Я с удовольствием выпью просто бокал портвейна».
• Урок 4. Не жадничайте. Если вы будете придерживать напиток для себя, то никогда не узнаете, какое это удовольствие — вести приятную беседу, потягивая портвейн. Лучше всего пить его с друзьями, которые не прочь пропустить с вами бокальчик. Помните, что у них тоже где-то припрятана бутылка.
Вы держите в руках не бутылку портвейна, а бесценную книгу о тестировании ПО. Она доходила до совершенства на протяжении 50 лет работы авторов. Если портвейн предназначен для ваших вкусовых рецепторов, то эта книга — для вашего мозга. Думаю, что все остальные различия покажутся вам незначительными. Я ознакомился с данной книгой и хочу дать вам несколько советов, которые помогут получить максимум удовольствия от чтения.
• Урок 1. Не пейте из горлышка. Принесите свой бокал. То есть читайте эту книгу сквозь призму своего опыта разработки и тестирования ПО. Если вы никогда не принимали участия в серьезной работе над ПО, то при чтении этой книги можете на какое-то время впасть в замешательство. Если у вас есть опыт работы, то оцените содержание книги в контексте собственных проектов.
• Урок 2. Не выпивайте всю бутылку сразу. Не читайте эту книгу за один присест. Прочитайте пару уроков, закройте книгу и подумайте над словами Кейнера, Баха и Петтикорда. Вы узнаете, что они называют свой подход к тестированию контекстно ориентированным. Контекст собственной работы знаете только вы. Вам предстоит самостоятельно определить соответствие между данным уроком и вашей конкретной работой.
• Урок 3. Не портите портвейн. Кто-то может захотеть составить список названий 293 уроков, содержащихся в данной книге. Пожалуйста, пусть это будете не вы. Основу книги составляют пояснения к каждому уроку. Может быть также, что кто-то другой немедленно попытается привести ее к стандарту ISO или подвести содержимое под модель CMM. Представляется название статьи: «Достижение 293-го уровня CMM с помощью книги “293 урока тестирования ПО”». Кошмар! Как поясняют авторы, «...мы не верим в “лучшие практики”. Мы считаем, что при определенных обстоятельствах одни техники более полезны, чем другие». Будучи написанными профессионалами, эти уроки представляют собой квинтэссенцию достижения состояния мастера-исследователя тестирования ПО.
• Урок 4. Не жадничайте. Если и существует книга, которую следует читать вместе с коллегами, то это именно она. Купите несколько экземпляров и раздайте всем тестировщикам и тем, кто ими руководит. Прочитайте пару уроков и обсудите их за чашкой кофе, обедом или даже портвейном! Читайте, размышляйте, наслаждайтесь.
Ваше здоровье!
Тим Листер, 17 августа 2001 г., [email protected], компания Atlantic Systems Guild, Inc., Нью-Йорк
Введение
Международный стандарт SWEBOK (Software Engineering Body of Knowledge; «Свод знаний по программной инженерии») предлагается в качестве подходящей основы для государственного лицензирования, регулирования деятельности инженеров-программистов и разработки университетских учебных программ по программной инженерии. Документ SWEBOK претендует на звание основанного на консенсусе. Можно ожидать, что такой документ будет нести в себе знания и мудрость (уроки), накопленные в данной отрасли.
Вот что в SWEBOK говорится об исследовательском тестировании:
«Пожалуй, самой распространенной техникой остается свободное тестирование: тестировщик создает тесты, полагаясь на свое мастерство и интуицию (“исследовательское” тестирование), а также на личный опыт работы с аналогичными программами. Хотя рекомендуется использовать более систематический подход, свободное тестирование может быть полезным (но только если тестировщик действительно является экспертом!) для выявления особых тестов, которые нелегко “уловить” с помощью формализованных методик. Кроме того, следует напомнить, что показатели эффективности этой методики могут сильно варьироваться» (SWEBOK 0.95, 2001. Р. 5–9).
Как в SWEBOK трактуется то, что, по признанию его составителей, является наиболее широко применяемой техникой в данной области? В документе нет ни слова о том, как правильно применять эту технику. Есть лишь заявление, что исследовательским тестированием должны заниматься только настоящие эксперты, что рекомендуются иные подходы, а также высказывается предположение, что другие, формализованные методики будут менее эффективны.
Ха!
Мы не утверждаем, что наша книга выражает общее мнение и представляет собой свод знаний в нашей области, но нам есть что сказать о наиболее распространенных практиках в этой сфере. Вместо того чтобы отвергать исследовательское тестирование, в этой книге мы показываем, как выглядит тестирование глазами людей, использующих эти (и многие другие) техники в стремлении добиться превосходного тестирования в реальных условиях.
Добро пожаловать
Эта книга рассказывает о разработке ПО в том виде, в котором мы пережили этот процесс. Суммарно наш опыт разработки составляет 50–60 лет (в зависимости от того, как считать).
Эта книга не о том, какой могла бы быть программная инженерия в идеальном и контролируемом мире. Мы пишем о своем опыте работы в реальном мире.
В нашем мире команды разработчиков ПО часто работают в условиях жестких дедлайнов, выясняя, что нужно сделать, и одновременно изучая способы реализации этих замыслов. Иногда их подходы более формальны, иногда менее. Это зависит от целого ряда обстоятельств.
Мы придерживаемся контекстно ориентированного подхода в тестировании ПО. Мы предполагаем, что метод, прекрасно работающий в одних условиях, не будет работать в других. Вместо того чтобы говорить о лучших практиках, мы говорим о практиках, подходящих для конкретного контекста.
Мы стараемся выбирать практики с учетом конкретных обстоятельств, чтобы добиться отличных результатов. Мы не думаем, что, взяв проект в свои руки, добьемся высоких результатов тестирования, и не станем указывать руководителю проекта (или исполнителям), как должны вести проект настоящие профессионалы. Нам кажется, что в тестировании нельзя добиться высоких результатов, запугивая программистов или заискивая перед ними. Мы не думаем, что отличное тестирование можно провести, заполняя тысячи листов бумаги (или электронных документов) и тратя время других сотрудников на ненужные процессы.
У нас нет ни политического, ни бюрократического, ни формально-методического рецепта отличного тестирования.
Такого рецепта просто не существует!
Мы считаем, что отличное тестирование включает в себя умелую техническую работу (поиск дефектов) и четкую, аргументированную коммуникацию.
Квалифицированный поиск всегда носит исследовательский характер. Тестировщикам нужно выполнить бесконечное количество тестов, при этом времени, за которое можно провести хотя бы какую-то их часть, ничтожно мало. На каждое тестирование, каждый документ, который мы пишем, каждое совещание, на котором мы присутствуем, тратится время, которое можно было бы потратить на выполнение тестов, способных помочь выявить ключевой дефект. Столкнувшись с этим ограничением, мы оптимизируем процессы тестирования таким образом, чтобы в них использовались наши постоянно растущие знания о продукте, его рынке, областях применения и слабых сторонах. То, что мы узнаём сегодня, отразится в более мощных тестах завтра.
Даже если:
• у продукта хорошая спецификация и...
• она точно отражает документ с требованиями и...
• он точно отражает реальные потребности стейкхолдеров (заинтересованных сторон) продукта —
(вы когда-нибудь участвовали в проекте, где все эти «даже если» были правдой?), мы все равно узнаём много нового о том, как тестировать продукт, пока делаем это. В частности, по мере обнаружения ошибок мы узнаём, как конкретная команда программистов может ошибаться. В спецификациях рассказывается о том, как должна работать программа, если она написана правильно. В них не говорится, какие ошибки следует предвидеть и как разрабатывать тесты для их обнаружения. Выполняя эту задачу (а она является для нас ключевой), мы улучшаем свои навыки за то время, пока длится проект. И так происходит в каждом проекте.
Когда мы проводим тестирование и наш мозг активно работает, наша работа носит исследовательский характер. Независимо от того, как это выглядит со стороны.
Для кого эта книга
Книга предназначена для тех, кто занимается тестированием ПО, руководит тестировщиками, а также для тех, кому приходится работать со специалистами в этой области в своих проектах по разработке ПО.
В этой книге, говоря «вы», мы обращаемся к нашему основному читателю — к людям, которые работают в компании уже несколько лет и, возможно, недавно были переведены на руководящую должность. Надеемся, в уроках вы отметите много общего со своим опытом, получите новые знания, найдете такие уроки, которые сочтете полезным процитировать вашему руководителю. Мы также надеемся, что вам очень понравятся некоторые из наших утверждений и вы распечатаете их и повесите на стену в своем кабинете и, возможно, отреагируете хотя бы на одно утверждение настолько сильно, что прикрепите его копию на середину своей доски для дартса. (Мы хотим заставить вас размышлять, а не только добиться согласия.)
У тестировщиков-новичков (и у тех из вас, кто только устраивается на эту работу) ощущение, что вы уже сталкивались с тем, о чем мы пишем, будет возникать не слишком часто. Для вас эта книга может послужить неким первым толчком и предостережением, давая представление о том, с какими проблемами сталкиваются тестировщики.
Подсказка. Если вы новичок и ищете книгу, которая помогла бы научиться тестированию и подготовиться к собеседованию, то наша книга вам не подойдет. Если у вас нет других подобных книг, то обратите самое пристальное внимание на главы 3 «Техники тест-дизайна» и 10 «Ваша карьера в области тестирования программного обеспечения». А лучше всего прочесть первые пять глав книги Testing Computer Software1.
Программисты, руководители проектов и другие специалисты, которым приходится работать с тестировщиками, найдут в этой книге полезные идеи, позволяющие определить ожидания, которые возлагаются на команду тестирования. Мы надеемся, что это поможет вам оценить работу ее участников и обсудить с ними проблемы, если вы не согласны с их политикой или считаете, что они неразумно тратят свое время.
О чем эта книга
За годы работы мы узнали много полезных практик и способов оценки ситуаций. Наши выводы основываются на опыте. В книге мы обобщаем его значительную часть, преподнося выводы в виде коротких удобочитаемых описаний нескольких сотен уроков.
Мы приняли несколько критериев добавления того или иного урока в книгу.
• Урок должен быть полезным или давать понимание темы.
• Урок должен пройти 90-минутный тест на самостоятельность мышления. Иначе говоря, урок не стоит добавлять в книгу, если его смог придумать практически каждый, кто думал о тестировании в течение 90 минут, не отвлекаясь ни на что другое.
• Урок должен быть основан на нашем реальном опыте. Хотя бы один из нас (а лучше все трое) должен был успешно применять наши рекомендации. По крайней мере двое из нас должны были обжечься, пытаясь следовать практике, которую мы критикуем. (Примечание. Иногда мы приходим к разным выводам, основываясь на разном опыте. Иногда мы выбираем не одну, а две точки зрения. Даже если представлена только одна, нельзя считать, что все трое полностью с ней согласны, — в случае разногласий мы, скорее всего, отдадим предпочтение тому из нас троих, кто имеет наиболее богатый опыт в данной ситуации.)
• Уроки должны гармонировать с опытом наших коллег. Мы собирали подробные отчеты о нем на семинарах по тестированию ПО, проводимых в Лос-Альтосе, круглых столах для менеджеров по тестированию ПО, семинарах по эвристическим и исследовательским методам, семинарах по автоматизации тестирования, проводимых в Остине, семинарах по паттернам тестирования ПО, семинарах по автоматизированному тестированию на основе моделей, на десятках конференций по тестированию ПО и на менее формальных тренингах (например, в ежегодных лагерях консультантов в Крестед-Бьютте).
• Урок должен быть кратким и понятным, но при этом легким для усвоения.
• Урок может быть более длинным, но лишь настолько, чтобы можно было объяснить, как сделать что-то, или предоставить полезный инструмент. Длинные описания и подробная справочная информация приводятся в учебниках.
• Уроки должны быть самодостаточными. Вы должны иметь возможность начать чтение с любого урока.
• В совокупности уроки должны дать вам представление о том, как мы проводим тестирование, а также об образе мышления и логике тестировщиков.
Чего в этой книге нет
Книга не является подробным руководством по тестированию ПО.
Ее нельзя считать сборником абсолютно верных уроков. Это наши уроки, основанные на нашем опыте. Мы считаем, что они применимы в широком смысле, но некоторые уроки, оказавшиеся полезными и важными в нашей карьере, могут не подойти вам. Всегда следует опираться на собственные суждения. Универсальность нашей книги ограничивает тот факт, что мы больше занимались разработкой ПО для массового рынка и контрактного ПО, чем программным обеспечением, предназначенным для внутреннего использования. Наш опыт работы с жизненно важным ПО и встраиваемым ПО ограничен.
Кроме того, книга не является и сборником лучших практик. На самом деле мы не верим в «лучшие практики». Мы считаем, что при определенных обстоятельствах одни техники более полезны, чем другие. Мы обеспокоены тем, что многое из того, что продается в качестве лучших практик, продвигается (и применяется), не подвергаясь критичному осмыслению, в неподходящих ситуациях.
Структура издания
Мы написали книгу таким образом, чтобы ее можно было читать, начиная с любой страницы, или пролистать, а не пытаться читать ее строго от начала до конца. В какой-то момент (надеемся) вы обнаружите жемчужину, идею, которая вам очень понравится. Мы не можем рекомендовать вам слепо применять эту идею, не подвергая ее критике. (Наши уроки — это не «лучшие практики».) Вместо этого мы призываем вас оценить урок с точки зрения его соответствия вашей ситуации.
Далее приведены несколько вопросов, которые помогут вам провести такую оценку.
• При каких обстоятельствах этот урок можно было бы применить в вашей компании?
• При каких обстоятельствах урок не будет работать?
• Пробовал ли кто-нибудь из ваших знакомых что-нибудь подобное этому уроку? И что произошло? Почему? Чем ваш текущий проект отличается от проекта этого человека? Значимо ли это различие?
• Кто с наибольшей вероятностью выиграет, попытавшись применить этот урок?
• Кто с наибольшей вероятностью окажется в невыгодном положении в результате попытки применения урока?
• Что вы узнаете, попытавшись применить этот урок?
• Пробуя что-то новое, вы рискуете. Имеет ли смысл проверить применимость урока в вашей компании, проведя пилотное исследование — создав ситуацию для опробования новых знаний, не принимая на себя обязательств, или когда риск минимален? Можно ли провести пилотное исследование в вашей компании в рамках создания текущего проекта (или в ходе его обслуживания)?
• Как оценить эффективность применения этого урока? Если решение сработает, то как узнать, чем был обусловлен успех: ценностью самого урока, сохраняющейся в процессе его дальнейшего применения, или вашим энтузиазмом при опробовании идеи?
• Что хорошего или плохого может произойти при попытке применить этот урок?
• Что хорошего или плохого может произойти с другим заинтересованным участником, например с пользователем или другим членом команды разработчиков?
• Что делать, если ключевая фигура в вашей компании не согласна с решением в уроке, которому вы хотите следовать? Как можно преодолеть такого рода возражения и затем продать это решение данному человеку?
Надеемся, эта книга вызовет дискуссии и обсуждения
В книге проводится резкий контраст между нашими и некоторыми другими взглядами. Мы считаем, что это поможет разжечь дискуссии, которые должны вестись в данной области. По нашему мнению, общепринятой парадигмы в тестировании ПО или в программной инженерии в целом не существует. Именно поэтому мы не относимся к числу тех, кто выступает за государственное лицензирование и регулирование деятельности инженеров-программистов после стандартизации свода знаний. По нашему опыту, существуют совершенно разные, заслуживающие доверия мнения о том, как лучше выполнять работу.
Хотелось бы внести ясность в этот вопрос. Мы часто критикуем работу людей, которых очень уважаем. Во многих случаях мы ссылаемся на работы, выполненные нашими хорошими друзьями. Не путайте критику идеи с критикой ее сторонника или автора.
Мы считаем, что сравнение и противопоставление разных точек зрения пойдет на пользу сфере разработки. В этой области очень важно вести дискуссии о наших методах. Мы выступаем за дальнейшее развитие квалифицированной практики в рамках каждого из основных подходов. В конце концов, мы все узна́ем, при каких обстоятельствах различные подходы становятся наилучшими. А пока пусть процветает многообразие мнений.
Несколько замечаний по лексикону
Ниже приведены некоторые ключевые слова, встречающиеся в этой книге, и то, что мы в них вкладываем.
Мы. Авторы.
Вы. Читатель.
Сбой — это ошибка, оплошность в проекте или реализации программы.
В нашем понимании ошибка — это сбой.
Отказ — неправильное поведение программы, возникающее в результате сбоя.
Отказы происходят при определенных условиях. Например, при попытке деления на ноль произойдет сбой программы. В данном случае он кроется в коде, разрешающем деление на ноль. Отказ — это нарушение работы. Но он произойдет только тогда, когда критическая переменная при делении будет иметь значение, равное нулю. Эта переменная с нулевым значением представляет собой критическое условие, которое должно быть выполнено, чтобы произошел отказ.
Симптом похож на отказ, но является менее серьезной проблемой. Например, если в программе произошла утечка памяти, то ее выполнение может начать замедляться задолго до того, как произойдет сбой и будет выдана ошибка нехватки памяти — out-of-memory. Замедление выполнения программы представляет собой симптом глубинной проблемы (нехватки памяти), которая не очевидна.
Баг — всеобъемлющий термин. Он может быть связан с какими-либо неполадками в программном обеспечении. Тот, кто сообщает о возникновении бага, может описать сбой, отказ или ограничение программы, которое делает ее менее ценной для стейкхолдера.
Если мы определяем качество как ценность для какого-то человека (Weinberg, 1998, 2.i), то баг-репорт — это заявление о том, что какой-то человек считает продукт менее ценным из-за того, что в нем есть баг.
Слово «дефект» несет в себе юридический смысл. Оно означает, что с продуктом явно что-то не так. Некоторые компании не разрешают использовать слова «дефект» или «дефектный» в системах отслеживания багов или связанных с ними служебных записках.
Некоторые компании предпочитают вместо «баг» употреблять такие понятия, как «аномалия», «проблема» или «вопрос».
После того как вы сообщите об обнаружении бага, программисты (или совет по управлению изменениями) исправят его или примут решение не исправлять. Они помечают баг как решенный (исправлен, отложен, не воспроизводим, работает как задумано и т.д.).
Тестирование методом «черного ящика». Тестирование внешнего поведения программы путем ввода входных данных и изучения выходных. При типичной процедуре тестировщик не имеет представления о внутреннем устройстве кода, но хорошо знаком с явными и неявными требованиями к продукту, такими как способы использования программы, типы поступающих в нее данных, любые нормативные вопросы, связанные с проблемой, которую программа пытается или помогает решить, а также аппаратное и программное окружение для обеспечения работы данной программы.
Поведенческое тестирование. Тестирование внешнего поведения программы, аналогичное тестированию методом «черного ящика», но с использованием всего доступного тестировщику объема знаний о внутреннем устройстве программы.
Функциональное тестирование. Тестирование методом «черного ящика» или поведенческое.
Тестирование методом «белого ящика», или «прозрачного ящика». Тестирование с использованием знаний о внутреннем устройстве программы.
Структурное тестирование. Тестирование методом «белого ящика», направленное на изучение внутренней структуры программы, например потока управления от одного решения или действия к другому.
Смоук-тестирование, или верификационное тестирование сборки.Стандартный набор тестов, применяемый к новой сборке. Тесты позволяют выявить фундаментальную нестабильность, отсутствие или поломку ключевых элементов. Если сборка не прошла эти тесты, то дальнейшее тестирование не проводится. Вместо этого возобновляется тестирование старой сборки или откладывается до создания новой.
Руководитель проекта. Человек, ответственный за своевременную поставку нужного продукта в рамках бюджета. В некоторых компаниях работу, которую, по нашему мнению, делает руководитель проекта, поручают руководителю группы проектов и руководителю разработки.
MaxInt. Наибольшее целое число, возможное на платформе пользователя или языке разработки программиста. Число, превышающее MaxInt, не может быть сохранено как целое.
Клиент. Некто, интересам кого вы обязаны служить. К клиентам, вероятно, в той или иной степени относятся все участники проекта, а также конечные пользователи продукта.
От издательства
Ваши замечания, предложения и вопросы отправляйте по адресу [email protected] (издательство «Питер», компьютерная редакция). Мы будем рады узнать ваше мнение!
Выражаем огромную благодарность компании «КРОК» за помощь в работе над русскоязычным изданием книги и их вклад в повышение качества переводной литературы.
На веб-сайте издательства www.piter.com вы найдете подробную информацию о наших книгах.
О научном редакторе русскоязычного издания
Захарова Анна — старший инженер-тестировщик. Более 15 лет работала ведущим инженером-тестировщиком на проектах арбитражной судебной системы РФ, судов общей юрисдикции, проектах РОССТАТ, проектах ФОМС, интеграционных проектах.
1 Канер С. и др. Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений.
Благодарности
Выход этой книги был бы невозможен без поддержки и помощи многих людей. Мы благодарим Ленор Бах, Джона Баха, Бекки Фидлер, Лесли Смарт и Зака Петтикорда за поддержку, понимание и помощь, пока три сумасшедших человека не думали ни о чем, кроме своей книги. Благодарим Пэт Макги за помощь в проведении исследований в критический момент.
Нам помогли подробные и вдумчивые рецензии на первые черновики книги. Мы добавили в книгу несколько примеров и описаний альтернативных точек зрения, приведенных нашими рецензентами. Благодарим вас, Стеле Амланд, Рекс Блэк, Джеффри Блейберг, Ханс Бувальда, Росс Коллард, Лиза Криспин, Крис Денардис, Мардж Фаррелл, Дороти Грэм, Эрик Гриффин, Роки Гробер, Сэм Гакенхаймер, Джордж Хэмблен, Элизабет Хендриксон, Даг Хоффман, Кэти Иберл, Боб Джонсон, Карен Джонсон, Джинни Кейнер, Бартон Лейн, Пэт Макги, Фрэн Маккейн, Пэт Маккуэйд, Брайан Марик, Алан Мирволд, Хунг Нгуен, Ноэль Найман, Эрик Петерсен, Йоханна Ротман, Джейн Степак, Мелора Свобода, Мэри Ромеро Суини, Пол Шимковяк, Энди Тинкхэм, Стив Толман и Тамар Ярон.
Содержимое этой книги значительно улучшилось благодаря многочисленным обсуждениям на семинарах по автоматизации тестирования (Лос-Альтос), семинарах по эвристическим и исследовательским методам, круглом столе менеджеров по тестированию ПО, семинарах по автоматизации тестирования (Остин), семинарах по паттернам тестирования ПО, а также на многих других семинарах, конференциях, занятиях и площадках с большим количеством людей, вкладывающих всю душу в поиск лучших способов тестирования ПО. Мы благодарим каждого из вас.
Глава 1. Роль тестировщика
Что тестировщики должны делать в проекте? Как и многое другое в тестировании, ответ на данный вопрос может показаться очевидным или простым, но это не так.
Любая роль подразумевает взаимоотношения. Это означает, что вы не контролируете свою роль, но можете договориться, в чем она состоит. Люди ожидают от вас того, что может быть неразумным. Когда вас обвиняют в низком качестве продукта (а такое случается), обвиняющие, вероятно, неправильно понимают роль тестировщика. Возможно, они считают, что ваша работа — бить по продукту волшебным молотком качества, и думают, что вы бьете недостаточно сильно.
Четко представляя себе свою роль (обсудив и утвердив ее рамки), вы понимаете, на чем могут основываться ожидания в любой возникающей ситуации. Однако следование даже четкой и адекватной роли в тестировании требует больших усилий.
Урок 1. Вы — «свет фар» проекта
Проект — своего рода дорожное приключение. Некоторые проекты просты и рутинны, как поездка в магазин. Но реализация большинства проектов скорее напоминает ночное вождение грузовика по горному бездорожью. И здесь не обойтись без света фар. Как тестировщик, вы освещаете путь. Вы освещаете дорогу, чтобы программисты и руководители, как бы ни спорили по поводу дорожной карты, могли хотя бы видеть, где они находятся, куда едут и насколько они близки к краю обрыва. Конкретная цель команды тестировщиков меняется в зависимости от компании, но все нюансы и различия объединяет нечто общее.
Тестирование проводят для того, чтобы найти информацию. На ее основе принимают критические решения по проекту или продукту.
Урок 2. Ваши цели управляют тем, что вы делаете
Ваши цели могут зависеть от отрасли, компании, проекта или состава команды. Тестирование проектов сильно различается в разных компаниях. В процессе развития тестирования как ремесла возникла необходимость обсуждать практику тестирования, в ходе чего можно было бы преодолеть культурные и технические различия. Многие из них обусловлены разными целями команд тестирования. Например, в одних организациях тест-план — просто инструмент, помогающий тестировщикам. Он может быть написан на салфетке и все равно быть эффективным. Другие организации создают тест-план в виде продукта, который должен поставляться вместе с их программным обеспечением. Их тест-план соответствует строгим требованиям и инструкциям.
Некоторые из указанных ниже требований могут определить вашу цель. Чего ждут от вас?
• Быстро найти важные баги.
• Дать общую оценку качества продукта.
• Удостовериться, что продукт отвечает конкретным стандартам.
• Помочь клиентам улучшить качество и тестируемость продукта.
• Удостовериться, что процесс тестирования соответствует стандартам.
• Рассказать клиентам о тестировании и как работать с тестировщиками.
• Следовать конкретному набору методов и правил.
• Помочь предсказывать и контролировать расходы на техподдержку.
• Помочь клиентам улучшить их процессы.
• Выполнить свою работу с минимальными расходами, за минимальное время или с минимумом негативных последствий.
• Делать все, что требует конкретный клиент.
Если вы тратите время и силы на выполнение требований, которые не волнуют клиентов, то рискуете прослыть неактуальным и контрпродуктивным. Обсудите ваши цели с руководителем. Проясните их. Если вы не сможете прийти к согласию касательно целей, то вам не на что будет опереться в процессе работы.
Что вы должны делать, когда не знаете, что делать? Один из ответов — пересмотреть вашу цель. Она определяет суть проблемы, с которой вы столкнулись. Установив четкую цель тестирования, вы сможете защитить свою работу и определить, что будете делать дальше. Вы также сможете простыми словами объяснить окружающим, в чем заключается ваша роль. Если по каким-то причинам вы не можете выполнить свою задачу, то сразу же обратитесь к руководству.
Что вы должны делать, когда точно знаете, что делать? Время от времени возвращайтесь к вашим целям, чтобы убедиться в том, что в ходе четкого следования плану не погрузились в одну часть задачи тестирования и не забыли обо всех остальных.
Урок 3. Вы обслуживаете разных клиентов
Тестирование — это услуга. Прочувствуйте это. Услуга, которую вы предоставляете, жизненно важна. Услуга подразумевает наличие клиентов — людей, которых вы обслуживаете. Ваш успех измеряется в первую очередь тем, насколько удовлетворены желания и интересы клиентов. Это может быть не так уж сложно, если не считать того, что тестирование нужно многим клиентам. Каждому из них требуется что-то свое, и их запросы не всегда совпадают.
• Руководитель проекта. Руководители имеют право знать ваш процесс работы и влиять на него. Вы оказываете услугу руководителю проекта, сообщая ему о ходе работ, о важных проблемах и не становясь мешающим фактором. Прерогатива руководителя — управлять проектом. Ваша работа — сказать ему, что вы можете сделать, а что — нет и как повлияет на тестирование то или иное решение или условие проекта.
• Программист. Вы упрощаете работу программиста, создавая настолько ясные баг-репорты (bug reports, «отчеты о багах»), насколько это возможно. Стремитесь быть профессионалом в своем деле и разбираться в продукте, чтобы не тратить время программиста на ложные или поверхностные баг-репорты. Если вам это удастся, вы завоюете больший авторитет у разработчиков. В свою очередь, это приведет к тому, что вы получите их поддержку и сможете выстраивать продуктивное общение.
• Технический писатель. Как и вы, люди, которые составляют руководства и интерактивную справку, имеют неполную информацию о продукте. Вы можете помочь им понять, как он работает на самом деле, и предупредить об ошибках в документации. Писатели тоже могут помочь вам. Изучая продукт и то, как его будут использовать люди, читающие документацию технические писатели узнаю́т то, чего не знаете вы. Если у вас хорошие отношения с техническими писателями, то они будут сообщать вам о новых функциях, новых способах использования, слабых местах в ваших тест-планах и найденных багах. Некоторые из этих багов никогда не были бы найдены с помощью тест-планов.
• Техническая поддержка. Любая проблема в продукте становится бременем для людей, обеспечивающих техническую поддержку. Вы сообщаете команде поддержки о тех аспектах применения продукта, которые могут вызвать затруднения у пользователей. Если вы взаимодействуете с представителями техподдержки в процессе разработки, то иногда они могут помочь вам доказать, что баг необходимо исправить. В свою очередь, вы также можете предлагать свою помощь в изучении сложных проблем, возникающих в предметной области. Таким образом можно улучшить контакт между техподдержкой и клиентами.
• Маркетинг. Маркетологам нужно знать, не противоречит ли что-либо в продукте ключевым преимуществам, которые описываются клиентам. Баг, который кажется незначительным программистам, может оказаться критическим для маркетологов. Они могут понять, что из-за бага клиенту сложнее выполнить важную задачу. Кроме того, просматривая запланированные маркетинговые документы, вы можете помочь маркетологам составить точное представление о возможностях продукта.
• Топ-менеджмент и стейкхолдеры. Вы обслуживаете бизнес. Поэтому вы должны быть осторожными, чтобы выглядеть и вести себя как разумный человек, а не как фанатик качества. Особенно ближе к концу проекта выполняйте свою работу таким образом, чтобы учитывать краткосрочные и долгосрочные интересы компании. Составляйте отчеты о состоянии тестирования, используя четкие и понятные термины, чтобы руководители чувствовали, что им есть на что опереться при принятии решений.
• Пользователи. И разумеется, вы обслуживаете тех, кто будет пользоваться продуктом. Конечно, удовлетворение их запросов отвечает интересам вашего проекта. Но и то, что вы являетесь главным защитником интересов пользователей в проектной команде, приносит особое удовлетворение.
Этот список не отсортирован по приоритету, но в вашем проекте такая иерархия может быть, поэтому узнайте ее. Выясните цели своего проекта. Узнайте, кого вы обслуживаете. Это первый шаг к отличному тестированию.
Урок 4. То, что вы обнаружили, может быть багом с точки зрения людей, мнение которых имеет значение
В задачи вашей команды входит (или должно входить) информирование клиентов обо всем, что угрожает ценности продукта, определенной так, как ее понимают клиенты. Если вы считаете, что продукт не будет оценен по достоинству, даже если работает должным образом, то обязаны сообщить о своих опасениях. Если клиенты решат проигнорировать ваше сообщение, это их право.
Урок 5. Быстро находите критические баги
Вероятно, в ваши цели входит поиск критических багов (в отличие от незначительных), и он должен быть быстрым. Если да, то что это означает в контексте тестирования?
• Тестируйте изменившиеся части прежде неизменившихся. Исправления и обновления означают новые риски.
• Тестируйте базовые функции прежде вспомогательных. Проверяйте критические и популярные функции продукта. Тестируйте функции продукта, которые делают его таким, какой он есть.
• Тестируйте возможности прежде надежности. Проверяйте работоспособность всего функционала, прежде чем углубляться в изучение особенностей работы функций в различных условиях.
• Тестируйте стандартныеусловия прежде гипотетических. Рассмотрите популярные данные и сценарии использования.
• Тестируйте распространенные угрозы прежде малораспространенных. Проводите проверки на наиболее вероятные стрессовые и ошибочные ситуации.
• Тестируйте проблемы, которые могут нанести больший вред, прежде тех, последствия которых не слишком серьезны. Проверяйте модули продукта, которые в случае отказа могут причинить наибольший ущерб.
• Тестируйте наиболее используемые области прежде невостребованных. Проверяйте любые области и обсуждайте проблемы, которые интересны еще кому-либо в команде.
Кроме того, вы быстрее обнаружите важные проблемы, если будете больше знать о продукте, программном и аппаратном обеспечении, с которым он должен взаимодействовать, и о людях, которые будут его использовать. Хорошо изучите их.
Урок 6. Работайте вместе с программистами
Помощь программистам, вероятнее всего, является вашей ключевой задачей. Если вы тестируете функционал, который программисты создали только что или недавно, то ваша обратная связь поможет им быть более эффективными. Когда они поставляют продукт, вы его тестируете. Если они внесли какие-либо изменения — протестируйте их. Стремитесь к тому, чтобы цикл обратной связи был максимально коротким и быстрым. Пока программисты будут разбираться с багами, которые вы нашли, занимайтесь поиском других багов. Идеальная (для тестировщиков) ситуация — это когда программисты заняты исправлением найденных вами проблем так сильно, что именно они, а не вы являются узким местом проекта.
Урок 7. Спрашивайте обо всем, но не обязательно вслух
Можно тестировать, не задавая вопросов, но лучше так не делать. Вопросы — основа вашей роли в проекте. Если вы их не задаете, то тестируете бесцельно и механически. Однако учтите, что некоторые явные вопросы могут показаться провокационными и люди начнут защищаться.
Вопросы подобны сильному лекарству: их лучше давать малыми дозами или сочетать с другими видами общения. К счастью, ценность вопросов не уменьшается, если задавать их не вслух. Любой вопрос, который приходит вам в голову, может подтолкнуть ваши собственные мысли в нужном направлении, что приведет к важным открытиям.
Если однажды в процессе тестирования вы поймете, что у вас нет вопросов по продукту, — сделайте паузу.
Урок 8. Сосредоточьтесь на отказах, чтобы ваши клиенты могли фокусироваться на успехе
Тестировщик — единственный участник проекта, который не ориентирован непосредственно на успех. Другие участники что-нибудь создают или описывают уже созданное. А тестировщики ищут негативные факторы. Тестирование может быть депрессивной работой, сродни пародии на греческий миф: «На острове тестировщиков они были обречены вечно искать то, чего не могло быть и не должно было существовать, зная, что успех принесет несчастье богам».
Было бы ошибкой переопределить вашу цель более позитивно — что вы человек, который проверяет, работает ли программа. Даже если вам поручат «убедиться, что программа работает», расскажите своим клиентам, что такая проверка невозможна. Она стоит очень дорого. Даже проведя все возможные тесты, вы не сможете доказать, что продукт работает. Максимум, что вы сможете сказать: «В ходе проведенных тестов я не заметил, что продукт не работает». А вот обратная ситуация сулит большую экономию: всего одним-единственным тестом можно доказать, что продукт не работает.
Тестировщики фокусируются на отказах, поскольку это повышает шансы обнаружить их. Ищите ключевые проблемы в продукте, используя все свои творческие способности и навыки. Если вы их не найдете, то их нельзя будет исправить, и тогда пользователи могут обнаружить их за вас. Находя все возможные ошибки в продукте, вы помогаете членам команды проекта больше узнать об их навыках и рисках продукта, а также помогаете им улучшить продукт, сделать его более удобным для поддержки и, возможно, более успешным на рынке.
Урок 9. Вы никогда не найдете все баги в продукте
Ваша работа — искать значимые баги и сообщать о них. Но вы никогда не найдете все. Чтобы найти их все, вам придется искать баг везде, где он может быть, рассматривая каждую потенциально возможную ситуацию. Кроме того, вам понадобится надежный способ идентифицировать каждый тип возникшего бага. Если вы думаете, что можете это сделать, то у вас или очень простой продукт, или очень ограниченное воображение.
Вы должны выбрать, на что тратить свое время, зная, что не сможете сделать все.
Урок 10. Опасайтесь «завершенного» тестирования
Некоторые тестировщики соглашаются, что не могут знать наверняка, нашли ли они все баги в продукте, и тем не менее говорят о том, что означает «закончить тестирование». Слова «мне потребуется пять дней, чтобы протестировать это» можно интерпретировать так: вы считаете, что полностью протестируете эту часть продукта за пять календарных дней. А это, в свою очередь, может быть воспринято как то, что за пять дней вы найдете все баги. Завершенность чаще подразумевается, чем утверждается. В любом случае к этой концепции нужно относиться с большой осторожностью. Подумайте, что может означать завершенное тестирование, что именно завершено:
• поиск багов в продукте;
• изучение каждой части продукта;
• тестирование, которое, по вашему мнению, полезно и экономически выгодно на данный момент;
• выполнение целей проекта, которых вы достигали в меру своих способностей;
• выполнение согласованных тестов;
• проверка всего, что под силу протестировать человеку при данных обстоятельствах;
• все, что вы знали, как делать;
• ваша часть тестирования, вне зависимости от каких-либо других частей;
• широкое, но не глубокое тестирование продукта;
• один вид тестирования продукта;
• период времени, отведенный на тестирование.
Если вы позаботитесь о том, чтобы уточнить, что именно подразумеваете под словами «завершено», «закончено» или «сделано», вероятность того, что вас будут обвинять в плохом выполнении своей работы, уменьшится. А если все же обвинят, то вы сможете лучше защитить себя. Имейте в виду, что понятие «завершенность» невозможно окончательно определить в начале проекта. Вам придется пересматривать его по мере развития тестового проекта и появления новых тестовых задач.
Чтобы не было недопонимания того, что значит завершенность, поделитесь с клиентами некоторыми подробностями процесса тестирования. Подведите итоги выполненного вами тестирования и объясните, почему оно имеет смысл, а также расскажите клиентам о других заслуживающих внимания тестах, которые вы не проводите, и о том, почему вы их не проводите.
