Артефакты, необходимые для тестирования

    Дисклаймер. Данная статья не является претензией на объективность, а отражает только мое сугубо личное мнение. Также прошу обратить внимание на то, что мое мнение не является статичным и может меняться. Статья написана только для того, чтобы не отвечать много раз на одни и те же вопросы, а просто дать ссылку.

    Итак попробую ответить на вопрос: какие артефакты необходимы для обеспечения процесса тестирования (имеется ввиду разрабатываемые самим тестировщиком).

    Я выделяю несколько артефактов:

    1. План тестирования (Test plan)
    2. Тестовый сценарий (Test-case)
    3. Наборы тестовых сценариев (Test script or Test suite)
    * Набор тестовых сценариев для Smoke-test
    * План приёмосдаточных испытаний (ПСИ)
    4. Описание дефектов
    5. Отчет о тестировании

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

    План тестирования

    Есть как минимум два общепринятых понимания этого документа:

    1. Документ описывающий кто, что, когда и как будет тестироваться
    2. Документ описывающий все необходимые для проверки приложения тесты.

    Говоря план тестирования, я подразумеваю именно первый вариант толкования.
    Для того чтобы посмотреть пример плана тестирования можно:

    * Взять книгу Роберт Калбертсон, Крис Браун, Гэри Кобб. Быстрое тестирование
    * Взять RUP
    * Погуглить
    * Дождаться когда я изложу пример в одной из следующих статей

    Тестовый сценарий(тест)

    Тестовый сценарий — это описание начальных условий, входных данных, действий пользователя и ожидаемого результата.
    Хорошая практика — написание тестовых сценариев на основании вариантов использования (Use cases).

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

    Варианты названий:

    * Атомарный тест
    * Тестовый вариант
    * Вариант тестирования
    * Тестовый случай

    Наборы тестовых сценариев

    Это тестовые сценарии сгруппированные по некоему признаку (например тестируемой функциональности). Они могут быть как зависящими от последовательности выполнения (результат выполнения предыдущего является предварительным условием для следующего (Test script)), так и независимыми (Test suite).
    Наиболее часто выделяемыми наборами являются: Набор тестовых сценариев для Smoke-test и План приёмо-сдаточных испытаний.

    Набор тестовых сценариев для Smoke-test

    Если честно, то я не знаю адекватного перевода на русский данного термина. Иногда используется перевод “Дымчатое тестирование”, но он вызывает у меня стойкое отвращение.

    Набор тестовых сценариев для Smoke-test — это документ, включающий в себя набор определенных тестовых сценариев, покрывающих основную функциональность объекта или системы. Цель проведения Smoke-test — убедиться в том, что ключевые функции программы работают, не вникая в подробности.

    Хорошая практика — прием билда в тестирование на основании прохождения Smoke-test. Также зачастую в качестве такого теста используют ежедневную сборку с обязательным прохождением unit тестов.

    Комментарий: Ежедневная сборка без unit тестов не может считаться как Smoke test. Это называется: “Ух ты компилицо”

    План приёмо-сдаточных испытаний (ПСИ)

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

    В общем случае подмножества тестов выглядят так как на рисунке.

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

    Подробнее
    Реклама

    Комментарии 20

      +2
      Увидел блог «тестирование», посмотрел статьи и не нашел ни одной, описывающий сам процесс. Взять, к примеру, комикс гугла. Очень интересно, каким образом осуществляется само тестирование, как этот процесс автоматизируется и т.д.
        +1
        На Хабре, к моему сожалению, данный блог не очень активен.

        Статьи по тестированию можно посмотреть на сайте it4business.ru.
          +2
          я могу вкратце рассказать если интересно. в моем подразделении мы не создаем продукт, а только тестируем продукты сторонних заказчиков, чистый qa без девелопмента. итак:
          — с заказчиком обговаривается, что мы будем тестировать (какой продукт)
          — qa создает test plan, в котором описаны кто, где и когда делает работу, кто за что отвечает, кто ответственный с каждой стороны, риски и т.п. аппрувится буджет и сроки.
          — заказчик выдает кучу требований (requirements) и дефектов (defect, bug), коорые они имплементировали / пофиксили в своем продукте.
          — qa пишет test script (состоящий из test case) на каждый такой рек.
          — наcтупает фаза функционального тестирования — прогоняются все приготовленные functional test scripts. заносятся новые дефекты. дефекты могут обсуждаться с девелоперами, но только qa решает правильно ли продукт работает или нет.
          — test cases из functional test scripts переносятся в regression test scripts (библиотека тест сценариев для проверки всех функциональностей продукта)
          — гоняются regression test scripts. заносятся дефекты.
          в зависимости он нужд заказчика, сроков, качества продукта определяется будет ли еще билд в данном случае или заказчик доволен результатом. если нет — то возможно:
          — дополнительный билд с пофиксенными дефектами из functional и regression фаз — тут делается только defect retest
          — или же еще 1-2 билда для defect retest и regresstion test run
          +2
          в моем представлении smoke test это нечто вроде «потестил основное, не напрягаясь с перерывами на покурить» :)
            +3
            Все проще — это когда ты включаешь девайс, а он как минимум не дымиться… :)

            en.wikipedia.org/wiki/Smoke_test
            +4
            Может наоборот — нервно куря :-)
              +2
              Перед показом заказчику и такое бывает :)
                +2
                это признак неграмотно поставленного процесса управления проектом :)
                  +2
                  Да я ж и не спорю.
                  Если это постоянно тогда да — плохо.
                  А если редко — то бодрит :)
                    +2
                    слишком велика вероятность того что что-то будет упущено. при столь усиленном стиле тестирвоания ))
                    я предпочитаю спокойненько размеренно все постепеннь проверять :)
              +1
              У всех, кто оставил коменты, ровно по 4 минуса… НЛО?
                +1
                тоже сейчас заметил… либо нло, либо…
                  +1
                  есть Посты Добра, а этот пост сделался Постом Зла :)
                +1
                хм… а я smoke-тесты называю aceeptance-тестами.
                или же это «две большие разницы»?

                acceptance-тесты мне нужны для проверки основной функциональности — что продукт не сломан вообще, а может работать и выполнять основные действия.
                  +1
                  Acceptance-тесты это по русски приёмочные тесты, ну и соотвественно они определяют удовлетворяет ли продукт критериям заказчика, и соответсвенно «примёт» он его или нет.
                    +1
                    у нас конкретного заказчика нет, это образ скорее собирательный… поэтому проверяется на соответствие «внутренним» критериям.
                      0
                      В англоговорящем мире acceptance test — синоним smoke test-а, и подтверждает, что тестеры готовы принять этот билд от девелоперов, и он пригоден для тестирования (не падает сразу, либо — заявленная разработчиками как готовая функциональность правда функционирует). Поскольку заказчиком никогда не являются тестеры, это не про критерии заказчика.
                    0
                    надо же, пост зла стал постом добра )
                      +1
                      Интересно, как сделать статьи про тестирование хоть немножечко интереснее?
                        0
                        Нарисовать комиксы как у гугла )

                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                      Самое читаемое