Апну тему, если никто не возражает.

Поскольку "бесплатная" запись закончилась (пинаю себя за нерегулярное посещение форума :)), позволю себе спросить у записавшихся (Слава, я вас там в комментариях видел :)) - Я многое упустил или все же нет?

Хм, как ни странно выскажусь за. Голосом проще и быстрее будет, чем в чате. Канала 128\128 должно бы хватать за глаза, но я не пробовал еще.

Слава, а в какое время суток вы это планировали делать?

Артем, спасибо большое. Это как раз такое объяснение мне и нужно было :) Мне вот тоже неважно, как это называть. Просто на разруливание этой нестыковки в терминологии мне пришлось убить слишком много времени. Ибо под дымным тестом я понимал именно технику тестирования, а не фазу :)

В общем всем большое спасибо.

PS: Пойду заполнять пробел в теоретических знаниях :)

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

Эт я понимаю :)
Вопрос тут в том, как называть тест, который проводится при выдаче билда в тестирование и на основании результатов которого делается вывод о том, пускать ли билд в полный цикл тестирования или нет :)

Коллеги, я тут столкнулся с тем, что под названием "Acceptance test" я понимаю именно smoke test, как критерий для приема билда в тестирование.
Однако вчера меня ткнули в РУП и указали, что "Acceptance test" - это приемочное тестирование при выпуске билда в релиз.

Быстрое гугление по РУПовским артефактам дало примерно следующее:

smoke test
A phrase used to describe a subset of tests?typically limited in number?that can be run against each software build to determine whether the software has regressed in form or function since a previous build. Synonyms: build validation test, build verification test, build acceptance test, build regression test and sanity check.

То бишь существует таки понятие "build acceptance test" по смыслу равное smoke test-у.
Похожие названия у различных видов тестирования?

PS: за мою двухгодичную практику работы рядовым QA в компании, где процесс разработки софта поставлен на 4 балла из 5ти, для Smoke test всегда использовалось название Acceptance, потому я слегка недоумеваю :)

Подскажите наиболее скоростной и эффективный способ для того, чтобы быстро записывать тест-кейсы.

У нас в таком случае использовались чек-листы. Для регрешена вполне себя оправдали.
С подключением новых работников есетственно будут возникать трудности, но при нормальном общении в команде трудности вполне решаемы. Зато новому человеку будет на что опираться при тестировании.
Вместо фразы "Вот тебе логины-пароли, на посмотри тут" у него уже будет обощенный план действий\список функциональности и почва для задавания конкретных вопросов в стиле "а как выполнить проверку бэкап скедьюлера? где он у нас в приложении находится?"

Вы не все знаете )

Автор этого ресурса спокойненько живет себе здесь http://mytestlab.livejournal.com/

Вы тоже не все знаете, я как раз оттуда на сайт и попал :) Обнаружил просто новое лицо во френдах и пошел :-)

Вот в этой дискуссии данный ресурс уже упомянался: http://forums.softwa...opic=8003&st=60

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

Просматривая сегодня ЖЖ, наткнулся на любопытную ссылку

http://www.mytestlab.ru

При беглом просмотре оказалось, что это таки действительно сайт на русском языке посвященный тестированию. Похоже на свежатинку и бету, потому при куче разделов - наполнения чуть-чуть.
Чем-то напомнило старый добрый tester.com.ua :)

Точно также бегло просмотрев статьи по тестированию, выложенные там, у меня появилось впечатление, что я их уже где-то читал. :)

Upd: специально сейчас полез глянуть на их форум дату первого сообщения - 26.09.2006, неужто баян?

Не совсем понятно, что в вашем случае значит приостановка тестирования. А что тогда тестировщики делают после этого? Курят бамбук? Идут в отпуск?)

Тут скорее всего существительного не хватает: Приостановка тестирования версии\модуля\продукта?

И некоторые общие критерии вроде есть, типа уже упомянутой выше блокирующей ошибки, когда функциональность просто не работает и workaround-ов нет, или же когда smoke\acceptance test не прошел.

Но тут опять таки все упирается в ресурсы и технологию разработки\тестирования. Я-то ни разу не встречал еще проекта, где бы смоук/акксептанс тест не позволял выявить критичные ошибки, но не факт что подобных проектов нет :)