К основному контенту

Сообщения

Что нужно знать о рисках

Риски используются для определения того, где начинать тестирование и каким аспектам уделить большее внимание. Риск (risk): Фактор, который может привести к негативным последствиям в будущем, обычно выражается через вероятность и влияние. (ISTQB) Анализ рисков (risk analysis): Процесс оценки идентифицированных рисков для вычисления их вероятности и влияния. (ISTQB) Контроль рисков (risk control): Процесс, в результате которого выносятся решения и принимаются защитные меры для уменьшения рисков до определенного уровня или поддержанию рисков в оговренных рамках. (ISTQB) Определение рисков представляет собой  процесс идентификации  рисков с использованием таких методик как мозговой штурм, контрольные списки и история отказов. Процесс оценки определенного риска проекта или продукта с целью определить его уровень называется оценка риска. По каждому риску даётся оценка представляемой им угрозы и приводятся варианты выхода из ситуации. Например: - Персонал (вероятность низкая): в случае нетрудосп…
Недавние сообщения

Тест план и тестовая модель - что это?

Test Plan (тест план)  — это документ или совокупность документов, расписывающих всю тестовую активность (цели, подходы, ресурсы и график запланированных тестовых активностей)  в пределах одного проекта, все работы проводимые командой тестирования или одним тестировщиком. В стандарте IEEE 829 перечислены пункты, из которых должен состоять тест-план: 1) Testplanidentifier (идентификатор); 2) Introduction (описание/цель) - Предельно краткое описание цели разработки приложения (частично это напоминает бизнес-требования); 3) Featurestobetested (Области, подвергаемые тестированию) - Перечень функций и/или нефункциональных особенностей приложения, которые будут подвергнуты тестированию. В некоторых случаях здесь также приводится приоритет соответствующей области. 4) Featuresnottobetested (Области, не подвергаемые тестированию) - Перечень функций и/или нефункциональных особенностей приложения, которые не будут подвергнуты тестированию. Причины исключения той или иной области из списка тестируемы…

Советы для молодых тестировщиков или как составлять тест - кейс =)

Тест (test) представляет собой набор операций, предназначенных для получения одного или большего числа ожидаемых результатов в некоторой программной системе. Тест-кейсы должен помочь тестировщику (даже начинающему) провести проверку продукта без ознакомления со всей документацией. В тест – кейсе желательно избегать зависимостей от других тест – кейсов. Тест кейс в основном состоит из *Основных параметров - id (номер) - уникальный идентификатор тест-кейса. Его удобно использовать для одинакового понимания, о какой проверке идет речь (например, дать ссылку в баге). - Автор – имя и фамилия тестировщика, который написал тест – кей. - Название — краткое описание сути проверки. - Предусловие – предварительные шаги. - Шаги – что нужно сделать, чтобы что-то получить. - Ожидаемый результат – тот результат, который соответствует документации или здравому смыслу =). - Фактический результат – то, что получилось в итоге действия в шаге. - Постусловия – заключительные шаги. - Статус (pass/ fail/ block) – прост…

Тестирование user story

На приведенной ниже схеме наглядно представлено как качественно протестировать user story/ (Источник: http://www.xmind.net/m/V9WU. Автор Д. Манухина).

Первый этап к составлению тест кейсов это определение и согласование стратегии тестирования: ·Определение уровней тестирования ·Учет рисков по проекту/продукту ·Построение матрицы взаимодействия компонентов ·Определяем какой функционал будем тестировать, а какой нет ·Определяем глубину тестирования, % приемлемого тестового покрытия и критерии выхода ·Определяем временные рамки с учетом того, что userstory могут передать в тестирование в конце итерации ·Выполняем тестирование userstory Второй этап - определение необходимых видов тестирования userstory. - Функциональное - Нефункциональное (ISTQB) ·Reliability testing (надежности) ·Usability testing (удобства использования)