Comments 20
Увидел блог «тестирование», посмотрел статьи и не нашел ни одной, описывающий сам процесс. Взять, к примеру, комикс гугла. Очень интересно, каким образом осуществляется само тестирование, как этот процесс автоматизируется и т.д.
На Хабре, к моему сожалению, данный блог не очень активен.
Статьи по тестированию можно посмотреть на сайте it4business.ru.
Статьи по тестированию можно посмотреть на сайте it4business.ru.
я могу вкратце рассказать если интересно. в моем подразделении мы не создаем продукт, а только тестируем продукты сторонних заказчиков, чистый 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
— с заказчиком обговаривается, что мы будем тестировать (какой продукт)
— 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
в моем представлении smoke test это нечто вроде «потестил основное, не напрягаясь с перерывами на покурить» :)
Все проще — это когда ты включаешь девайс, а он как минимум не дымиться… :)
en.wikipedia.org/wiki/Smoke_test
en.wikipedia.org/wiki/Smoke_test
Может наоборот — нервно куря :-)
У всех, кто оставил коменты, ровно по 4 минуса… НЛО?
хм… а я smoke-тесты называю aceeptance-тестами.
или же это «две большие разницы»?
acceptance-тесты мне нужны для проверки основной функциональности — что продукт не сломан вообще, а может работать и выполнять основные действия.
или же это «две большие разницы»?
acceptance-тесты мне нужны для проверки основной функциональности — что продукт не сломан вообще, а может работать и выполнять основные действия.
Acceptance-тесты это по русски приёмочные тесты, ну и соотвественно они определяют удовлетворяет ли продукт критериям заказчика, и соответсвенно «примёт» он его или нет.
у нас конкретного заказчика нет, это образ скорее собирательный… поэтому проверяется на соответствие «внутренним» критериям.
В англоговорящем мире acceptance test — синоним smoke test-а, и подтверждает, что тестеры готовы принять этот билд от девелоперов, и он пригоден для тестирования (не падает сразу, либо — заявленная разработчиками как готовая функциональность правда функционирует). Поскольку заказчиком никогда не являются тестеры, это не про критерии заказчика.
надо же, пост зла стал постом добра )
Интересно, как сделать статьи про тестирование хоть немножечко интереснее?
Sign up to leave a comment.
Артефакты, необходимые для тестирования