Начинаем тестировать не с тестирования: с чего начать?
Я хочу акцентировать ваше внимание на необходимости согласовать все ключевые аспекты с ответственными лицами (аналитиками, проектными менеджерами, разработчиками) еще до начала тестирования. Необходимо заранее выяснить следующие моменты:
цель тестирования (с их точки зрения);
виды тестирования, которые необходимо провести;
специфику приложения и его целевую аудиторию;
перечень устройств, на которых необходимо проводить тестирование;
список ОС и браузеров для тестирования;
разрешения экранов на которых необходимо проверить приложение;
предусмотрены ли требования к разного рода формам, есть ли стайл-гайд, актуальное ЧТЗ;
необходимость предоставления конкретной документации по результатам тестирования (отчет, чек-листы, тест-кейсы и т. д.).
Получив ответы на эти вопросы, о которых часто забывают новички, вы сэкономите свое время. Дальше переходите к непосредственной подготовке окружения и формированию стратегии тестирования.
Некогда думать, нужно тестировать! Любое тестирование требует содержательного подхода с применением техник тест-анализа и тест-дизайна. В противном случае вы рискуете навсегда остаться «monkey-тестером», ценность труда которого будет мизерна. В целом, ключевые положения тест-анализа и тест-дизайна применимы как к тестированию десктоп-приложений, так и к веб-у, но с существенной оговоркой: вы должны учитывать все упомянутые в статье нюансы. Отдельно хочу акцентировать внимание на том, что без стойкого понимания методик и способов применения тест-анализа и тест-дизайна тестировать качественно ПО практически невозможно.
Рассмотрим классический набор методик тест-дизайна, которые можно применять при тестировании веб-приложений:
разбиение на классы эквивалентности;
попарное тестирование;
тестирование переходов состояний;
анализ граничных значений;
тестирование с помощью таблиц решений;
методика тест-туров Виттакера и множество других.
Подай ключ «на 13» В настоящее время существует огромное множество разнообразных инструментов, которые упрощают жизнь всем участникам разработки нового ПО. Следовательно, не стоит забывать о том, что помимо развития личных качеств, технических знаний и навыков, мы должны уметь хорошо пользоваться вспомогательными инструментами, каждый раз испытывая все новые и новые.
Отмечу лишь некоторые из них:
Ресайзер – оперативное изменение всяческих настроек размеров отображения, просмотр метрик, переключение ориентаций отображения.
Opera Mobile Classic Emulator – классический одноименный эмулятор.
Mobile Phone Emulator – классический эмулятор.
Fiddler – ПО для отслеживания всего вашего трафика. Я всегда сопровождаю любое тестирование его фоновой работой, а потом сортирую по ошибкам и анализирую трафик. Также с помощью этого приложения можно отправлять ложные запросы на сервер с нужными вам параметрами.
Xenu Link Evaluator (альтернатива – Black Widow) – «чекер» веб-приложения на предмет наличия в нем «битых» ссылок. Также можно использовать его для формирования карты приложения.
Skipfish – активный сканер уязвимостей веб-приложений.
OpenVAS – бесплатный сканер уязвимостей.
Nikto – веб-сканер, проверяющий веб-серверы на самые частые ошибки, возникающие обычно из-за человеческого фактора.
Выводы и напутствия
Подводя итоги, я хочу еще раз акцентировать внимание читателя на том, что «веб» развивался, развивается и будет развиваться, а количество используемых технологий, как и разнообразие дефектов, – увеличиваться. Возможно, когда-то придет закат эры «веб-а», но это не случится в ближайшие 5-10 лет, поэтому знание основ и понимание сути веб-приложений поистине бесценно. Любой тестировщик рано или поздно прикоснется к «веб-у» своей профессиональной «разрушительной» рукой, но только хороший специалист получит из этого максимально приближенный к требуемому результат.
Важно помнить, что тестирование ПО ставит перед каждым вступившим в стройные ряды сферы обеспечения качества ПО такие задачи, которые практически невозможно решать однозначно и по четкому алгоритму. Тестирование – это философия, творчество, полет мысли, основанный на четких и безоговорочных технических аспектах. Пожалуй, только тестировщикам приходится одновременно быть разработчиком, системным аналитиком, пользователем, заказчиком (для которого первоочередной интерес – финансовый или иной успех продукта), специалистом в предметной области и даже DBA.
Каждый из этих навыков QA Engineer должен развивать постоянно, и тогда он сможет избежать многих возможных проблем и остаться востребованным высококвалифицированным профессионалом. Остановка в развитии для специалиста из сферы обеспечения качества фактически приравнивается к профессиональной смерти (как минимум, «клинической» в том случае, если стремление к новым знаниям со временем возвращается). Движение – это жизнь. Всем добра!
Чек-лист для тестирования веб-приложений состоит из:
Тестирования удобства использования.
Функционального тестирования.
Тестирования совместимости.
Тестирования баз данных.
Тестирования безопасности.
Тестирования производительности.
Теперь давайте рассмотрим каждый пункт по отдельности.
Тестирование удобства использования
Что это такое?
Это не что иное, как тестирование дружелюбности приложения для пользователя.
При тестировании удобства использования проверяется, легко ли новому пользователю разобраться в приложении.
В целом при тестировании удобства использования тестируется системная навигация.
Какова цель этого тестирования?
Тест удобства использования удостоверяется в простоте и эффективности использования продукта при использовании стандартных практик тестирования удобства использования.
Сценарии тестирования удобства использования:
Содержание веб-страницы верное, без грамматических и орфографических ошибок.
Все шрифты соответствуют требованиям.
Все тексты правильно выровнены.
Все сообщения об ошибках верные, без орфографических и грамматических ошибок, и соответствуют заголовку окна.
Подсказки существуют для всех полей.
Все поля правильно выровнены.
Между полями, колонками, рядами и сообщениями об ошибках оставлено достаточно свободного места.
Все кнопки должны иметь стандартный формат и размер.
Ссылка на домашнюю страницу должна быть на каждой странице сайта.
Неактивные поля должны быть серыми.
Проверьте, что на сайте нет битых ссылок и изображений.
Подтверждающие сообщения должны отображаться для всех операций обновления и удаления.
Проверьте сайт при разных разрешениях экрана ((640 x 480, 600x800 и т. д.)
Проверьте, что пользователь может пользоваться системой без раздражения.
Проверьте, что TAB правильно работает.
Панель скролла должна появляться только тогда, когда она требуется.
Если при отправке формы есть сообщения об ошибке, в нем должна содержаться информация, переданная пользователем.
Заголовок должен отображаться на каждой странице.
Все поля (текстовые, выпадающие меню, радио-кнопки и т. д.) и кнопки должны быть доступны с клавиатуры, и пользователь должен быть в состоянии пользоваться сайтом, используя только клавиатуру.
Убедитесь, что данные в выпадающих списках не обрезаются из-за размеров поля, и проверьте, зашиты ли данные в код или управляются администратором.
Функциональное тестирование
Что это?
Тестирование функциональностей и операционного поведения продукта с целью убедиться, что они соответствуют спецификациям.
Тестирование, игнорирующее внутренние механизмы системы или компонента. Оно концентрируется исключительно на выходных данных, полученных в ответ на пользовательский ввод и условия исполнения сценариев.
Какова цель функционального тестирования?
Цель функционального тестирования – убедиться, что ваш продукт соответствует нужной функциональной спецификации, упомянутой в вашей документации по разработке.
Сценарии функционального тестирования:
Протестируйте валидацию всех обязательных полей
Убедитесь, что знак звездочки отображается у всех обязательных полей
Убедитесь, что система не отображает окно ошибки при незаполненных необязательных полях.
Убедитесь, что високосные коды корректно валидируются и не вызывают ошибок в расчетах.
Протестируйте числовые поля: они не должны принимать буквы, в этом случае должно отображаться соответствующее сообщение об ошибке.
Протестируйте отрицательные значения в числовых полях, если они разрешены.
Протестируйте, что деление на ноль верно обсчитывается.
Протестируйте максимальную длину каждого поля, чтобы убедиться, что данные не обрезаются.
Протестируйте всплывающее сообщение ("Это поле ограничено 500 знаками"), которое должно отобразиться, если введенные данные превышают разрешенный размер поля.
Убедитесь, что подтверждающее сообщение отображается для операций обновления и удаления.
Убедитесь, что значения стоимости отображаются в нужной валюте.
Протестируйте все поля ввода на спецсимволы.
Протестируйте функциональность тайм-аута.
Протестируйте функциональность сортировки.
Протестируйте функциональность доступных кнопок.
Протестируйте условия использования и часто задаваемые вопросы: они должны быть внятными и доступными пользователю.
Протестируйте, что при отказе функциональности пользователь перенаправляется на специальную страницу ошибки.
Протестируйте, что все загруженные документы правильно открываются.
Протестируйте, что пользователь может скачать загруженные файлы.
Протестируйте почтовую функциональность системы.
Протестируйте, что Java Script верно работает в разных браузерах (IE, Firefox, Chrome, Safari, Opera).
Посмотрите, что будет, если пользователь удалит куки, находясь на сайте.
Посмотрите, что будет, если пользователь удалит куки после посещения сайта.
Протестируйте все данные в выпадающих списках: они должны быть расположены в хронологическом порядке.
Тестирование совместимости
Что это?
Тестирование совместимости используется, чтобы убедиться, что ваше приложение совместимо с другими элементами системы, в которой оно работает – например, браузерами, операционными системами или железом.
Какова цель тестирования совместимости?
Цель тестирования совместимости – оценка того, насколько хорошо ПО работает в определенном браузере, под определенной ОС, с другим ПО или железом.
Сценарии тестирования совместимости:
Протестируйте сайт в различных браузерах (IE, Firefox, Chrome, Safari, Opera) и убедитесь, что сайт правильно отображается.
Убедитесь, что используемая версия HTML совместима с соответствующими версиями браузеров.
Убедитесь, что картинки корректно отображаются в разных браузерах.
Убедитесь, что шрифты верно отображаются в разных браузерах.
Убедитесь, что Java Script код работает в разных браузерах.
Проверьте анимированные GIF в разных браузерах.
Инструмент для тестирования совместимости
Spoon.net: Spoon.net предоставляет доступ к тысячам приложений (браузеров), не требующих установки. Этот инструмент помогает вам тестировать приложение в разных браузерах на одной и той же машине.
Тестирование баз данных
Что это?
При тестировании баз данных проверяются бэкэнд-записи, введенные через веб или десктоп-приложение. Данные, которые отображаются в приложении, должны совпадать с данными, хранящимися в базе данных.
Чтобы тестировать базы данных, тестировщик должен знать следующее:
Тестировщик должен понимать функциональные требования, бизнес-логику, основной сценарий приложения и дизайн базы данных.
Тестировщик должен разбираться в таблицах, триггерах, процедурах хранения, способах отображения и указателях, используемых для приложения.
Тестировщик должен понимать логику триггеров, процедур хранения, способов отображения и указателей.
Тестировщик должен понимать, какие таблицы затрагиваются, когда операции вставки, обновления и удаления выполняются в приложении.
Понимая вышеперечисленные пункты, тестировщик может легко написать сценарии для тестирования баз данных.
Сценарии тестирования баз данных:
Проверьте название базы данных: оно должно совпадать со спецификацией.
Проверьте таблицы, колонки, типы колонок и значения по умолчанию: все это должно совпадать со спецификацией.
Проверьте, позволяет ли колонка значение null.
Проверьте первичный и внешний ключ каждой таблицы.
Проверьте процедуры хранения.
Протестируйте, установлена ли процедура хранения.
Проверьте название процедуры хранения.
Проверьте названия параметров, их типы и количество.
Проверьте, обязательны параметры или нет.
Проверьте процедуру хранения, удалив некоторые параметры.
Проверьте базу данных, если на выходе ноль – записи с нулем должны быть задействованы.
Проверьте процедуру хранения, задав простые SQL-запросы.
Убедитесь, что процедура возвращает значения.
Проверьте процедуру вводом тестовых данных.
Проверьте поведение каждого флага в таблице.
Убедитесь, что данные правильно сохраняются в базе данных после каждого ввода.
Проверьте данные при каждой операции обновления, удаления и вставки.
Проверьте длину каждого поля. Длина на бэкэнде и фронтэнде должны совпадать.
Проверьте названия баз данных QA, UAT и прода. Имена должны быть уникальными.
Проверьте зашифрованные данные в базе.
Проверьте размер базы и время отклика на каждый запрос.
Проверьте данные, отображающиеся на фронтэнде, и убедитесь, что они совпадают с бэкэндом.
Проверьте целостность данных, вводя невалидные значения в базу.
Проверьте триггеры.
Что такое тестирование безопасности?
Тестирование безопасности нацелено на поиск недостатков и пробелов с точки зрения безопасности приложения.
Сценарии тестирования безопасности:
Убедитесь, что страницы, содержащие важные данные (пароль, номер кредитной карты, ответы на секретные вопросы и т. п.) открываются через HTTPS (SSL).
Убедитесь, что важная информация (пароль, номер кредитной карты) отображается в зашифрованном виде.
Убедитесь, что правила создания паролей внедрены на всех страницах авторизации (регистрация, страница "забыли пароль", смена пароля).
Убедитесь, что если пароль изменен, пользователь не может зайти под старым.
Убедитесь, что сообщения об ошибках не содержат никакой секретной информации.
Убедитесь, что если пользователь вышел из системы или сессия завершена, он не может пользоваться сайтом.
Проверьте доступ к закрытым и открытым страницам сайта напрямую без авторизации.
Убедитесь, что опция "Просмотр исходного кода" отключена и не видна пользователю.
Убедитесь, что учетная запись пользователя блокируется, если он несколько раз ввел пароль неверно.
Убедитесь, что пароль не хранится в куки.
Убедитесь, что если какая-либо функциональность не работает, система не отображает информацию о приложении, сервере или базе данных. Вместо этого отображается соответствующее сообщение об ошибке.
Проверьте сайт на SQL-инъекции.
Проверьте права пользователей и их роли. К примеру, кандидат не должен быть способен получить доступ к странице администратора.
Убедитесь, что важные операции пишутся в логи, и информацию можно отследить.
Убедитесь, что значения сессий отображаются в адресной строке в зашифрованном виде.
Убедитесь, что куки хранятся в зашифрованном виде.
Проверьте приложение на устойчивость к брутфорс-атакам.
Что такое тестирование производительности?
Тестирование производительности проводится для оценки соответствия системы или компонента специфичным требованиям к производительности.
Общие тестовые сценарии:
Определение производительности, стабильности и масштабируемости приложения под разной нагрузкой.
Определение, может ли актуальная архитектура поддерживать приложение при пиковых нагрузках.
Определение, какая конфигурация приводит к наилучшим показателям производительности.
Определение бутылочного горла приложения и инфраструктуры.
Определение, не изменилось ли время отклика у новой версии приложения.
Оценка продукта и/или железа с целью удостовериться, что они выдержат прогнозируемые объемы нагрузки.
Как проводится тестирование производительности? Вручную или автоматически?
В целом невозможно проводить тестирование производительности вручную по ряду причин:
Понадобится большое количество ресурсов.
Невозможно одновременно осуществлять ряд действий.
Отсутствует подходящий способ отслеживания поведения системы.
Сложность выполнения повторяющихся задач.
Чтобы справиться с вышеперечисленными проблемами, используются специальные инструменты тестирования производительности. Ниже перечислены некоторые из них:.
Apache JMeter
Load Runner
Borland Silk Performer.
Rational Performance Tester
WAPT
NEO LOAD
Тестирование требований
Данный тип тестирования включает тестирование документации требований, которая описывает:
функциональность проекта;
пользовательский интерфейс;
аппаратные и программные интерфейсы;
критерии эффективности;
вопросы и риски, связанные с реализацией проектов;
критерии безопасности и корректности системы.
В услугу тестирования требований также входит помощь в сборе и анализе данных пользователей и их предметной деятельности. Это необходимо для исследования удобства UI, создания профилей, доработке документации и, в целом, способствует процессу проектирования.
Данная процедура помогает улучшить качество требований и значительно снизить количество тестов, проводимых для удовлетворения указанных требований.
Прежде всего, наша команда QA производит сбор и анализ требований, чтобы узнать какие технологии будут использоваться в создании проекта, для кого этот проект будет создан и какова его цель. Мы также исследуем, есть ли недостающие требования, чтобы понять, является ли собранная информация последовательной и четкой, и описывается ли каждый аспект разрабатываемого ПО.
Следующим этапом мы создаем тест-кейсы на базе параметров, предъявляемым к требованиям, и выполняем их, чтобы убедиться в том, что тестируемая система работает в соответствии с заданными требованиями. Например, вам нужно, чтобы время отклика системы составляло 2 секунды — это является вашим параметром к требованию. Все подобные параметры к требованиям проходят проверку и оценку.
Мы также участвуем в обзорных совещания и в случае обнаружения новых требований или внесении изменений в существующие, мы отслеживаем их в трэкинг-системе.
И наконец, когда все требования протестированы, клиент доволен результатами и документ требований подписан, требования “замораживаются” до фазы проектирования.
Тестирование требований
Тестирование требований является необходимой и очень важной процедурой, которая в дальнейшем поможет оптимизировать работу команды и избежать недопониманий, а также позволяет понять, можно ли в принципе выполнить данные требования — с точки зрения времени, ресурсов и бюджета.
Что тестируется: требования, описывающие функциональность проекта, пользовательский, аппаратный, программный интерфейсы, критерии эффективности, риски, критерии безопасности и корректности системы
Тестирование требований
Техники тестирования требований :
Взаимный просмотр:
беглый просмотр — автор показывает свою работу коллегам, они в свою очередь дают свои рекомендации, высказывают свои вопросы и замечания;
технический просмотр — выполняется группой специалистов;
формальная инспекция — привлекается большое количество специалистов, представляет собой структурированный, систематизированный и документированный подход. Минус такого варианта — тратится много времени.
2) Вопросы — если возникают вопросы, то можно спрашивать у представителей заказчика, более опытных коллег.
3) Тест-кейсы и чек-листы — хорошее требование должно быть проверяемым, чтобы это определить можно использовать чек-листы или полноценные тест-кейсы. Если можно быстро придумать несколько пунктов чек-листа — это уже хороший знак.
4) Исследование поведения системы — необходимо мысленно смоделировать процесс работы пользователя с системой, созданной по тестируемым требованиям, после этого определить неоднозначные варианты определения системы.
5) Рисунки — графическое представление дает наглядное представление приложения, на рисунке проще увидеть, что какие-то элементы не стыкуются, где-то чего-то не хватает и т.д.
6) Прототипирование — сделав наброски пользовательского интерфейса, легко оценить применить применение тех или иных пользовательских решений.
Бонусом для понятия как проводить тестирование требований, немного о самих требованиях:
Характеристики хороших требований:
Завершенность (требование должно содержать всю информацию, необходимую для разработчиков).
Ясность (требования должны быть понятными).
Корректность и согласованность (требование должно четко указывать на то, что должно выполнять приложение).
Проверяемость (способ однозначной проверки выполнено требование или нет).
Необходимость и полезность при эксплуатации.
Осуществимость (определяется балансом между ценностью и требуемыми ресурсами).
Модифицируемость (набор требований должен быть таким, чтобы его можно было легко модифицировать, при этом не изменяя требования в других местах).
Прослеживаемость (возможность отследить связь между требованием и другими артефактами проекта, каждое требование имеет уникальный идентификатор, по которому оно легко прослеживается).
Упорядоченным по важности, стабильности и срочности.
Проблемы, которые возникают при работе с требованиями:
Проблемы незавершенности.
Проблемы противоречивости.
Проблемы некорректности.
Проблемы двусмысленности.
Проблемы непроверяемости.
Проблемы непроранжированности.
Виды тестирования ПО
Все виды работ проводимых тестировщиком можно условно разделить на два:
Функциональное тестирование — тестирование ПО главная цель которого это проверка реализуемости функциональных требований приложения, т.е. способность приложения в заданных критериях решать возложенные на него (на приложение) задачи. Требования включают в себя:
защищенность
соответствие стандартам
способность к взаимодействию
функциональная пригодность
точность
Не функциональное тестирование ПО — в первую очередь проверка на соответствие не функциональным требованиям:
Удобство (В основном производиться оценка удобства для пользователей)
Маштабируемость (проверяется как вертикальная так и горизонтальная маштабируемость тестируемого приложения)
Производительность (Способность работы приложения при различных нагрузках)
Безопасность (Защита пользовательских данных, защита данных приложения, стойкость на взлом)
Портируемость (Совместимость и переносимость приложения для и под различные окружения, платформы и т.д.)
Надежность (Поведение системы при различных непредвиденных ситуациях, способность обработки нестандартных действий пользователя)
Принципы разработки программного обеспечения
Ориентация на качество.
Адаптивность и гибкость.
Как и процесс разработки, процесс последующего тестирования программного обеспечения также следует определенной методологии. Под методологией в данном случае мы понимаем разнообразные комбинации принципов, идей, методов и концептов, к которым вы прибегаете во время работы над проектом.
Каскадная модель (Линейная последовательная модель жизненного цикла ПО)
Каскадная модель (Waterfall Model) является одной из наиболее старых моделей, которую можно применять не только для разработки или тестирования ПО, но также практически для любого другого проекта. Его базовым принципом является последовательный порядок выполнения задач. Это значит, что мы можем переходить к следующему шагу разработки или тестирования только после того, как предыдущий был успешно завершен. Эта модель подходит для небольших проектов и применима только в том случае, если все требования точно определены. Главными достоинствами этой методологии являются экономическая эффективность, простота использования и управления документацией.
Процесс тестирования ПО начинается после завершения процесса разработки. На этой стадии все необходимые тесты переносятся с юнитов на системное тестирование для того, чтобы контролировать работу компонентов как по отдельности, так и в комплексе.
Помимо упомянутых выше достоинств, данный подход к тестированию также имеет и свои недостатки. Всегда существует вероятность обнаружения критических ошибок в процессе тестирования. Это может привести к необходимости полностью изменить один из компонентов системы или даже всю логику проекта. Но подобная задача невозможна в случае каскадной модели, поскольку возвращение на предыдущий шаг в этой методологии запрещено.
V-Model (Модель верификации и валидации)
Как и каскадная модель, методика V-Model основана на прямой последовательности шагов. Основным отличием между этими двумя методологиями является то, что тестирование в данном случае планируется параллельно с соответствующей стадией разработки. Согласно этой методологии тестирования ПО, процесс начинается как только определены требования и становится возможным начать статическое тестирование, т.е. верификацию и обзор, что позволяет избежать возможных дефектов ПО на поздних стадиях. Соответствующий план тестирования создается для каждого уровня разработки ПО, что определяет ожидаемые результаты, а также критерии входа и выхода для данного продукта.
Схема данной модели показывает принцип разделения задач на две части. Те, которые относятся к дизайну и разработке, размещены слева. Задачи, относящиеся к тестированию ПО, размещены справа:
Основные этапы этой методологии могут изменяться, однако обычно они включают следующие:
Этап определения требований. Приемочное тестирование относится к этому этапу. Его основная задача состоит в оценке готовности системы к финальному использованию
Этап, на котором происходит высокоуровневое проектирование, или High-Level Design (HDL). Этот этап относится к системному тестированию и включает оценку соблюдения требований к интегрированным системам
Фаза детального дизайна (Detailed Design) параллельна фазе интеграционного тестирования, во время которой происходит проверка взаимодействий между различными компонентами системы
После этапа написания кода начинается другой важный шаг — юнит-тестирование. Очень важно убедиться в том, что поведение отдельных частей и компонентов ПО корректно и соответствует требованиям
Единственным недостатком рассмотренной методологии тестирования является отсутствие готовых решений, которые можно было бы применить, чтобы избавиться от дефектов ПО, обнаруженных на этапе тестирования.
Инкрементная модель
Данная методология может быть описана, как мультикаскадная модель тестирования ПО. Рабочий процесс разделяется на некоторое количество циклов, каждый из которых также делится на модули. Каждая итерация добавляет определенный функционал к ПО. Инкремент состоит из трех циклов:
дизайн и разработка
тестирование
реализация.
В этой модели возможна одновременная разработка разных версий продукта. Например, первая версия может проходить этап тестирования в то время, как вторая версия находится на стадии разработки. Третья версия в то же самое время может проходить этап дизайна. Этот процесс может продолжаться до самого завершения проекта.
Очевидно, что данная методология требует обнаружения максимально возможного количества ошибок в тестируемом ПО настолько быстро, насколько это возможно. Так же, как и фаза реализации, которая требует подтверждения готовности продукта к доставке к конечному пользователю. Все эти факторы существенно увеличивают весомость требований к тестированию.
В сравнении с предыдущими методологиями, инкрементная модель имеет несколько важных преимуществ. Она более гибкая, изменение требований ведет к меньшим затратам, а процесс тестирования ПО является более эффективным, поскольку гораздо проще проводить тестирование и дебаггинг за счет использования небольших итераций. Тем не менее, стоит отметить, что общая стоимость все же выше, чем в случае каскадной модели.
Спиральная модель
Спиральная модель это методология тестирования ПО, которая основана на инкрементном подходе и прототипировании. Она состоит из четырех этапов:
Планирование
Анализ рисков
Разработка
Оценка
Сразу после того, как первый цикл завершен, начинается второй. Тестирование ПО начинается еще на этапе планирования и длится до стадии оценки. Основным преимуществом спиральное модели является то, что первые результаты тестирования появляется незамедлительно после появления результатов тестов на третьем этапе каждого цикла, что помогает гарантировать корректную оценку качества. Тем не менее, важно помнить о том, что эта модель может быть довольно затратной и не подходит для маленьких проектов.
Несмотря на то, что эта модель является довольно старой, она остается полезной как для тестирования, так и для разработки. Более того, главная цель многих методологий тестирования ПО, включая спиральную модель, изменилась в последнее время. Мы используем их не только для поиска дефектов в приложениях, но также и для выяснения причин, их вызвавших. Такой подход помогает разработчикам работать более эффективно и быстро устранять ошибки.
Читайте подробнее o спиральной модели в предыдущем блог посте.
Agile
Методология гибкой (Agile) разработки и тестирование ПО может быть описана как набор подходов, ориентированных на использование интерактивной разработки, динамического формирования требований и обеспечения их осуществления как результата постоянного взаимодействия внутри самоорганизующейся рабочей группы. Большинство гибких методологий разработки ПО нацелены на минимизацию рисков посредством разработки в рамках коротких итераций. Одним из главных принципов этой гибкой стратегии является возможность быстрого реагирования на возможные изменения, нежели стремление положиться на долгосрочное планирование.
Узнайте больше об Agile (прим. — статья на английском языке).
Экстремальное программирование (XP, Extreme Programming)
Экстремальное программирование является одним их примеров гибкой разработки ПО. Отличительной особенностью этой методологии является “парное программирование”, ситуация, когда один разработчик работает над кодом, в то время как его коллега постоянно проводит обзор написанного кода. Процесс тестирования ПО является довольно важным, поскольку начинается даже раньше, чем написана первая строка кода. Каждый модуль приложения должен иметь юнит-тест, чтобы большинство ошибок могло быть исправлено на стадии написания кода. Другим отличительным свойством является то, что тест определяет код, а не наоборот. Это значит, что определенная часть кода может быть признана завершенной только в том случае, если все тесты пройдены успешно. В противном случае, код отклоняется.
Главными достоинствами такой методологии являются постоянное тестирование и короткие релизы, что помогает обеспечить высокое качество кода.
Scrum
Scrum — Часть методологии Agile, итеративный инкрементный фреймворк, созданный для управления процессом разработки ПО. Согласно принципам Scrum, команда тестировщиков должна участвовать в следующих этапах:
Участие в Scrum планировании
Поддержка в юнит-тестировании
Тестирование пользовательских историй
Сотрудничество с заказчиком и владельцем продукта для определения критериев приемлемости
Предоставление автоматического тестировании
Более того, участники QA-отдела должны присутствовать на всех ежедневных собраниях, как и другие члены команды, чтобы обсудить, что было протестировано и сделано вчера, что будет протестировано сегодня, а также общий прогресс тестирования.
В то же время принципы Agile методологии в Scrum к появлению специфических особенностей:
Оценка усилий, необходимых для каждой пользовательской истории является обязательной
Тестировщик должен быть внимательным к требованиям, поскольку они могут постоянно изменяться
Риск регрессии возрастает вместе с частыми изменениями в коде
Одновременность планирования и выполнения тестов
Недопонимание между членами команды в случае если требования заказчика не до конца ясны