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

А кто тут главный?

Ранее мы познакомились с тем, что такое тестирование разрабатываемого продукта, его виды, методы и уровни. Но, прежде чем углубляться в само тестирование и его классификацию, познакомимся с управлением тестирования, чтобы было понятно с чего же начинается тестирование.
Даже если допустить, что мы идеально знаем все технические аспекты предстоящей работы, не отвеченными остаются такие вопросы, как:
·  Когда и с чего начать?
·  Всё ли необходимое для выполнения работы у нас есть? Если нет, где взять недостающее?
·  В какой последовательности выполнять разные виды работ?
·  Как распределить ответственность между участниками команды?
·  Как организовать отчётность перед заинтересованными лицами?
·  Как объективно определять прогресс и достигнутые успехи?
·  Как заранее увидеть возможные проблемы, чтобы успеть их предотвратить? 
·  Как организовать нашу работу так, чтобы при минимуме затрат получить максимум результата?
Эти и аналогичные вопросы изучаются в другой сфере, вне технической области. Они относятся к управлению проектом.
Эта задача достаточно обширна, поэтому в данной статье рассматривается лишь малая её часть (рис. 1).
            
                      Рисунок 1. Этапы управления тестированием.
Управление тестированием – это техника контроля качества, которая включает в себя активности по планированию работ, проектированию тестов, выполнению тестирования, и анализу полученных результатов.
Подход к тестированию определяется и детализируется в плане тестирования и спецификации проектирования тестов и обычно включает в себя решения, основанные на целях проекта и оценке рисков. Это первый этап планирования тестовых процессов, выбора метода и типа тестов и определения критериев входа и выхода.
Риск может быть определен как вероятность возникновения события, опасности, угрозы или ситуации, которая выражается в нежелательных последствиях или потенциальной проблеме.
Так как одной из целей тестирования является поиск дефектов, то разница между действительным и ожидаемым результатом должна быть зарегистрирована как инцидент. После обязательного изучения инцидента, он может быть определен как дефект.
Инциденты и дефекты должны отслеживаться от момента обнаружения и классификации до исправления и подтверждения, что проблема решена. Для управления всеми инцидентами до их завершения в организации необходимо установить процесс управления инцидентами и правила их классификации.
Непосредственно в тестировании используются вспомогательные продукты (рис. 2).
                         
               Рисунок 2. Пример инструмента для управления тестированием.
После планирования можно приступать к этапу авторинг тестирования – это  процесс определения конкретных шагов, необходимых для завершения теста.
Этот процесс решает вопрос, как что-то будет тестироваться. Именно здесь некие абстрактные тестовые примеры развиваются в более подробные шаги тестирования, которые, в свою очередь, станут тестовыми сценариями (test scripts) (либо ручными, либо автоматизированными).
Выполнение тестирования влечет за собой запуск тестов путем объединения последовательностей тестовых сценариев в набор тестов. Это ответ на вопрос как провести тестирование.
Составление отчетности по тестированию можно считать заключительным этапом. Отчетность используется для определения текущего состояния процесса тестирования проекта, а также общего уровня качества приложения или системы. Составление отчетности дает ответ на вопрос, как различные результаты тестирования анализируются и соотносятся между собой. 

Комментарии


  1. "Ранее мы познакомились с тем, что такое тестирование разрабатываемого продукта, его виды, методы и уровни". Прочитав первую статью, я могу смело сказать, что про методы тестирования там нет ни слова, а уровни и виды, скорее всего, одно и тоже.

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

    "Составление отчетности дает ответ на вопрос, как различные результаты тестирования анализируются и соотносятся между собой." Что значит результаты тестирования соотносятся между собой? Разве они не должны быть независимыми друг от друга??

    ОтветитьУдалить
    Ответы
    1. Дорогой читатель. Явно вы не читали статью, перед тем как "смело" утверждать. Цитирую из своей первой статьи"Также тестирование делят на методы: при тестировании "белого ящика" разработчик теста имеет доступ к исходному коду программ и может писать код, который связан с библиотеками тестируемого ПО; при тестировании "черного ящика" ...."
      Уровни и виды тестирования - это разные определения. Советую вам почитать источники, которые я указала в комментариях к первой статье.

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

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

      Удалить

Отправить комментарий

Популярные сообщения из этого блога

Дымовое, критического пути и расширенное тестирование

Из приведенной ранее классификации тестирования (в статье " С чего начинать изучение тестирования? Конечно же с методов! ") нам осталось рассмотреть «по степени важности тестируемых функций». Но, на этом теория еще не заканчивается) Итак, по степени важности тестируемых функций разделяют следующие виды: - «Дымовое» (smoke) - тестирование, которое состоит из минимального набора тестов на явные ошибки. Дымовое тестирование на начальном этапе выявляет основные критические дефекты. Исходя из того, что данные проверки практически всегда одинаковы и редко претерпевают изменениям, целесообразно будет их автоматизировать. Ежедневная сборка продукта и smoke тестирование являются передовыми практическими методами. Программу, не проходящую "дымовой тест", не имеет смысла отдавать для более глубокого тестирования. - Критического пути ( critical path test ) — основной тип тестовых испытаний, во время которого значимые элементы и функции приложения проверяются н

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

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

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

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