ФУНКЦИОНАЛЬНОЕ ТЕСТИРОВАНИЕ. ПОДХОДЫ К ТЕСТИРОВАНИЮ: 1. «Исчерпывающее» тестирование программного обеспечения (ПО), когда пытались проверить все варианты выполнения программного кода. 2. Выполнение программы с целью найти ошибки, а не доказать, что она работает. Указанные два подхода называют «парадоксом тестирования», так как: a) с одной стороны, тестирование позволяет убедиться, что ПО работает хорошо; b) с другой – выявляет ошибки в ПО, показывая, что ПО не работает. Процесс/методология разработки ПО (software development process) – это набор задач и/или деятельности, которые решаются и/или происходят в ходе процесса создания программы. Waterfall (каскадная, водопадная модель) Основная идея: долгосрочное планирование. Хорошо работает для мелких проектов. Ошибка, найденная на более поздних этапах жизненного цикла проекта, может привести к большим дополнительным расходам, даже срыву проекта. Итерационная модель - это процесс создания программного обеспечения, который осуществляется небольшими этапами, в ходе которых ведется анализ полученных промежуточных результатов, выдвигаются новые требования и корректируются предыдущие этапы работы. Здесь очень плотное взаимодействие. Огромное кол-во анализа требований. В основном разработка кода ведется на ранних стадиях. Итерационная модель ближе всего к гибким методологиям, но направлена на крупнобюджетные проекты. В 90-х в понятие «тестирование» стали включать планирование, проектирование, создание, поддержку и выполнение тестов и тестовых окружений, и это означало переход от тестирования к обеспечению качества, охватывающего весь цикл разработки ПО. • • • • Agile Manifesto разработан и принят 11-13 февраля 2001 года. Идеи: Личности и их взаимодействия важнее, чем процессы и инструменты; Работающее программное обеспечение важнее, чем полная документация; Сотрудничество с заказчиком важнее, чем контрактные обязательства; Реакция на изменения важнее, чем следование плану. Семь принципов тестирования: • Принцип 1. Тестирование демонстрирует наличие дефектов. Тестирование может показать, что дефекты в программном обеспечении есть, но не может доказать, что никаких дефектов не существует. Но даже если никаких дефектов не найдено, это не доказывает правильность работы программы. • Принцип 2. Исчерпывающее тестирование невозможно. Протестировать абсолютно всё (все комбинации входов и предусловий) не представляется возможным, за исключением тривиальных случаев. Вместо этого используются риски и приоритеты для эффективного поиска дефектов. • Принцип 3. Раннее тестирование. Тестовые активности должны начинаться как можно раньше в цикле разработки ПО, чтобы быть эффективнее. • Принцип 4. Скопление дефектов. Небольшое количество модулей содержит большинство дефектов, выявленных в ходе тестирования, или демонстрирует наибольшее количество операционных сбоев. • Принцип 5. Парадокс пестицида. Если одни и те же тесты повторяются снова и снова, в конце концов с их помощью вы перестанете находить дефекты. • Принцип 6. Тестирование зависит от контекста. Тестирование проводится по-разному в различных ситуациях. • Принцип 7. Заблуждение об отсутствии ошибок. Нахождение и исправление дефектов не поможет, если разработанная система не удовлетворяет нуждам и ожиданиям пользователей. ОПРЕДЕЛЕНИЯ: Тестирование программного обеспечения (Software Testing) – процесс анализа программного средства и сопутствующей документации с целью повышения качества продукта. Обеспечение качества (Quality Assurance) – мероприятия, охватывающие все этапы разработки, выпуска и эксплуатации ПО, проводимых на разных стадиях жизненного цикла ПО, для обеспечения качества выпускаемого продукта. Контроль качества (Quality Control) – рабочие методы и активности, нацеленные на выполнение требований к качеству производимого продукта. Верификация (Verification) – это процесс оценки системы или её компонентов с целью определения удовлетворяют ли требованиям, определенным в начале. Валидация (Validation) – это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, требованиям к системе. Тест-план (Test Plan) – часть проектной документации, описывающая и регламентирующая процесс тестирования. Чек-лист (Check-List) – набор идей тестов, которые проверяют работу программы. Тест-кейс (Test Case) – набор входных данных, условий выполнения и ожидаемых результатов, разработанный с целью проверки того или иного свойства или поведения программного средства. Билд (Build) – промежуточная версия (сборка) программного средства (финальный билд называют релизом (release)). Отладка (Debugging) – процесс поиска, анализа и устранения причин отказов в программном обеспечении. Дефект (Defect, Bug) – любое несоответствие фактического и ожидаемого результата (согласно требованиям или здравому смыслу). Ожидаемый результат (Expected Result) – такое поведение программного средства, которое мы ожидаем в ответ на наши действия. Качество (Quality) – показатель степени соответствия продукта его требованиям. Качество ПО включает 8 характеристик (ISO/IEC 25010:2011): ● Функциональную пригодность (Functional suitability); ● Производительность (Performance efficiency); ● Совместимость (Compatibility); ● Удобство использования (Usability); ● Надежность (Reliability); ● Безопасность (Security); ● Ремонтопригодность (Maintainability); ● Переносимость (Portability) Уровни тестирования (по степени детализации компонентов системы): • Компонентное (модульное) тестирование (Component Testing, Unit Testing) – тестирование отдельного модуля. • Интеграционное тестирование (Integration Testing) – проверка взаимодействия модулей. • Системное тестирование (System Testing) – проверка всего приложения. Интеграционное тестирование – это тестирование части системы или системы в целом, состоящей из двух и более частей, при этом основной задачей является поиск дефектов, связанных с ошибками взаимодействия между этими частями. Приёмочное тестирование (Acceptance testing) – тестирование по отношению к потребностям и требованиям пользователя, проводимое с целью дать возможность пользователям, заказчикам определить, принимать систему или нет. • Пользовательское приемочное тестирование (UAT) - Тестирование конечного продукта проводят пользователи; • Эксплуатационное приемочное тестирование (OAT); • Альфа- тестирование потенциальными пользователями/заказчиками или независимой командой тестирования на стороне разработчиков, и бета- тестирование тестирование потенциальными и/или существующими клиентами/заказчиками на внешней стороне Виды/направления тестирования (по целям и задачам): ● Функциональное тестирование (Functional) – тестирование, основанное на анализе спецификации функциональности приложения, проводимое с целью проверки на соответствие требованиям. Проверка того, «ЧТО» система делает. ● Нефункциональное тестирование (Non-functional) – тестирование свойств приложения, которые не относятся к функциональности системы. Проверка того, «как» работает приложение (надежность, эффективность, практичность, сопровождаемость). Проверка того «КАК» работает система. Нефункциональные виды тестирования: ● Инсталляционное тестирование (Installation Testing). ● Конфигурационное тестирование (Configuration Testing) (оборудование, сервер). ● Тестирование совместимости (Compatibility Testing). ● Тестирование графического интерфейса (GUI Testing). ● Тестирование удобства использования (UX, Usability Testing). ● Тестирование интернационализации (Internationalization Testing, i18n) (возможность перехода на другой язык, готовность к переводу). ● Тестирование локализации (Localization Testing, l10n) (как перевели программу). ● Тестирование безопасности (Security Testing) (оценка защищённости продукта). ● Тестирование адаптации для людей с ограниченными возможностями (Accessibility Testing). ● Тестирование производительности (Performance Testing). ● Нагрузочное тестирование (Load Testing). ● Стресс тестирование (Stress Testing). Виды/направления тестирования (по тестированию изменений): ● Тестирование нового функционала (New Feature Testing) – проверка того, что все новое работает верно. ● Повторное тестирование (Retest, bug-fix verification) – проверка того, что поломанное действительно исправили. ● Регрессионное тестирование (Regression Testing) – проверка того, что то, что работало, по-прежнему работает после внесения изменений в код системы (исправление ошибки, реализация новой функции). Уровни функционального тестирования (по степени важности тестируемых функций и приоритету выполнения тестов): ● Дымовое тестирование (Smoke Testing) – тестирование «только самого важного», без успешного завершения которого не имеет смысла переходить на следующий уровень тестирования. ● Тестирование критического пути (Critical-Path Testing) – тестирование часто используемых повседневных функций приложения, то есть функций, которые выполняет бизнес-пользователь чаще всего в реальной жизни. ● Расширенное тестирование (Extended Testing) – тестирование всех возможных функций приложения. Виды/направления тестирования (по принципу работы с приложением): ● Позитивное тестирование (Positive Testing). ● Негативное тестирование (Negative Testing). Виды/направления тестирования (по запуску кода на исполнение): ● Статическое (Statistical Testing) – тестирование без запуска программы. Например, тестирование документации, статический анализ кода приложения специальными инструментальными средствами. ● Динамическое (Dynamic Testing) – тестирование с запуском программы. Методы тестирования (по знанию и использованию кода тестировщиком): ● «Белого ящика» (White-Box Testing, Glass-Box Testing) – тестировщик имеет доступ к коду, опирается на понимание кода во время составления тестов и/или использует код во время тестирования. ● «Черного ящика» (Black-Box Testing) – тестирование приложения без знания внутренней структуры системы (кода), когда тестировщик опирается на требования и работает с интерфейсом приложения как конечный пользователь. ● «Серого ящика» (Grey-Box Testing) – тестирование, при котором тестировщик имеет доступ только к некоторой части кода (например, доступ к БД) и использует это при составлении тестов и их выполнении. Виды/направления тестирования (по степени формализации тестов): • На основе тест-кейсов (scripted testing, test case based testing) – тестирование производится на основе заранее подготовленных тест-кейсов. • На основе чек-листов (checklist-based testing) – тестирование производится на основе чек-листов. • Исследовательское тестирование (exploratory testing) – по чек-листу или тест кейсу/сценарию, который разрабатывается или дорабатывается в процессе выполнения самих тестов. • Свободное (интуитивное) тестирование (ad-hoc testing) – ни тест-кейсов, ни чеклистов, ни сценариев, полностью опираемся на свой профессионализм и интуицию. Основные способы коммуникации в команде: • Личные беседы (один на один). • Совещания (собрания, “митинги”). • Почта. • Мгновенные сообщения. • Звонки. Часто используемые аббревиатуры в работе с почтой: MFU – Meeting Follow Up. FYI – For Your Information. IFU – Interview Follow Up. SIN – Service Interruption Notification. OOO – Out Of Office. Требования – это документ, описывающий то, что должно быть реализовано в системе. Выделяют следующие уровни требований: Уровень бизнес-требований (Business Requirement) – «общее видение системы», то есть основная концепция приложения (Vision). Уровень пользовательских требований (User Requirements, Use-Cases) – «что можно будет делать», то есть варианты использования системы. Уровень функциональных и нефункциональных требований (Functional, Nonfunctional, Technical Requirement) – «что конкретно должна выполнять система и каким образом она должна это выполнять». Детализация требований в спецификации (Specifications) – «система должна соответствовать таким-то параметрам», то есть требованиям, уточненным до числовых характеристик. Типы требований: o Функциональные требования (functional requirements): «что система должна делать». o Нефункциональные требования (non-functional requirements): «как система должна это делать». Свойства хорошего требования: • Завершенность (Completeness). • Непротиворечивость (Consistency). • Корректность (Correctness). • Недвусмысленность (Unambiguousness). • Проверяемость (Verifiability). • Модифицируемость (Modifiability). • Прослеживаемость (Traceability). • Проранжированность (Ranked for importance, Stability, Priority) 1. Где хранятся требования? – сетевая шара, гуглдок, конфлюенс, джира и т.п., доступы к ним 2. Какие источники требований у нас есть? – документы, переписка, прототипы 3. Кто помещает требования в официальное хранилище? – PM, PO, BA, кастомер 4. Как мы узнаем об изменениях в требованиях? – тикеты, чендж реквесты, письма, митинги 5. Что более правильно – изначальные спецификации, последующие письма, прототип? 6. Кто утверждает окончательные требования? – PM, PO, BA, кастомер Требования могут быть представлены в виде: Последовательного, структурированного описания системы. User Story Диаграмм. Блок-схем. Mock-ups (отрисованных страниц приложения). Старой работающей системы Style Guide (описания стандартов графического интерфейса) Общая концепция (Vision) Варианты использования (Use cases) Истории использования (User Stories) Функциональные спецификации (Functional specs) Технические изменения (Technical change) Готовое приложение Документация для тестирования: ● Чек-лист (Check-List) – высокоуровневый список идей проверок. ● Тест-кейс (Test Case) – набор входных данных, условий / шагов выполнения и ожидаемых результатов, разработанный с целью проверки свойства или поведения программного средства. ● Тестовый сценарий (Test Scenario, Test Suite) – набор тестов (тест-кейсов), собранных в последовательность для достижения некоторой цели. Последовательность разработки и выполнения тестов: ● Простые позитивные. ● Простые негативные. ● Сложные позитивные. ● Сложные негативные Атрибуты тест-кейса: • Идентификатор (ID). • Приоритет (Priority). • Ссылка на требование (Requirement). • Модуль / подмодуль (Module / Submodule). • Описание (Description). • Название тест-кейса (Title) • Предусловие (Precondition) • Шаги воспроизведения (Test Steps/Test procedure) • Постусловие (Postcondition) • Ожидаемый результат (Expected Result) - valid in release - designer - created date - version - status - update -reviewer -introduced in -automation candidate (yes,no) Для чего составляются тест-кейсы: ● Структурированный подход к тестированию. ● Возможность найти пропуски в требованиях. ● Планирование регрессионного тестирования. ● Передача знаний о приложении новым членам команды по тестированию. ● Удовлетворение требования заказчика. ● Обеспечение хранения информации. ● Контроль прогресса тестирования. Регрессионное тестирование (Regression Testing) – проверка того, что то, что работало, по-прежнему работает после внесения изменений в код системы (исправление ошибки, реализация новой функции). • Регрессия багов (bug regression) – с одной стороны мы должны убедится, что все дефекты у нас закрыты к моменту релиза, а с другой – у нас не должно быть ситуации, когда дефекты возвращаются к нам в своем прежнем обличии в новом билде, хотя в старом их по-прежнему нет. • Регрессия старых исправлений (old fix regression) – этот вариант встречается реже и как правило, речь идет о фиксах, которые были когда-то сделаны и есть риск того, что проблемы могут возникнуть снова. • Общая регрессия (general functional regression) – проверяем, что старый функционал работает так, как он работал, при этом мы не концентрируемся на отдельных частях, а идем по всему функционалу. Выделяют 2 способа проведения регрессионного тестирования: • Подтверждающий (verification) – раз за разом выполняем одни и те же тесты, которые выбраны как критичные. «+» - быстрота, по требованиям заказчика. «-» - малая вероятность найти новые баги • Осматривающий (look around) – каждый раз набор тестов изменяется, основываясь на риске возникновения ошибок в той или иной области «+» - находят новые баги, можно найти случайные баги «-» - много времени, нет тест-кейсов Принципы выбора тест-кейсов • вероятность возникновения – выше в областях, связанных с изменяемыми функциями или модулями, наиболее технически сложных; • сила влияния – больше в часто используемых функциях, или наоборот в редких, но при этом очень критичных, без которых встанет работа. В каком виде хранить тестовую информацию – в виде чек-листов или подробных тест-кейсов. Если у вас высокая текучка, низкоквалифицированные сотрудники или этого требует руководство, выбора нет, и придётся создавать и поддерживать подробные, детальные тест-кейсы. Но если в вашей команде квалифицированные сотрудники, то чек-листы значительно удобнее и помогут вам получить максимум пользы от тестовой документации, не тратя время на бюрократию! Тестовый набор (test suite) – набор тестов (тест-кейсов), собранных в последовательность для достижения некоторой цели. Test suite следует некоторой логике, например: • типичной последовательности использования приложения. • распределению функций по модулям. • по тестированию функции с различными условиями или данными. Дефект – любое несоответствие требованиям или функциональным спецификациям (здравому смыслу). То есть это отклонение фактического результата (Actual Result) от ожидаемого результата (Expected Result), которое фиксируется в документе под названием “отчет о дефекте” (Bug Report), где содержится детальная информация об ошибке. Bug report как правило создается в баг-трекинговой системе (JIRA, Rally, HP QC, Bugzilla, etc.) Цель создания отчета об ошибке: • предоставить информацию о проблеме; • приоритезировать проблему; • учесть и проанализировать качество продукта; • помочь программистам исправить Следующие сущности в баг-трекинговой системе могут быть как самостоятельными видами, так и синонимами баг-репорту: • Improvement – запрос, на улучшение существующих функций. • Feature – запрос, на расширение ПО новой функцией или изменение существующей функциональности. • Change Request – запрос, для настройки или изменения системы. • Enhancement – запрос, на воплощение новых идей, нового поведения или новой функциональности ПО. Атрибуты отчета о дефекте: • Идентификатор (id). • Краткое описание (summary). • Подробное описание (description). • Ссылка на требование (requirement id). • Фактический результат (actual result). • Ожидаемый результат (expected result). • Шаги воспроизведения (steps to reproduce). • Важность (severity). Критическая (critical). S0 Это самые страшные ошибки, выражающиеся в крахе приложения или операционной системы, серьёзных повреждениях базы данных, падению веб-сервера или сервера приложений. Высокая (major). S1 Серьёзные ошибки, такие как: потеря данных пользователя, падение значительной части функциональности приложения, падение браузера или иного клиента и т.п. Средняя (medium). S2 Ошибки, затрагивающие небольшой набор функций приложения. Как правило, такие ошибки можно «обойти», т.е. выполнить требуемое действие иным способом, не приводящим к возникновению ошибки. Низкая (minor). S3 Ошибки, не мешающие непосредственно работе с приложением. Как правило, сюда относятся всевозможные косметические дефекты, опечатки и т.п. • Срочность (priority). Устанавливает владелец Наивысшая (ASAP, as soon as possible). Присваивается ошибкам, наличие которых делает невозможным дальнейшую работу над проектом или передачу заказчику текущей версии проекта. (some times BLOCKER – настройки принтера низзя, а мы хотип тестить печать…) Высокая (high). Присваивается ошибкам, которые нужно исправить в самое ближайшее время. Обычная (normal). Присваивается ошибкам, которые следует исправлять в порядке общей очереди. Низкая (low). Присваивается ошибкам, которыми отделу разработки следует заниматься в последнюю очередь (когда и если на них останется время). • Приложения (attachments) (e.g. screenshots, video recordings, log files, etc.). • Воспроизводимость (reproducible). • Симптом (symptom). Косметический дефект (cosmetic flaw) – опечатки, повреждённые картинки, не тот цвет, не тот размер, не там расположено и т.п. Повреждение/потеря данных (data corruption/loss) – в результате ошибки данные повреждаются или теряются. Проблема в документации (documentation issue) – такой симптом присваивается ошибке, если она описывает проблему не в приложении, а в документации. Некорректная операция (incorrect operation) – например: 2+2=5, или: хотим сохранить файл в c:/ , а он сохраняется в d:/ Проблема инсталляции (installation problem) – ошибки, возникающие на стадии установки или удаления приложения. Ошибка локализации (localisation issue) – что-то не переведено или переведено неверно. Нереализованная функциональность (missing feature) – например: приложение сохраняет файлы только в формате DOC, а должно ещё и в XML. Низкая производительность (slow performance) – некоторые действия и/или условия работы приводят к тому, что приложение начинает «тормозить». Крах системы (system crash) – приложение или операционная система или (веб-сервер / сервер приложений / СБД) виснет, перезагружается, «вываливается» (закрывается). Неожиданное поведение (unexpected behavior) – например: комбинация клавиш Ctrl-O вызывает не открытие, а печать файла; в полях формы появляются странные значения по умолчанию. (Как правило связано с usability) Недружественное поведение (unfriendly behavior) – например: на сайте есть голосование, пользователь выбирает вариант, нажимает «Проголосовать» и… его просят зарегистрироваться. Симптом (symptom) (продолжение) Расхождение с требованиям (variance from spec) – под этот симптом попадает почти любая ошибка, но рекомендуется писать его только тогда, когда к ошибке не подходит ничего из вышеперечисленного. Предложение по улучшению (enhancement) – строго говоря, это – не баг, и во многих фирмах не принято его писать в список багов; имеется в виду, что приложение работает по требованиям, но можно улучшить его работу, если внести предлагаемые изменения. • Возможность «обойти баг» (workaround). • Статус (Status - fix version -Root Cause Analisis -Specific environment -Regression -Found Via Отчёт о результатах тестирования (Test Result Report, TRR) – часть документации по тестированию, включающая в себя описание процесса тестирования, итоговую информацию о протестированной за подотчетный период функциональности системы, данные о деятельности тестировщиков, планах, возможных проблемах, а также некоторые статистические данные / метрики. Цель написания TRR – проанализировать текущий процесс на проекте и качество продукта на данном этапе, чтобы выявить возможные проблемы и устранить, а также предоставить лицам, заинтересованным в проекте, данную информацию, которая выражается в конкретных фактах и / или цифрах. Test Result Report состоит из следующих секций (некоторые из них могут отсутствовать для конкретного проекта, так как они могут не нести смысловую нагрузку, так же могут быть добавлены дополнительные секции): • Команда по тестированию, которая работала над проектом (Testing Team). • Описание процесса тестирования (Testing Process Description). ● Расписание команды (может включать затраченное время), отражающее выполненные задачи (Team Timetable / Schedule). ● Краткое описание статуса текущего периода (описание процесса и качества) (Summary). ● Проблемы, которые мешают запланированному выполнению задачи (Blockers). ● Риски (Risks). ● Рекомендации (Recommendations). ● Список найденных багов (за текущий период и / или за весь период) (Bugs List). ● Статистика по ошибкам (распределенная по status, priority, severity и/или модулям приложения) (Bugs Statistics / Overall Bugs Statistics). ● Метрики (Metrics) (например, процент “заваленных” билдов; процентное соотношение найденных багов тестировщиками к багам, найденным заказчиком во время UAT; процентное покрытие требований тест-кейсами; процент, показывающий количество пройденных тест-кейсов ко всем созданным тест кейсам; процент, показывающий количество переоткрытых багов; процентное соотношение требований, на реализацию которых ушло ожидаемое время, к требованиям, на реализацию которых ушло больше запланированного времени). Заинтересованные в TRR лица: ● Команда тестировщиков в лице ведущего тестировщика. ● Команда разработчиков в лице ведущего разработчика. ● Проектный менеджер. ● Заказчик. ● Могут быть заинтересованы и такие лица, как бизнес-аналитик, архитектор, delivery-менеджер и др. в зависимости от проекта.
