Написать эссе на тему конкретного метода тестирования (с примерами) или конкретной системы отслеживания ошибок.
Методические указания
Эссе (от фр. essai ‘попытка, проба, очерк’) – небольшой прозаический текст-рассуждение, выражающий точку зрения автора по какому-то вопросу.
Цель эссе – изложить собственное видение какого-либо вопроса (в данном случае – метода тестирования или багтрекинговой системы). Хорошее эссе отражает индивидуальность автора, в нём содержатся оригинальные мысли, оно обязательно заканчивается авторскими выводами. В списке использованной литературы должно быть не менее 5-и источников. Средний объем эссе – 20000 знаков с пробелами.
•0 От надежного функционирования определенных типов программного обеспечения может зависеть успех бизнеса - работы финансовых или промышленных компаний - или даже человеческая жизнь. Поэтому на его самое тщательное проектирование, разработку и тестирование не жалеют ни времени, ни денег.
•1 Сверхнадежное программное обеспечение можно сравнить с "Роллсройсом" - роскошно, но дорого.
•2 Однако не все программное обеспечение таково, и дело не только в его цене. Тестирование программных продуктов для среднего бизнеса, академических учреждений и личного пользования проводится в более сжатые сроки и скромнее оплачивается, но их качество вполне удовлетворяет требованиям рынка - это полезные и надежные программы, многими из которых производители могут заслуженно гордиться.
Литература
•3 С. Канер, Д. Фолк, Е. Нгуен. Тестирование программного обеспечения. — К.: Диасофт, 2000. — 544 с.
•4 Г. Майерс. Искусство тестирования программ. — М.: «Финансы и статистика», 1982. — 176 с.
•5 Андон Ф.И., Коваль Г.И., Коротун Т.М., Лаврищева Е.М., Суслов В.Ю. Основы инженерии качества программных систем. 2-е изд., перераб. и доп. - К.: Академпериодика, 2007. – 672 с.
•6 Г. Майерс. Надежность программного обеспечения. — М.: «Мир», 1980. — 360 с.
•7 С. Макконнелл. Совершенный код. — СПб: «Питер», 2005. — 896 с.
•8 Б. Бейзер. Тестирование черного ящика. — СПб: «Питер», 2005. — 318 с.
•9 Л. Тамре. Введение в тестирование программного обеcпечения — M.: «Вильямс», 2003. — 368 с.
Литература
•10 Э. Брауде. Технология разработки программного обеспечения. — СПб: «Питер», 2004. — 655 с.
•11 С. Орлов. Технологии разработки программного обеспечения. — СПб: «Питер», 2003. — 480 с.
•12 И. Винниченко. Автоматизация процессов тестирования. — СПб: «Питер», 2005. — 203 с.
•13 К. Бек. Экстремальное программирование. — СПб: «Питер», 2002.
•14 К. Ауэр, Р. Миллер. Экстремальное программирование. — СПб: «Питер», 2003. — 368 с.
•15 Д. Бентли. Жемчужины программирования. — СПб: «Питер», 2002. — 272 с.
•16 С. Бобровский. Технологии Пентагона на службе российских программистов. — СПб: «Питер», 2003. — 222 с.
•17 А. Якобсон, Г. Буч, Д. Рамбо. Унифицированный процесс разработки программного обеспечения. — СПб: «Питер», 2002. — 496 с.
•18 Р. Мартин. Чистый код: создание, анализ и рефакторинг. — СПб: «Питер», 2010. — 464 с.
Тема 1. Основы тестирования
•19 Основные понятия в области тестирования.
•20 Цели тестирования и его место в жизненном цикле ПО.
•21 Виды тестирования.
•22 Связь тестирования с другими видами деятельности. Социальные аспекты деятельности тестировщика.
1.1. SWEBOK (Software Engineering Body of Knowledge) — документ, подготавливаемый сообществом IEEE Computer Society. Назначение SWEBOK — в объединении знаний по разработке программного обеспечения. Он призван обеспечить следующее:
•23 определить необходимый набор знаний и рекомендуемые практики;
•24 определить этические и профессиональные стандарты;
•25 определить учебную программу для студентов, аспирантов и продолжающих обучение.
Документ SWEBOK2004 посвящён составлению учебного плана по программной инженерии - разработке ПО.
Документ делит знания по программной инженерии на 10 областей знаний (Knowledge Areas):
•26 Software Requirements — требования к ПО.
•27 Software Design — проектирование ПО.
•28 Software Construction — конструирование ПО.
•29 Software Testing — тестирование ПО.
•30 Software Maintenance — сопровождение ПО.
•31 Software Configuration Management — управление конфигурацией.
•32 Software Engineering Management — управление IT проектом.
•33 Software Engineering Process — процесс программной инженерии.
•34 Software Engineering Tools and Methods — методы и инструменты.
•35 Software Quality — качество ПО.
В SWEBOK 2004 область знаний «Тестирование ПО» представлена пятью основными разделами
1.2. Тестирование ПО
Термин testing (тестирование) широко используется в литературе, но определяется по-разному.
Стандарт ANSI/IEEE Std. 610.12:1990 определяет термин testing в самом его широком смысле как любое действие по анализу ПО (включая методы как динамической, так и статической проверки).
Г. Майерс определяет этот термин в самом узком смысле: «тестирование – процесс выполнения программы (или ее части) с целью обнаружения ошибок… Отладка (debugging) – диагностирование точной природы известных ошибок и их исправление».
«Исторические» периоды,
отражающие прогресс в понимании целей тестирования и его места в жизненном цикле ПС:
1) период до 1956 года - ориентация на отладку;
2) период с 1957 по 1978 гг. - ориентация на установление соответствия ПO исходным требованиям;
3) период с 1979 по 1982 гг. – ориентация на обнаружение дефектов, оставшихся после реализации ПО;
4) период с 1983 по 1987 гг. – ориентация на анализ, проверку и тестирование с целью оценки качества ПO на всех стадиях разработки;
5) период с 1988 по 1995 гг. – интеграция действий по проверке и тестированию в жизненный цикл ПO с целью предотвращения появления дефектов на всех стадиях разработки.
6) В настоящее время произошла интеграция тестирования с процессами разработки, и сегодня тестирование рассматривается как непрерывная деятельность, выполняемая на протяжении всего процесса разработки. Планирование тестирования должно начинаться на стадии анализа требований, а планы и процедуры тестирования должны систематически и постоянно уточняться по мере разработки ПО.
1.3. Тестирование программы заключается в динамической проверке поведения программы на конечном множестве тестовых данных, специальным образом выбранных из бесконечного входного пространства, на соответствие установленному ожидаемому поведению.
•36 динамическое: тестирование всегда предполагает выполнение программы;
•37 конечное: даже для небольшой программы теоретически возможно создать такое количество тестов, для выполнения которых могут понадобиться годы. Тестирование всегда предполагает некий компромисс между ограниченными сроками и потенциально неограниченным количеством тестов.
•38 выбранных: с проблемой адекватности тестирования связана проблема выбора ограниченного множества тестов. Методы тестирования, в основном, отличаются подходами к выбору множества тестовых данных из входного пространства;
•39 ожидаемое поведение: нужно уметь определять, правильны ли полученные результаты выполнения программы, соответствует ли наблюдаемое выполнение ожиданиям пользователя или спецификациям –так называемая проблема оракула (эталона).
1.3. Объекты тестирования
Основная цель тестирования – обнаружить дефекты ПО и установить его функциональную пригодность, но возможно рассматривать и другие его цели и, соответственно, объекты. Тестировать можно:
•40 работу программы;
•41 качество ее кода и понятность комментариев;
•42 быстродействие;
•43 устойчивость под большой нагрузкой;
•44 расход ресурсов (памяти, диска, потери этих ресурсов);
•45 взаимодействие с другими программами;
•46 стабильность работы;
•47 возможность работы на других платформах;
•48 удобство интерфейса;
•49 документацию на ПО (смысловые и грамматические ошибки, понятность и полноту);
•50 работу через сеть, работу аппаратного обеспечения и т.п.
1.4. 2 основных подхода к выполнению тестирования:
•51 Деструктивный (отрицательное, разрушительное тестирование). При этом тесты выбираются с целью обнаружения дефектов, и эффективным считается тест с высокой вероятностью их обнаружения.
•52 Конструктивный (положительное или демонстрационное тестирование) - тесты выбираются для демонстрации соответствия характеристик ПО установленным требованиям пользователя или целям качества.
2.1. Основные этапы жизненного цикла ПО
•53 Спецификация требований
(Оценка реального объема проекта, его целей и задач)
•54 Анализ
(исследование бизнес-процессов)
•55 Проектирование
(формирование модели данных)
•56 Реализация
•57 Тестирование
•58 Внедрение
•59 Эксплуатация и техподдержка
Классические модели жизненного цикла ПО
•60 Каскадная модель
•61 Спиральная модель
Каскадная модель
Каскадная с обратной связью
Спиральная модель
Согласно современному подходу
Тестирование – основной процесс в ЖЦ, выполняемый всегда, для всех объектов ПО системы независимо от ее критичности.
Тестирование ПО тесно связано с отладкой и собственно программированием, но охватывает гораздо более широкий круг проблем и участников – программистов, тестировщиков, аналитиков и инженеров по качеству.
2.2.Типы тестирования по этапам жизненного цикла:
•62 Юнит тестирование – тестирование базовых функциональных элементов
•63 Интеграционное тестирование – тестирование сборки целостного решения из отдельных компонентов
•64 Системное тестирование – тестирование программного продукта как единого целого
•65 Приемо-сдаточные испытания – тестирование совместно с заказчиком
•66 Альфа-тестирование
использование незавершённой (альфа) версии продукта, в которой реализована не вся функциональность, запланированная для данной версии продукта, штатными разработчиками и тестерами с целью выявления ошибок в работе реализованных модулей и функций для их последующего устранения перед бета-тестированием.
•67 Бета-тестирование
интенсивное использование почти готовой версии продукта с целью выявления максимального числа ошибок в его работе для их последующего устранения перед окончательным выходом (релизом) продукта на рынок, к массовому потребителю. К бета-тестированию часто привлекаются добровольцы из числа будущих пользователей
2.3. Советы практика
http://ko.com.ua/testirovanie_po_s_chego_nachat_22452
•68 Если в организации появляется первый тестировщик, он пойти двумя путями.
•69 Первый - просто «нажимать кнопки». Естественно, при работе таким способом «ошибки» у тестировщика быстро заканчиваются, а у пользователей – остаются, что приводит к обвинению его в непрофессионализме.
•70 Второй путь – организовать работу более эффективно. Можно исходить из определения:
«основная цель тестирования – убедиться, что система делает то, что нужно, и не делает того, что не нужно».
Первоочередная задача тестера – разработать как можно более полную систему тестов и при этом сделать все, чтобы на следующий раз не забыть, что же он делал, что нашел и как исправление этого найденного проверить.
Следует собрать и изучить все должностные инструкции (если их нет – разработать), стандарты предприятия и прочую документацию. В идеале цель – заставить общаться отдел тестирования с остальным миром только посредством документов.
Первоочередные задачи
•71 круг своих обязанностей в организации необходимо конкретизировать (чаще всего, кстати, это означает «сузить») и закрепить;
•72 нужны документированные требования к системе, ведь чем детальнее проработан их список, тем легче производить тестирование;
•73 найденные дефекты обязательно регистрировать, причем так, чтобы потом можно было отследить их жизненный цикл;
•74 результаты тестирования должны храниться в форме, удобной для поиска и анализа;
•75 ни в коем случае нельзя начинать сразу с автоматизации тестирования: она подходит при уже существующем и налаженном процессе, а на первом этапе не даст ничего, кроме материальных и временных потерь.
Минимальный набор документов:
•76 план тестирования (test plan) – документ, содержащий краткую информацию о самой системе, силах и средствах, которыми предполагается ее тестировать, о том, что именно вы собираетесь подвергнуть проверке (вплоть до списков или даже описаний тестов), примерные планы по срокам, критерии окончания работы и признания релиза успешным, риски и прочие сведения, могущие оказать влияние на процесс тестирования.
•77 контрольный пример (test case) – документ с описанием конкретного теста. Основное требование к контрольному примеру – описание проверки четко определенной самостоятельной части функциональности (или свойств) программного обеспечения и ожидаемых результатов;
•78 таблицу контроля (check-list, он же suite, или набор). Это документ, объединяющий в себе (через гиперссылки) набор контрольных примеров с отметками о результате их исполнения и примечаниями;
•79 отчет о тестировании (test results) – результирующий документ, содержащий ссылки на таблицы контроля и выводы о работоспособности релиза с подписями тестера и руководителя отдела.
На каждую сборку создаются все указанные документы, кроме плана.
•80 Ну и, конечно, нужно ознакомиться с теорией. Не полениться выделить неделю на чтение книг и интернет-форумов, посвященных тестированию, хотя после них остается ощущение полной пустоты в голове и чувство собственной неполноценности, пока не придешь к мысли, что теорию следует применять, руководствуясь здравым смыслом. Поэтому не стоит и пытаться полностью приспособить к себе теорию, которую использует гигант с многотысячным персоналом и миллиардным бюджетом. Нужно выбрать оттуда только полезное для вас, отбрасывая или упрощая то, что, по вашему мнению и здравому смыслу, будет только отнимать время.
Организация хранилища данных и версионность
Для начала подход достаточно простой. Где-то на файл-сервере формируется общий ресурс, в котором создаются папки на каждый проект. Каждая такая папка содержит следующие элементы:
•81 файл с тест-планом;
•82 файл с шаблоном отчета о тестировании;
•83 каталог TestCase с набором контрольных примеров по конкретному проекту;
•84 каталог Builds, в котором в отдельных папках хранятся отработанные контрольные примеры по данной сборке (практически, копия папки TestCase, документы из которой используются в качестве шаблонов) и отчет о тестировании.
Внедрение BTS (Bug Tracking System – системы регистрации и отслеживания жизненного цикла дефектов). Для начала это может быть даже Excel-файл с настроенными автофильтрами, но в идеале желательно сразу определиться с ПО, которое будет применено для автоматизированного тестирования, отслеживания ошибок, управления требованиями, документирования и пр. Причем на первом этапе в качестве рабочей БД лучше выбирать Access в связи с легкостью преобразования данных из нее во что угодно при последующей смене управляющего ПО.
BTS сначала встречает неприятие у программистов, но уже очень скоро они не могут без нее работать. Одним из достоинств подобных систем является формализация общения между отделами и исключение недоразумений в вопросах ответственности, а для менеджеров – возможность объективно оценивать уровень квалификации и вклад в общее дело своих сотрудников.
Таким образом, для первичной организации тестирования необходимо, образно выражаясь, выполнить условия трех «Ф», которые заключаются в следующем:
•85 Формализации обязанностей – написании должностных инструкций и положения про отдел;
•86 Формализации общения с программистами – внедрении BTS;
•87 Формализации работы тестеров – создании контрольных примеров, планировании и получении отчета о тестировании.
Стоимость ошибки
3.1.Главный закон контроля качества ПО -- повышение качества системы снижает расходы на ее разработку.
С т. зрения управления качеством, тестирование - это
одна из техник контроля качества, включающая в себя
активности по планированию работ, проектированию
тестов, выполнению тестирования и анализу полученных результатов.
Что такое качество?
Термин неясен и неоднозначен, в связи с тем, что:
Понятие качества весьма неопределенно, что может объясняться пакетностью самого исходного понятия - один и тот же термин обозначает целое семейство, или пакет, в каком-то отношении сходных понятий, разграничить которые по чисто формальным, структурным характеристикам, как правило, невозможно. В этой связи трактовки понятия качества сильно разнятся, и можно выделить следующие:
•88 Качество как превосходство.
•89 Качество как соответствие эталону.
•90 Качество как услуга, как соответствие запросам потребителей.
•91 Качество как идеал, как непрерывный поиск совершенства.
3.2. Критерии качества ПО
Внешние характеристики:
•92 корректность - наличие/отсутствие дефектов в спецификации, проекте и реализации;
•93 практичность - легкость изучения и использования;
•94 эффективность - степень использования системных ресурсов;
•95 надежность - способность системы выполнять необходимые функции;
•96 целостность - способность предотвращать неавторизованный или некорректный доступ;
•97 адаптируемость - возможность использования в других областях и средах;
•98 правильность - степень безошибочности данных, выдаваемых системой;
•99 интервал между отказами;
•100 живучесть - способность продолжать работу при недопустимых данных или в напряженных условиях и др.
Критерии качества ПО
Внутренние характеристики
•101 удобство сопровождения;
•102 тестируемость;
•103 удобочитаемость;
•104 гибкость;
•105 портируемость;
•106 возможность повторного использования;
•107 понятность
•108 и др.
3.3.Требования к тестировщику
(подборка из описания вакансий)
•109 Деструктивное мышление
•110 Умение точно описывать конфигурацию системы
•111 Умение четко документировать результаты
•112 Способность (психологическая) приносить плохие вести
•113 Стрессоустойчивость
•114 Гибкость мышления
•115 Способность одновременно видеть и всю картину, и детали
•116 Экспертные знания в различных областях (помимо тестирования)
•117 Умение программировать
•118 Умение быстро обучаться и осваивать новые программы и инструменты
•119 Терпение
Требования к тестировщику
(американский вариант)
•120 Обеспечение постоянной обратной связи
•121 Принесение пользы заказчику
•122 Готовность к личным контактам
•123 Смелость
•124 Простота
•125 Постоянное совершенствование практики
•126 Реакция на изменения
•127 Самоорганизация
•128 Ориентация на людей
•129 Удовольствие
•130 Обязательное ведение базы знаний
Мифы о работе тестировщика
•131 Менее квалифицированная работа, чем разработчик
•132 Стартовая позиция прежде чем приступать к программированию
•133 Работа скучная, рутинная. У программиста более творческая и интересная
•134 У команды разработчиков имеется определенное видение будущего продукта, горячее желание осуществить задуманное и понимание того, что во многом работа будет делаться методом проб и ошибок. К тому времени, когда каждый аспект разработки прорисуется до деталей, будет сформирована рабочая версия проекта, которую смогут понять и охватить целиком один-два ведущих специалиста. Эта версия и называется спецификацией. Спецификация не выгравирована на камне: позднее она не раз еще будет пересматриваться и усовершенствоваться.
•135 В реальной жизни изменения вносятся в продукт даже в самом конце разработки. Если, например, программа разрабатывается на продажу, ваши пользователи - потенциальные пользователи - ни на какую спецификацию не соглашались. И если конкурент создает нечто более привлекательное…
•136 Изменения в конце разработки есть всегда, и они нужны. Главное - справиться с ними с минимумом потерь. Не стоит разводить бюрократию, пытаясь запретить такие изменения. Профессионализм сотрудников группы тестирования заключается в том, чтобы принять реальность такой, как она есть, не жалуясь и не пытаясь бороться с ней запретами, и успешно закончить тестирование продукта вместе с внесенными изменениями.
•137 Бывает, что при тестировании программного продукта приходится иметь дело с ошибками, допущенными еще на стадии проектирования. Программа может в точности соответствовать спецификации, но, если спецификация содержит ошибки, такая программа, увы, для работы не годится.
•138 Часто в литературе, посвященной вопросам надежности программного обеспечения и методикам его тестирования, совсем не уделяется внимания пользовательскому интерфейсу программ. Ее авторы считают, что этим вопросом должен заниматься специалист по анализу человеческого фактора. Мы же с этим абсолютно не согласны. Ведь надежность системы зависит от того, насколько хорошо работают вместе все ее составляющие, включая и людей, которые используют программу.
Задача специалиста по тестированию - выявить все проблемы, которые могут возникнуть при работе с продуктом, и сделать все возможное для улучшения его качества. Помните, что тестируется не просто программу, а система человек-компьютер, и отчеты о ненадежности или неэффективности взаимодействия между человеком и компьютером не менее важны, чем остальные. Тестировщик - один из немногих специалистов, анализирующих продукт во всех деталях, причем, как правило непосредственно перед его предоставлением пользователю.
