Перевод ISTQB Certification на русский язык

понедельник, 28 сентября 2020 г.

Оглавление учебной программы ISTQB Certification

вторник, 19 октября 2010 г.

Тестирование на протяжении жизненного цикла программного обеспечения. Модели разработки программ (часть II).

Итеративно-инкрементальная модель разработки программного обеспечения ( Iterative-incremental development models)

Итеративно-инкрементальная разработка это процесс утверждения требований к проекту, дизайна, построения и тестирования системы, выполненное в качестве более коротких циклов разработки. Например: прототипирование, концепция создания средств разработки программных продуктов, уделяющая особое внимание быстроте и удобству программирования (RAD), методология разработки программного обеспечения, созданная компанией Rational Software (Rational Unified Process (RUP)), гибкая модель разработки (adgile development models). Система, полученная методом итерации, может быть протестирована на нескольких уровнях, что является частью ее разработки. Мини-прирост, который добавляется к разработанным раннее приростам, формирует растущую систему, которая также должна быть протестирована. Регрессионное тестирование (regression testing) становится все более важным на всех итерациях после первой. Верификация и валидация могут быть выполнены на каждом мини-приросте.

суббота, 16 октября 2010 г.

Тестирование на протяжении жизненного цикла программного обеспечения. Модели разработки программ (часть I).

Тестирование не существует изолировано; оно неразрывно связано с разработкой программного обеспечения. Разные модели разработки по требуют разных подходов тестирования.

V модель (последовательная модель разработки)

Хотя и существует несколько вариантов данной модели, вообщем случае она использует 4 уровня тестирования, отвечающие 4 уровням разработки.

4 уровня, описанные в этой учебной программе:

тестирование компонентов (component or unit testing)
интеграционное тестирование (integration testing)
системное тестирование (system testing)
приемочное тестирование (acceptance testing)

На практике V-модель может иметь больше, меньше или другие уровни разработки и тестирования, указанные здесь, это зависит от проекта и программного обеспечения. Например, после компонентного интеграционного тестирования может следовать тестирование компонентов и системное интеграционное тестирование может идти после системного тестирования.

Рабочие документы (такие как бизнес сценарии или use кейсы, спецификации, документы по дизайну и код), составленные во время разработки программы, часто являются основой для тестирования на одном или нескольких уровнях тестирования. Общие стандарты ведения проектов включают Модель зрелости процессов создания (Capability Maturity Model Integration (CMMI)) или Процессы жизненного цикла разработки программы (‘Software life cycle processes’ (IEEE/IEC 12207)). Проверка и верификация (а также тест дизайн) могут быть осуществлены в процессе разработки программных продуктов.

суббота, 9 октября 2010 г.

Психология тестирования. Вступление (часть II)

Нахождение ошибок во время тестирования можно расценивать как чрезмерную критику продукта и автора продукта. Поэтому тестирование рассматривается скорее как деструктивная деятельность, даже не смотря на то, что она считается довольно творческой при управлении рисками продукта. Поиск ошибок в программе требует любопытства, профессионального пессимизма, критического взгляда, внимания к деталям, активных переговоров и обсуждений продукта с коллегами по разработке и опыт, на основе которого находится ошибка.

Если ошибки, дефекты или сбои программы обсуждаются конструктивным путем, то можно избежать конфликтов между тестировщиками и аналитиками, дизайнерами и разработчиками. Это применимо как к оцениванию так и к тестированию.

Тестировщик и тест лид должны обладать хорошими навыками общения для обсуждения дефектов, прогресса и рисков конструктивным путем. Автору программы или документа информация об ошибке может помочь улучшить свои навыки. Ошибки, найденные и исправленные во время тестирования, уменьшат финансовые затраты и количество времени на их исправление, а также сократят риски.

Недоразумения в команде могут возникнуть, частично если тестировщики расцениваются только как вестники нежелательных новостей об ошибках. Однако, есть несколько путей чтобы улучшить взаимопонимание между тестировщиками и другими членами команды:

Начать с сотрудничества, а не с противоречий - напомните каждому об общей цели достижения лучшего качества работы системы
Обсуждайте найденные ошибки в нейтральном, нацеленном на факты тоне, не критикуя человека, который ее допустил, например, объективно и фактично описывайте инциденты и делайте обзор выводов
Пытайтесь понять как себя чувствует другой человек и почему он так реагирует
Убедитесь, что человек понял, что вы сказали, и что вы поняли его

