Тестирование приложений. Обеспечения Базовый курс (3е издание) Версия книги 15 от 31. 03. 2022
 Скачать 5.07 Mb.
|
|
Вкратце можно выразить суть моделей разработки ПО таблицей 2.1.a. Таблица 2.1.a — Сравнение моделей разработки ПО Модель Преимущества Недостатки Тестирование Водопадная • У каждой стадии есть чёткий прове- ряемый результат. • В каждый момент времени команда выполняет один вид работы. • Хорошо работает для небольших за- дач. • Полная неспособ- ность адаптировать проект к измене- ниям в требова- ниях. • Крайне позднее со- здание работаю- щего продукта. • С середины про- екта. V- образная • У каждой стадии есть чёткий прове- ряемый результат. • Внимание тестиро- ванию уделяется с первой же стадии. • Хорошо работает для проектов со стабильными тре- бованиями. • Недостаточная гиб- кость и адаптируе- мость. • Отсутствует раннее прототипирование. • Сложность устра- нения проблем, пропущенных на ранних стадиях развития проекта. • На переходах между стадиями. 38 «The Agile System Development Life Cycle» [ http://www.ambysoft.com/essays/agileLifecycle.html ] «Бэклог» проекта «Бэклог» спринта Спринт (до 4-х недель) Результат Итерация ( сутки) Модели разработки ПО Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 26/298 Итерационная инкре- ментальная • Достаточно раннее прототипирование. • Простота управле- ния итерациями. • Декомпозиция про- екта на управляе- мые итерации. • Недостаточная гиб- кость внутри итера- ций. • Сложность устра- нения проблем, пропущенных на ранних стадиях развития проекта. • В определённые моменты итераций. • Повторное тестиро- вание (после дора- ботки) уже прове- ренного ранее. Спиральная • Глубокий анализ рисков. • Подходит для круп- ных проектов. • Достаточно раннее прототипирование. • Высокие накладные расходы. • Сложность приме- нения для неболь- ших проектов. • Высокая зависи- мость успеха от ка- чества анализа рисков. Гибкая • Максимальное во- влечение заказ- чика. • Много работы с требованиями. • Тесная интеграция тестирования и разработки. • Минимизация доку- ментации. • Сложность реали- зации для больших проектов. • Сложность постро- ения стабильных процессов. • В определённые моменты итераций и в любой необхо- димый момент. Ещё два кратких и информативных сравнения моделей жизненного цикла ПО можно найти в статьях «Project Lifecycle Models: How They Differ and When to Use Them » 39 и «Блок-схема выбора оптимальной методологии разработки ПО» 40 А общий обзор всех моделей в контексте тестирования ПО представлен в статье «What are the Software Development Models?» 41 Задание 2.1.a: представьте, что на собеседовании вас попросили назвать основные модели разработки ПО, перечислить их преимущества и недо- статки с точки зрения тестирования. Не ждите собеседования, ответьте на этот вопрос сейчас, а ответ запишите. 39 «Project Lifecycle Models: How They Differ and When to Use Them» [ http://www.business-esolutions.com/islm.htm ] 40 «Блок-схема выбора оптимальной методологии разработки ПО» [ http://megamozg.ru/post/23022/ ] 41 «What are the Software Development Models?» [ http://istqbexamcertification.com/what-are-the-software-development-models/ ] Жизненный цикл тестирования Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 27/298 2.1.2. Жизненный цикл тестирования Следуя общей логике итеративности, превалирующей во всех современных моделях разработки ПО, жизненный цикл тестирования также выражается замкну- той последовательностью действий (рисунок 2.1.g). Важно понимать, что длина такой итерации (и, соответственно, степень по- дробности каждой стадии) может варьироваться в широчайшем диапазоне — от единиц часов до десятков месяцев. Как правило, если речь идёт о длительном про- межутке времени, он разбивается на множество относительно коротких итераций, но сам при этом «тяготеет» к той или иной стадии в каждый момент времени (напри- мер, в начале проекта больше планирования, в конце — больше отчётности). Также ещё раз подчеркнём, что приведённая схема — не догма, и вы легко можете найти альтернативы (например, здесь 42 и здесь 43 ), но общая суть и ключе- вые принципы остаются неизменными. Их и рассмотрим. Рисунок 2.1.g — Жизненный цикл тестирования Стадия 1 (общее планирование и анализ требований) объективно необхо- дима как минимум для того, чтобы иметь ответ на такие вопросы, как: что нам пред- стоит тестировать; как много будет работы; какие есть сложности; всё ли необхо- димое у нас есть и т.п. Как правило, получить ответы на эти вопросы невозможно без анализа требований, т.к. именно требования являются первичным источником ответов. Стадия 2 (уточнение критериев приёмки) позволяет сформулировать или уточнить метрики и признаки возможности или необходимости начала тестирова- ния (entry criteria 44 ) , приостановки (suspension criteria 45 ) и возобновления (resumption 42 «Software Testing Life Cycle» [ http://softwaretestingfundamentals.com/software-testing-life-cycle/ ] 43 «Software Testing Life Cycle» [ http://www.softwaretestingmentor.com/software-testing-life-cycle/ ] 44 Entry criteria. The set of generic and specific conditions for permitting a process to go forward with a defined task, e.g. test phase. The purpose of entry criteria is to prevent a task from starting which would entail more (wasted) effort compared to the effort needed to remove the failed entry criteria. [ISTQB Glossary] 45 Suspension criteria. The criteria used to (temporarily) stop all or a portion of the testing activities on the test items. [ISTQB Glossary] Общее планирование и анализ требований Уточнение критериев приёмки Уточнение стратегии тестирования Разработка тест-кейсов Выполнение тест- кейсов Фиксация найденных дефектов Анализ результатов тестирования Отчётность 1 2 3 4 5 6 7 8 Тестирование Жизненный цикл тестирования Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 28/298 criteria 46 ) тестирования, завершения или прекращения тестирования (exit criteria 47 ). Стадия 3 (уточнение стратегии тестирования) представляет собой ещё одно обращение к планированию, но уже на локальном уровне: рассматриваются и уточ- няются те части стратегии тестирования (test strategy 48 ) , которые актуальны для те- кущей итерации. Стадия 4 (разработка тест-кейсов) посвящена разработке, пересмотру, уточ- нению, доработке, переработке и прочим действиям с тест-кейсами, наборами тест- кейсов, тестовыми сценариями и иными артефактами, которые будут использо- ваться при непосредственном выполнении тестирования. Стадия 5 (выполнение тест-кейсов) и стадия 6 (фиксация найденных дефек- тов) тесно связаны между собой и фактически выполняются параллельно: дефекты фиксируются сразу по факту их обнаружения в процессе выполнения тест-кейсов. Однако зачастую после выполнения всех тест-кейсов и написания всех отчётов о найденных дефектах проводится явно выделенная стадия уточнения, на которой все отчёты о дефектах рассматриваются повторно с целью формирования единого понимания проблемы и уточнения таких характеристик дефекта, как важность и срочность. Стадия 7 (анализ результатов тестирования) и стадия 8 (отчётность) также тесно связаны между собой и выполняются практически параллельно. Формулиру- емые на стадии анализа результатов выводы напрямую зависят от плана тестиро- вания, критериев приёмки и уточнённой стратегии, полученных на стадиях 1, 2 и 3. Полученные выводы оформляются на стадии 8 и служат основой для стадий 1, 2 и 3 следующей итерации тестирования. Таким образом, цикл замыкается. В жизненном цикле тестирования пять из восьми стадий так или иначе свя- заны с управлением проектами, рассмотрение которого не входит в наши планы, а потому обо всём, что касается планирования и отчётности, мы кратко поговорим в главе «Оценка трудозатрат, планирование и отчётность» {205} . А сейчас мы перехо- дим к ключевым навыкам и основным видам деятельности тестировщиков и начнём с работы с документацией. 46 Resumption criteria. The criteria used to restart all or a portion of the testing activities that were suspended previously. [ISTQB Glossary] 47 Exit criteria. The set of generic and specific conditions, agreed upon with the stakeholders for permitting a process to be officially completed. The purpose of exit criteria is to prevent a task from being considered completed when there are still outstanding parts of the task which have not been finished. Exit criteria are used to report against and to plan when to stop testing. [ISTQB Glossary] 48 Test strategy. A high-level description of the test levels to be performed and the testing within those levels for an organization or program (one or more projects). [ISTQB Glossary] Тестирование документации и требований Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 29/298 2.2. Тестирование документации и требований 2.2.1. Что такое «требование» Как мы только что рассмотрели в главе, посвящённой жизненному циклу те- стирования, всё так или иначе начинается с документации и требований. Требование (requirement 49 ) — описание того, какие функции и с соблюде- нием каких условий должно выполнять приложение в процессе решения полезной для пользователя задачи. Небольшое «историческое отступление»: если поискать определения тре- бований в литературе 10-20-30-летней давности, то можно заметить, что изначально о пользователях, их задачах и полезных для них свойствах приложения в определении требования не было сказано. Пользователь выступал некоей абстрактной фигурой, не имеющей отношения к прило- жению. В настоящее время такой подход недопустим, т.к. он не только приводит к коммерческому провалу продукта на рынке, но и многократно повышает затраты на разработку и тестирование. Хорошим кратким предисловием ко всему тому, что будет рассмотрено в данной главе, можно считать небольшую статью «What is documentation testing in software testing » 50 49 Requirement. A condition or capability needed by a user to solve a problem or achieve an objective that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document. [ISTQB glossary] 50 «What is documentation testing in software testing». [ http://istqbexamcertification.com/what-is-documentation-testing/ ] Важность требований Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 30/298 2.2.2. Важность требований Требования являются отправной точкой для определения того, что проектная команда будет проектировать, реализовывать и тестировать. Элементарная логика говорит нам, что если в требованиях что-то «не то», то и реализовано будет «не то», т.е. колоссальная работа множества людей будет выполнена впустую. Эту мысль иллюстрирует рисунок 2.2.a. Брайан Хэнкс, описывая важность требований 51 , подчёркивает, что они: • Позволяют понять, что и с соблюдением каких условий система должна де- лать. • Предоставляют возможность оценить масштаб изменений и управлять изме- нениями. • Являются основой для формирования плана проекта (в том числе плана те- стирования). • Помогают предотвращать или разрешать конфликтные ситуации. • Упрощают расстановку приоритетов в наборе задач. • Позволяют объективно оценить степень прогресса в разработке проекта. Вне зависимости от того, какая модель разработки ПО используется на про- екте, чем позже будет обнаружена проблема, тем сложнее и дороже будет её ре- шение. А в самом начале («водопада», «спуска по букве v», «итерации», «витка спирали») идёт планирование и работа с требованиями. Если проблема в требованиях будет выяснена на этой стадии, её решение может свестись к исправлению пары слов в тексте, в то время как недоработка, вызванная пропущенной проблемой в требованиях и обнаруженная на стадии экс- плуатации, может даже полностью уничтожить проект. Рисунок 2.2.a — Стоимость исправления ошибки в зависимости от момента её об- наружения Если графики вас не убеждают, попробуем проиллюстрировать ту же мысль на простом примере. Допустим, вы с друзьями составляете список покупок перед поездкой в гипермаркет. Вы поедете покупать, а друзья ждут вас дома. Сколько 51 «Requirements in the Real World», Brian F. Hanks, February 28, 2002. Общее планирование Пользовательские требования Системные требования Техническая архитектура Детализированный дизайн Разработка и отладка Интеграция и модульные тесты Инсталляционное тестирование Системное тестирование Приёмочное тестирование Итоговая отчётность 0 20 500 1000 Эксплуатация Время, затраченное на проект Стоимость исправления ошибки Важность требований Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 31/298 «стоит» дописать, вычеркнуть или изменить пару пунктов, пока вы только-только составляете список? Нисколько. Если мысль о несовершенстве списка настигла вас по пути в гипермаркет, уже придётся звонить (дёшево, но не бесплатно). Если вы поняли, что в списке «что-то не то» в очереди на кассу, придётся возвращаться в торговый зал и тратить время. Если проблема выяснилась по пути домой или даже дома, придётся вернуться в гипермаркет. И, наконец, клинический случай: в списке изначально было что-то уж совсем неправильное (например, «100 кг конфет — и всё»), поездка совершена, все деньги потрачены, конфеты привезены и только тут выясняется, что «ну мы же пошутили». Задание 2.2.a: представьте, что ваш с друзьями бюджет ограничен, и в списке требований появляются приоритеты (что-то купить надо обяза- тельно, что-то, если останутся деньги, и т.п.). Как это повлияет на риски, связанные с ошибками в списке? Ещё одним аргументом в пользу тестирования требований является то, что, по разным оценкам, в них зарождается от ½ до ¾ всех проблем с программным обеспечением. В итоге есть риск, что получится так, как показано на рисунке 2.2.b. Поскольку мы постоянно говорим «документация и требования», а не просто «требования», то стоит рассмотреть перечень документации, которая должна под- вергаться тестированию в процессе разработки ПО (хотя далее мы будем концен- трироваться именно на требованиях). Рисунок 2.2.b — Типичный проект с плохими требованиями В общем случае документацию можно разделить на два больших вида в за- висимости от времени и места её использования (здесь будет очень много сносок Так клиент объяснил, чего он хочет Так клиента понял менеджер проекта Так аналитик описал проект Так программист реализовал проект Так проект был прорекламирован консультантами Так проект был задокументирован Так проект был сдан в эксплуатацию В такую сумму проект обошёлся заказчику Так работала техническая поддержка Что на самом деле было нужно клиенту Важность требований Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 32/298 с определениями, т.к. по видам документации очень часто возникает множество во- просов и потому придётся рассмотреть некоторые моменты подробнее). • Продуктная документация (product documentation, development documenta- tion 52 ) используется проектной командой во время разработки и поддержки продукта. Она включает: o План проекта (project management plan 53 ) и в том числе тестовый план (test plan 54 ). o Требования к программному продукту (product requirements document, PRD 55 ) и функциональные спецификации (functional specifications 56 doc- ument, FSD 57 ; software requirements specification, SRS 58 ). o Архитектуру и дизайн (architecture and design 59 ). o Тест-кейсы и наборы тест-кейсов (test cases 60 , test suites 61 ). o Технические спецификации (technical specifications 62 ), такие как схемы баз данных, описания алгоритмов, интерфейсов и т.д. • Проектная документация (project documentation 63 ) включает в себя как про- дуктную документацию, так и некоторые дополнительные виды документа- ции и используется не только на стадии разработки, но и на более ранних и поздних стадиях (например, на стадии внедрения и эксплуатации). Она вклю- чает: 52 Development documentation. Development documentation comprises those documents that propose, specify, plan, review, test, and implement the products of development teams in the software industry. Development documents include proposals, user or customer requirements description, test and review reports (suggesting product improvements), and self-reflective documents written by team members, analyzing the process from their perspective. [ «Documentation for Software and IS Development», Thomas T. Barker, «Encyclopedia of Information Systems» (Elsevier Press, 2002, pp. 684‐694.)] 53 Project management plan. A formal, approved document that defines how the project is executed, monitored and controlled. It may be summary or detailed and may be composed of one of more subsidiary management plans and other planning documents. [PMBOK, 3 rd edition] 54 Test plan. A document describing the scope, approach, resources and schedule of intended test activities. It identifies amongst others test items, the features to be tested, the testing tasks, who will do each task, degree of tester independence, the test environment, the test design techniques and entry and exit criteria to be used, and the rationale for their choice, and any risks requiring contingency planning. It is a record of the test planning process. [ISTQB Glossary] 55 |