10 Тестирование программного обеспечения

Эта книга — о тестировании в условиях, когда те, с кем вы работаете, не следуют, не хотят и не должны следовать правилам.

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

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

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

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

Как часто приходится отказываться ог внесения в программу полезных дополнительных возможностей из-за нехватки времени. И часто первая рабочая версия фрагмента, которую никак нельзя назвать профессиональ­ной, остается последней, поскольку переписывать ее некогда. Бывает, что программист “втихаря” по собственной инициативе все же выполнит нуж­ную работу и без предупреждения внесет в проект значительные измене­ния. Такая работа делается не по обязанности, сверх положенных 40 часов в неделю. Она может значительно улучшить проект, а может и серьезно его дестабилизировать на некоторое время. Но каким бы ни был результат, личная инициатива всегда направлена на улучшение проекта.

Изменения в конце разработки есть всегда, и они нужны. Главное — справиться с ними с минимумом потерь. Не стоит разводить бюрократию,

Предисловие 11

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

Для кого предназначена эта книга

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

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

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

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

12 Тестирование программного обеспечения

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

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

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

Программное обеспечение, к которому предъявляются повышенные требования по надежности

При создании определенных типов программного обеспечения отступ­ление программистов и управляющего персонала от стандартизированной методологии абсолютно недопустимо. Например, программы, управляющие ядерным реактором, должны быть специфицированы и документированы самым тщательным образом. И в случае их сбоя отчеты о тестировании становятся юридическими документами. Для тестирования таких проектов выделяются огромные средства и этим занимаются очень большие группы специалистов, называемые группами гарантии качества (Quality Assurance). Для обучения сотрудников таких групп больше подойдут другие книги — строго академического характера.

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

Предисловие 13

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

Можно ли назвать эту книгу учебником?

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

Организациями Association for Computing Machinery (Ассоциация вы­числительной техники) и IEEE Computer Society (Компьютерное сообще­ство IEEE) недавно был опубликован документ Computing Curricula 1991 (рекомендованный учебный план компьютерных факультетов), который в значительной степени определит содержание университетских учебных программ в области компьютерных наук на все следующее десятилетие. Время, отводимое на изучение технологий тестирования, обычно составляет несколько часов на четырехгодичный курс. В документе Computing Curricula предлагается ввести необязательный курс под названием Advanced Software Engineering (Продвинутый курс разработки программного обеспечения), вклю­чающий среди прочих и темы тестирования, но идеи о специальном кур­се тестирования в этом руководстве нет.

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

Но почему бы этот пробел не заполнить колледжам? Associate of Sciences (Ассоциация наук), у которой есть несколько курсов по тестиро­ванию, дополненных вводным курсом программирования и управления проектами, вполне могла бы с этим справиться. К тому же стартовая зара­ботная плата специалистов по тестированию достаточно высока. Так что, по нашему мнению, колледжам стоит подумать о подготовке таких специ­алистов — это дело как раз для них.

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

Тестирование программного обеспечения

Структура книги и принятые в ней соглашения

Сначала несколько замечаний о структуре книги

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

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