четверг, 7 октября 2010 г.

Психология тестирования. Вступление (часть I)

С точки зрения психологии, подход к тестированию отличается от подхода к программированию. С правильной установкой программисты могут тестировать свой программный код, но предоставление этих обязанностей тестировщикам обычно делается с целью сосредоточить усилия и обеспечить процесс разработки программного обеспечения дополнительными преимуществами такими как, например, независимая оценка профессиональных специалистов в этой области. Независимое тестирование (independent testing) может проводиться на любом этапе.

Определенная степень независимости (не учитывая пристрастие автора) часто бывает эффективной в поиске ошибок. Тем не менее, она не избавляет от обязанности быть внимательным разработчика, который так же может эффективно найти много ошибок в своем коде.

Существует несколько уровней независимости тестирования:

тесты написаны разработчиком данной программы или приложения (низкий уровень независимости - low level of independence)
тесты написаны другим человеком (например, из команды разработчиков)
тесты написаны человеком из другой организационной группы (независимая группа тестировщиков) или специалистом по тестированию (юзабилити или тестированию производительности)
тесты написаны человеком из другой организации или другой компании (например, аутсорсинговой компании)

У людей и проектов есть цели. Люди стремятся сравнять свои планы и задачи, поставленные их менеджером и другими заинтересованными лицами, например, найти ошибки в программе или подтвердить правильность ее работы. Поэтому важно четко определять цели и задачи тестирования.

понедельник, 4 октября 2010 г.

Основы тестирования. Фундаментальный процесс тестирования (часть III)

Оценка выходного критерия и отчетность

При оценке выходного критерия выполнение тестирования оценивается в отношении того, насколько достигнуты поставленные цели. Это должно происходить на каждом этапе тестирования.

Оценка выходного критерия имеет следующие главные задачи:

сравнение данных регистрационного журнала с выходным критерием, определенным при планировании тестирования
определение нужно ли больше тестов или возможно необходимо изменить выходной критерий
написание краткого отчета по тестированию для заказчиков

Завершение процесса тестирования

В процессе завершения тестирования собираются данные предыдущих пройденных этапов для накопления опыта, тестового по, фактов и чисел. Например, когда выходит программа, проект тестирования завершается (или отменяется), завершается очередной этап или релиз продукта без внесения изменений или функций в него.

Процесс завершения тестирования имеет следующие задачи:

проверка того сколько запланированных целей достигнуто, закрытия инцидентов или поднятие записей об изменениях для тех, которые остались открытыми, а также проверка приемочного тестирования
окончание работы и архивирование результатов программ тестирования (testware), среды тестирования и инфраструктуры для дальнейшего использования
передача программ тестирования организации техобслуживания
анализ полученного опыта, улучшение результатов тестов на зрелость

суббота, 2 октября 2010 г.

Основы тестирования. Фундаментальный процесс тестирования (часть II).

Реализация и выполнение тестирования

Реализация и выполнение тестирования это деятельность, при которой тест процедуры и сценарии (test procedures and scripts) определяются посредством расположения тест кейсов в определенном порядке и включают любую другую информацию, необходимую для выполнения тестирования, среда тестирования настроена и тесты запускаются.

Реализация и выполнение тестирования имеют следующие главные задачи:

разработка, реализация и приоритетность тест кейсов
разработка, приоритетность процедур тестирования, формирование тестовых данных, подготовка test harnesses (необязательно) и написание автоматизированных сценариев
создание набора тестов из тест процедур для эффективного выполнения тестирования
проверка настроек среды тестирования
выполнение тест процедур вручную либо используя специальные программы в соответствие плановой последовательности
фиксирование результатов выполнения тестирования и особенностей и версии тестируемого программного обеспечения, тестовых инструментов и программ (testware)
сравнение полученных и предполагаемых результатов тестирования
сообщение о несоответствиях являющихся инцидентами тестирования и анализ с целью выявления причин их появления (например, ошибка в коде, в документе или в процессе выполнения определенного теста)
повторное тестирование для проверки каждой неточности. Например, повторное выполнение теста, на котором произошла ошибка, чтобы убедиться в его исправности (confirmation testing), запуск исправленного теста или тестов и проверка того, что ошибки не повлияли на неизмененную часть программы или, что исправление ошибок не приводит к появлению новых (регрессионное тестирование - regression testing)

понедельник, 28 сентября 2020 г.