Книги: [Классика] [Базы данных] [Internet/WWW] [Сети] [Программирование] [UNIX] [Windows] [Безопасность] [Графика] [Software Engineering] [ERP-системы] [Hardware]
Предисловие
Тестирование программного обеспечения - это книга, написанная профессионалами для профессионалов. Что такое тестирование потребительских и деловых программ в условиях, приближенных к боевым, мы знаем не понаслышке, поскольку выполняли эту работу для самых известных производителей программного обеспечения Кремниевой Долины. Лежащее перед вами руководство разрабатывалось для наших собственных сотрудников.
О том, как тестировать программные продукты, от которых требуется повышенная надежность, написано немало хороших книг. От надежного функционирования определенных типов программного обеспечения может зависеть успех бизнеса - работы финансовых или промышленных компаний - или даже человеческая жизнь. Поэтому на его самое тщательное проектирование, разработку и тестирование не жалеют ни времени, ни денег. Сотрудникам тестовых групп предоставляется полный доступ к исходному коду программ, причем на столько времени, сколько потребуется для его подробного изучения.
Сверхнадежное программное обеспечение можно сравнить с "Роллсройсом" - роскошно, но дорого. Однако не все программное обеспечение таково, и дело не только в его цене. Тестирование программных продуктов для среднего бизнеса, академических учреждений и личного пользования проводится в более сжатые сроки и скромнее оплачивается, но их качество вполне удовлетворяет требованиям рынка - это полезные и надежные программы, многими из которых производители могут заслуженно гордиться.
Так как же организовать тестирование программных продуктов, чтобы его результаты можно было назвать сверхнадежными? И как удается группам тестирования обычного потребительского ПО в условиях сжатых сроков, малочисленной команды и ограниченных средств выпускать прекрасные и вполне конкурентоспособные продукты? Обо всем этом вы узнаете из книги Тестирование программного обеспечения.
Чего в этой книге нет
Часто авторы книг утверждают, что для успешного тестирования необходимо, чтобы все было по правилам: документация, включающая необходимые для разработки спецификации была полной и своевременной, при проектировании и написании кода применялась правильная и самая современная методология и т.д.
На деле при разработке программного обеспечения бюджет всегда слишком мал, сотрудников не хватает, согласия между ними для выработки единой линии добиться трудно, а работа при этом должна быть выполнена "на вчера".
Качество большого продукта зависит от работы каждого, кто его проектирует, программирует, тестирует и документирует. Никакие стандарты и спецификации, никакой контроль и отслеживание изменений не гарантируют качества продукции. Все зависит только от людей - их работоспособности, мастерства и умения работать в команде. Только это определяет результат, а никак не правила.
У команды разработчиков имеется определенное видение будущего продукта, горячее желание осуществить задуманное и понимание того, что во многом работа будет делаться методом проб и ошибок. К тому времени, когда каждый аспект разработки прорисуется до деталей, будет сформирована рабочая версия проекта, которую смогут понять и охватить целиком один-два ведущих специалиста. Эта версия и называется спецификацией. Спецификация не выгравирована на камне: позднее она не раз еще будет пересматриваться и усовершенствоваться, пока не будет достигнута полная согласованность со всей системой. И выполняя тестирование, вы тоже примете участие в этой работе.
В реальной жизни изменения вносятся в продукт даже в самом конце разработки. Если, например, программа разрабатывается на продажу, ваши пользователи - потенциальные пользователи - ни на какую спецификацию не соглашались. И если конкурент создает нечто более привлекательное, отвечать приходится быстро.
Как часто приходится отказываться от внесения в программу полезных дополнительных возможностей из-за нехватки времени. И часто первая рабочая версия фрагмента, которую никак нельзя назвать профессиональной, остается последней, поскольку переписывать ее некогда. Бывает, что программист "втихаря" по собственной инициативе все же выполнит нужную работу и без предупреждения внесет в проект значительные изменения. Такая работа делается не по обязанности, сверх положенных 40 часов в неделю. Она может значительно улучшить проект, а может и серьезно его дестабилизировать на некоторое время. Но каким бы ни был результат, личная инициатива всегда направлена на улучшение проекта.
Изменения в конце разработки есть всегда, и они нужны. Главное - справиться с ними с минимумом потерь. Не стоит разводить бюрократию, пытаясь запретить такие изменения. Профессионализм сотрудников группы тестирования заключается в том, чтобы принять реальность такой, как она есть, не жалуясь и не пытаясь бороться с ней запретами, и успешно закончить тестирование продукта вместе с внесенными изменениями.
Для кого предназначена эта книга
Эта книга предназначена для того, кто выполняет тестирование программного кода, обычно написанного кем-то другим. В ней обсуждаются вопросы и решения, которые на наш взгляд интересны и полезны такому человеку. Поэтому рассказ наш не академичен, в нем не затрагиваются такие классические темы, как доказательства правильности программного кода. Мы постарались больше уделить внимания темам, не характерным для учебников, как, например, межличностные взаимоотношения и корпоративная политика. Судить о работе других людей приходится даже начинающему тестировщику - в этом суть тестирования. За высказывание своих суждений тестировщики нередко подвергаются нападкам со стороны разработчиков. (Бывает, что и заслуженно.) Поскольку группа тестирования работает с программой последней и ее результаты у всех на виду, ее ответственность всегда оказывается больше возможностей - положение политически самое невыгодное. Решения этой проблемы у нас нет. Однако мы готовы поделиться своим опытом в том, как повысить эффективность работы и избежать некоторых неприятных моментов и ошибок.
Поговорим мы также и об управлении проектом. Оценка, планирование и составление календарного плана работ по тестированию программного продукта - задача не из легких, ведь конечная точка фактически не определена. Всегда остаются тесты, которые еще полезно было бы провести, и риск, связанный с отказом от их выполнения. Специалист по тестированию должен это хорошо понимать и принимать во внимание при планировании работ. Например, можно отложить важный тест, чтобы в совершенстве выполнить другую часть работы, а потом обнаружить, что времени на отложенный тест уже нет. В результате, пытаясь выполнить работу лучше, вы на самом деле сделаете ее хуже. К сожалению, ситуация эта очень типична. Поэтому в нашей книге много внимания уделено вопросам эффективности и правильной расстановки приоритетов.
Бывает, что при тестировании программного продукта приходится иметь дело с ошибками, допущенными еще на стадии проектирования. Программа может в точности соответствовать спецификации, но, если спецификация содержит ошибки, такая программа, увы, для работы не годится.
Часто в литературе, посвященной вопросам надежности программного обеспечения и методикам его тестирования, совсем не уделяется внимания пользовательскому интерфейсу программ. Ее авторы считают, что этим вопросом должен заниматься специалист по анализу человеческого фактора. Мы же с этим абсолютно не согласны. (И даже имеющийся в нашем коллективе специалист по анализу человеческого фактора с этим не согласен.) Ведь надежность системы зависит от того, насколько хорошо работаю вместе все ее составляющие, включая и людей, которые используют программу.
Задача специалиста по тестированию - выявить все проблемы, которые могут возникнуть при работе с продуктом, и сделать все возможное для улучшения его качества. Помните, что вы тестируете не просто программу, вы тестируете систему человек-компьютер, и отчеты о ненадежности или неэффективности взаимодействия между человеком и компьютером не менее важны, чем остальные. Вы один из немногих специалистов, анализирующих продукт во всех деталях, причем непосредственно перед его предоставлением пользователю. И поэтому кто же, как не вы, сможет выявить и устранить подобные проблемы. I
Прочитав разделы нашей книги, посвященные пользовательскому интерфейсу, вы не станете в этом вопросе специалистом - книга не претендует на абсолютную полноту освещения этой темы. Может быть, некоторые из ваших предложений будут неверны. Но все же предоставьте отчеты и на тему интерфейса. Они очень важны. И некоторые из них обязательно помогут улучшить конечный продукт.
Программное обеспечение, к которому предъявляются повышенные требования по надежности
При создании определенных типов программного обеспечения отступление программистов и управляющего персонала от стандартизированной методологии абсолютно недопустимо. Например, программы, управляющие ядерным реактором, должны быть специфицированы и документированы самым тщательным образом. И в случае их сбоя отчеты о тестировании становятся юридическими документами. Для тестирования таких проектов выделяются огромные средства и этим занимаются очень большие группы специалистов, называемые группами гарантии качества (Quality Assurance). Для обучения сотрудников таких групп больше подойдут другие книги - строго академического характера.
Но даже на таких проектах в конце работы часто подключаются группы приемки, бюджеты которых мизерны, а сроки предельно коротки. Сотрудники таких групп не участвуют в разработке и часто из-за недостатка времени не могут понастоящему серьезно протестировать продукт. Если вы работаете именно в таких условиях, эта книга будет для вас полезнее, чем традиционные учебники.
Можно ли назвать эту книгу учебником?
Мы принимали на работу множество специалистов по тестированию, но еще ни разу не встречали выпускника компьютерного факультета, который узнал бы что-нибудь полезное о тестировании из университетского курса.
Организациями Association for Computing Machinery (Ассоциация вычислительной техники) и IEEE Computer Society (Компьютерное сообщество IEEE) недавно был опубликован документ Computing Curricula 1991 (рекомендованный учебный план компьютерных факультетов), который в значительной степени определит содержание университетских учебных программ в области компьютерных наук на все следующее десятилетие. Время, отводимое на изучение технологий тестирования, обычно составляет несколько часов на четырехгодичный курс. В документе Computing Curricula предлагается ввести необязательный курс под названием Advanced Software Engineering (Продвинутый курс разработки программного обеспечения), включающий среди прочих и темы тестирования, но идеи о специальном курсе тестирования в этом руководстве нет.
Итак, не похоже, что в ближайшие десять лет выпускники компьютерных факультетов университетов будут хоть что-нибудь знать о тестировании программных продуктов.
Но почему бы этот пробел не заполнить колледжам? Associate of Sciences (Ассоциация наук), у которой есть несколько курсов по тестированию, дополненных вводным курсом программирования и управления проектами, вполне могла бы с этим справиться. К тому же стартовая заработная плата специалистов по тестированию достаточно высока. Так что, по нашему мнению, колледжам стоит подумать о подготовке таких специалистов - это дело как раз для них.
Работая над последним изданием этой книги, мы внесли в нее много дополнений, рассчитанных именно на студентов колледжей - тех, которым никогда не приходилось бывать с тестовых лабораториях. Надеемся также, что книга будет полезна тем колледжам, которые захотят включить в свои программы курс тестирования делового программного обеспечения.
Начало
Полное содержание
Об авторах
Заказать книгу в магазине "Мистраль"
🔥 VPS до 5.7 ГГц под любые задачи с AntiDDoS в 7 локациях
Виртуальные VPS серверы в РФ и ЕС
