«Тестирование – процесс выполнения программы с намерением найти ошибки.» (Майерс) «Тестирование программ может использоваться для демонстрации наличия ошибок, но оно никогда не покажет их отсутствие.»(Дейкстра, 1970 г) Существующие на сегодняшний день методы тестирования программного обеспечения не позволяют однозначно и полностью устранить все дефекты и ошибки и установить корректность функционирования программного продукта. Поэтому, все существующие методы тестирования действуют в рамках формального процесса проверки исследуемого или разрабатываемого программного продукта.
Такой процесс формальной проверки или верификации может доказать, что дефекты отсутствуют, с точки зрения используемого метода. (То есть нет никакой возможности точно установить или гарантировать отсутствие дефектов в программном продукте с учётом человеческого фактора, присутствующего на всех этапах жизненного циклапрограммного обеспечения). Существует множество подходов к решению задачи тестирования и верификации программного обеспечения, но эффективное тестирование сложных программных продуктов — это процесс в высшей степени творческий, не сводящийся к следованию строгим и чётким процедурам или созданию таковых.
Конечной целью любого процесса тестирования является обеспечение такого ёмкого (совокупного) понятия как Качество, с учётом всех или наиболее критичных для данного конкретного случая составляющих. Тестирование программного обеспечения — попытка определить, выполняет ли программа то, что от неё ожидают. Как правило, никакое тестирование не может дать абсолютной гарантии работоспособности программы в будущем. Задачи тестирования программного обеспечения – снизить стоимость разработки путем раннего обнаружения дефектов.
5.1.1 Методологии тестирования
В терминологии профессионалов тестирования (программного и некоторого аппаратного обеспечения), фразы «тестирование белого ящика» и «тестирование чёрного ящика» относятся к тому, имеет ли разработчик тестов доступ к исходному коду тестируемого программного обеспечения, или же тестирование выполняется через пользовательский интерфейс либо прикладной программный интерфейс, предоставленный тестируемым модулем. При тестировании методом белого ящика (white-box testing, также говорят — прозрачного ящика, оно же структурное тестирование), разработчик теста имеет доступ к исходному коду программ и может писать код, который связан с библиотеками тестируемого программного обеспечения.
Рис. 11. Метод белого ящика 
Тесты создаются на основе знаний о структуре самой системы и о том, как она работает. Критерии полноты основаны на проценте элементов кода, которые отработали в ходе выполнения тестов.
Для оценки степени соответствия требованиям могут привлекаться дополнительные знания о связи требований с определенными ограничениями на значения внутренних данных системы (например, на значения параметров вызовов, результатов и локальных переменных). При тестировании методом чёрного ящика, тестировщик имеет доступ к программному обеспечению только через те же интерфейсы, что и заказчик или пользователь, либо через внешние интерфейсы, позволяющие другому компьютеру либо другому процессу подключиться к системе для тестирования.
Рис. 12. Метод черного ящика 
Тестирование черного ящика, нацеленное на проверку требований.
Тесты для него и критерий полноты тестирования строятся на основе требований и ограничений, четко зафиксированных в спецификациях, стандартах, внутренних нормативных документах. Часто такое тестирование называется тестированием на соответствие (conformance testing).
Частным случаем его является функциональное тестирование — тесты для него, а также используемые критерии полноты проведенного тестирования определяют на основе требований к функциональности. Помимо методов тестирования «белый ящик» и «черный ящик» различают тестирование методом «серого ящика». Рис. 13.
Метод серого ящика 
В данном случае у человека, который разрабатывает тест кейсы, есть некоторая информация о внутренней структуре приложения или о деталях реализации. Данный метод применяется в последнее время чаще предыдущих.
Источник: studfile.net
Что такое тестирование требований, и зачем оно нужно
В книжках для аналитиков иногда пишут, что написанные требования к системе неплохо бы протестировать до того, как отдавать в разработку. Делают это, конечно же, единицы – не все вообще знают, что так можно, поджимают сроки, нет бюджета, сложность закупочной процедуры нивелирует пользу и т.д.
Так что этот пост для тех, кто этого никогда не делал, но давно хотел попробовать.
Давайте сначала про самое главное – тестирование требований — это НЕ требования к тестированию! А то я несколько раз видела, что эти понятия путают несмотря на то, что они очень далеки друг от друга.
Цель тестирования требований – выявить проблемы и устранить противоречия в них еще до начала разработки и избежать дорогостоящих доработок и изменений на поздних этапах проектов.
В идеале, конечно, отдавать требование на тестирование стороннему подрядчику (особенно если разработка тоже не внутренняя, а силами подрядчика), но если такой возможности нет – сойдет и внутренний тестировщик или бизнес-аналитик.
Что проверяется при тестировании требований
В рамках процесса тестирования бизнес-аналитик или тестировщик проверяют следующие аспекты требований:
- Структуру документа на соответствие утвержденному шаблону;
- Отсутствие дублирования требований в различных разделах документа;
- Соответствие требований бизнес-правилам: законодательные акты, нормативы, стандарты, правила, описанные бизнес-процессы и др.;
- Однозначность интерпретации требований;
- Достаточность детализации задокументированных требований: детальное текстовое описание элементов интерфейса системы либо наличие прототипов/макетов пользовательского интерфейса системы;
- Отсутствие противоречий между текстовым описанием элементов интерфейса, вариантами использования, прототипами/макетами пользовательского интерфейса системы, моделями данных и/или бизнес-процессов.
Также, конечно, проверяется наличие и полнота описания:
- перечня классов и ролей пользователей системы и их характеристик;
- требований к реализации в системе всех возможных сценариев протекания автоматизируемого бизнес-процесса (альтернативных/исключительных);
- требований к проверке корректности вводимых данных (автоматическая валидация);
- требований к поведению системы при прерывании либо изменении направления выполнения шагов процесса (возврат к предыдущему шагу, закрытие окна и др.);
- всех сущностей данных с указанием необходимого набора атрибутов для каждой;
- всех возможных состояний/статусов сущностей данных и условия перехода между ними; • требований при работе со списками сущностей данных;
- требований к взаимодействию с внешними системами.
В результате тестирования требований у вас могут появиться следующие артефакты:
- Реестр замечаний, содержащий перечень выявленных в требованиях проблем. Для каждой из них указывается ее уникальный номер, дата выявления, автор, раздел документа, в котором она обнаружена, суть проблемы, тип проблемы, критичность и т.д.
- Перечень предложений по улучшению разрабатываемой системы, если таковые будут – например, добавить требования к дизайну, сделать этап прототипирования и проч.
- Перечень предложений по улучшению подхода к документированию требований в компании в целом – например, присвоение кодировки, соблюдение гранулярности, степень детализации, подход к описанию НСИ и проч.
К слову о типе проблемы – возможные типы, которые должны быть выявлены в результате тестирования, имеет смысл проговорить с исполнителем заранее, чтобы он лучше понимал ваши ожидания (например, кому-то приоритетен поиск противоречий и ошибок, а кто-то считает нужным включить также поиск опечаток, получение рацпредложений по структурированию и проч.). Так как тестирование требований – редкая вещь, почти как снежный барс (все слышали, но никто не видел) – формализованных подходов к такому тестированию даже на рынке профессионального QA не очень много, поэтому лучше все обозначить на берегу.
Пример реестра замечаний по итогам тестирования требований
Ниже скрин из одного из моих старых отчетов по тестированию требований, уже не под NDA.
Тоже делаю это тестирование не всегда, но стараюсь все-таки впихнуть в проект, если на это есть время и деньги.
Как выбрать подрядчика для тестирования требований (и для тестирования вообще)
Ну для начала – просто спросите, какой у него опыт в этой отрасли тестирования. С большой вероятностью вам скажут какую-нибудь расплывчатую вещь типа «да, что-то подобное делали, уточню у коллег, можем сделать, конечно», что можно однозначно интерпретировать как «неа, не умеем, но с удовольствием отдадим джуну почитать, а с вас возьмем денег как за команду сеньоров». Понятно, что тогда лучше требования самому под бокал вина почитать вечером, толку будет больше.
Если подрядчик вопроса не испугается и выдаст что-то более осмысленное – то стоит попросить пример реестра замечаний и предложений и оценить его на соответствие тому, что вы ждете от тестирования. Часто это будет несколько листочков с притянутыми за уши рекомендациями «надо делать хорошо и по Вигерсу, а плохо делать не надо». Тоже не стоит связываться.
А вот если реестр вдохновляет детализацией, в рекомендациях – конкретика, а пример вам дали не через неделю (как только нарисовали его на коленке), а вот прямо в течение дня – с этим подрядчиком можно попробовать поработать.
Причем с большой вероятностью это будет очень-очень-очень хороший подрядчик с высоким уровнем организации процессов (раз уже до тестирования требований дорос), по крайней мере, в моем опыте это было так.
В общем, тестирование требований – отличный инструмент, который может сэкономить много часов и нервов, остается сущая ерунда – убедить заказчика и спонсора включить эти работы в проект.
Как считаете, полезно? Используете тестирование требований в своих проектах?
Источник: upravlenie-proektami.ru
Тестирование требований
Тестирование требований является необходимой и очень важной процедурой, которая в дальнейшем поможет оптимизировать работу команды и избежать недопониманий, а также позволяет понять, можно ли в принципе выполнить данные требования — с точки зрения времени, ресурсов и бюджета.
Что тестируется: требования, описывающие функциональность проекта, пользовательский, аппаратный, программный интерфейсы, критерии эффективности, риски, критерии безопасности и корректности системы
Глядя на диаграмму (согласна, так себе надежность статистики, уровня белстата примерно, но все же), большинство ошибок тянется именно из требований к ПО, поэтому нужно с этим как-то бороться, т.е. сделать так, чтобы не было следующих проблем:
- непонятность требований,
- частая изменяемость,
- изменения, вносимые в последний момент,
- неверная трактовка требований.
Из-за всего выше перечисленного может произойти следующее:
- срыв срока проекта,
- будет сделано не то и не так как нужно,
- изменения не контролируются и команда не знает, что делать.
Чтобы избежать всего этого следует сделать так , чтобы требования были :
- завершенными,
- непротиворечивыми,
- корректными,
- недвусмысленными,
- проверяемыми,
- приоритизированными.
Также хороший набор требований должен быть модифицируемым, прослеживаемым, проранжированным.
Техники тестирования требований :
- Взаимный просмотр:
- беглый просмотр — автор показывает свою работу коллегам, они в свою очередь дают свои рекомендации, высказывают свои вопросы и замечания;
- технический просмотр — выполняется группой специалистов;
- формальная инспекция — привлекается большое количество специалистов, представляет собой структурированный, систематизированный и документированный подход. Минус такого варианта — тратится много времени.
2) Вопросы — если возникают вопросы, то можно спрашивать у представителей заказчика, более опытных коллег.
3) Тест-кейсы и чек-листы — хорошее требование должно быть проверяемым, чтобы это определить можно использовать чек-листы или полноценные тест-кейсы. Если можно быстро придумать несколько пунктов чек-листа — это уже хороший знак.
4) Исследование поведения системы — необходимо мысленно смоделировать процесс работы пользователя с системой, созданной по тестируемым требованиям, после этого определить неоднозначные варианты определения системы.
5) Рисунки — графическое представление дает наглядное представление приложения, на рисунке проще увидеть, что какие-то элементы не стыкуются, где-то чего-то не хватает и т.д.
6) Прототипирование — сделав наброски пользовательского интерфейса, легко оценить применить применение тех или иных пользовательских решений.
Бонусом для понятия как проводить тестирование требований, немного о самих требованиях:
Характеристики хороших требований:
- Завершенность (требование должно содержать всю информацию, необходимую для разработчиков).
- Ясность (требования должны быть понятными).
- Корректность и согласованность (требование должно четко указывать на то, что должно выполнять приложение).
- Проверяемость (способ однозначной проверки выполнено требование или нет).
- Необходимость и полезность при эксплуатации .
- Осуществимость (определяется балансом между ценностью и требуемыми ресурсами).
- Модифицируемость (набор требований должен быть таким, чтобы его можно было легко модифицировать, при этом не изменяя требования в других местах).
- Прослеживаемость (возможность отследить связь между требованием и другими артефактами проекта, каждое требование имеет уникальный идентификатор, по которому оно легко прослеживается).
- Упорядоченным по важности, стабильности и срочности .
Проблемы, которые возникают при работе с требованиями:
- Проблемы незавершенности.
- Проблемы противоречивости.
- Проблемы некорректности.
- Проблемы двусмысленности.
- Проблемы непроверяемости.
- Проблемы непроранжированности.
Все о тестировании и качестве ПО
- Характеристики качества программного обеспечения
- Техники тест-дизайна
- Методы верификации программного обеспечения
- Расширенное тестирование
- Интеграционное тестирование: что это и зачем
I believe in QA, все о тестировании
| 1 | 2 | 3 | 4 | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 | 30 |
Больше о тестировании и качестве ПО
- Использование техник тест-дизайна
- Техники тест-дизайна
- Use-cases (юз-кейсы)
- Формальное тестирование
- Методы верификации программного обеспечения
- Мобильное тестирование
Источник: qaevolution.ru