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

В какой очерёдности практика рекоммендует выполнять тестирование?
Регресионное, нагрузочное? и пр.
Имеетмя в виду, если есть время, проект готов к тестированию и все прочие тех вопросы закрыты.
То есть методологически есть ли какие то предпосылки к очерёдности различных видов тестирования?

У нас на практике выстроилась следующая очередность:
1. Приемочное тестирование - набор тестов для проверки общей базовой работоспособности проекта.
2. Регрессионное тестирование - полный набор тестирования функциональности.
3. Нагрузочное тестирование - performance/load testing
4. Определение пика возможной нагрузки

Вроде как нет смысла проводить нагрузочные тесты, если не работает функциональность.

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

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

Поэтому если времени достаточно (а именно так изначально поставил вопрос Case), стараемся начинать тестирование производительности как можно раньше -- как только система приходит в состояние, в котором его вообще можно проводить, а это ведь на самом деле можно делать задолго до завершения функциональных тестов.

2Oleshka:

2. Регрессионное тестирование - полный набор тестирования функциональности.

Не совсем понял видимо, но почему между регрессионным тестированием и тестированием функциональности стоит тире?

Регрессионное в широком смысле - тестирование на вопрос не отвалилось ли что-то, что раньше работало при переходе к следующему билду, к примеру.

Функцаональное - это в принципе тестирование на работоспособность и правильность работы.
Регрессионное как я понимаю выполняетсяв процессе разработки, а не после, когда проект в принципе готов. Или я как то с терминологией путаюсь?

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

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

Поэтому если времени достаточно (а именно так изначально поставил вопрос Case), стараемся начинать тестирование производительности как можно раньше -- как только система приходит в состояние, в котором его вообще можно проводить, а это ведь на самом деле можно делать задолго до завершения функциональных тестов.

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

To Case:

Могло быть и двоеточие. ;) Разницы нет, только регрессионное тестирование у нас выполняется не в процессе разработки, а после. В процессе разработки выполняется функциональное тестирование исправлений, изменений и новой функциональности, потом прогоняется весь пакет регрессионных тестов для подтверждения, что все как работало, так и работает.

Прошу прощения - регрессионый тест после чего?

Прошу прощения - регрессионый тест после чего?

После проверки отдельно всех изменений, исправлений и новых фичей.

Я всё пытаюсь вернуться к теме которую я поднял.
У нас с Вами небольшое недопонимание терминологии, ну да это не проблема, я понял о чём Вы, кажется :)

Меня интересует следующая ситуация.
Проект завершён. Функционал не добавляется. (я вроде как и оговорил это в вопросе, ну на всякий случай уточнюсь). Есть желание устроить так сказать гранд-финале тестинг.
В наличии любые возможности (такой себе оптимальный вариант): хочу прогнать N раз все тесты не по алфавиту, а по логике какой-то, которая пока от меня ускользает.
То есть могу сделать прогон всех тестовых случаев поведения пользователя скриптами, потом натравить нагрузочные тесты поглядеть как система под нагрузкой ведёт, могу потом дать ещё первому пойманному в коридоре попробовать кнопки потыкать, потом уже дать в руки на приёмочное испытание заказчику, а могу и в любой другой последовательности, вот и интересует - как лучше?

А о чем я? :D В моем понимании для регрессионного тестирования используются все существующие тесты функциональности. Это могут быть и скрипты, имитирующие типичные сценарии работы пользователя. Прогоняются на каждом релизе ПОСЛЕ тестирования всех изменений, но ДО нагрузочного тестирования. Другое дело, что эти скрипты тоже надо менять согласно изменениям.

И еще - у нас пакет регрессионных тестов обычно пополняется из двух источников. Один - создание тестов по спецификации, проверяющих, работает ли система так, как должна. Второй - тесты, направленные на проверку найденных и исправленных багов - для того, чтобы проверить, что эти баги не появились снова.

Я бы так и делала, как Вы описали. Только насчет коридора - мне кажется, лучше это делать раньше - а то как выяснится, что есть определенные вещи, просто неудобные по интерфейсу, да перед самой сдачей заказчику... ой. Лучше не надо. То есть если это не делали раньше - сделать, но, наверно, имеет смысл устраивать такие проверки регулярно.

Функционал не добавляется.
В наличии любые возможности
проект готов к тестированию и все прочие тех вопросы закрыты.

У нас, видимо, случилось еще и недопонимание постановки вопроса :D

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

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

Проект тестировался в процессе разработки.
Логика вроде да, работает.
До последней даты заморозки вносились изменения, которые планово тестировались.
Этап закончен.

Теперь я хочу оттестировать, ну как сказать, пусть с белого листа.
Пусть я стал на место команды, которая вот взяла и получила в руки проект на альфа-тест.

К примеру мне дают в работу удалённую команду, которая будет проводить альфа-тестирование на месте внедрения. Вариант? Мне их нужно скоординировать и направить в процессе тестирования.

Теперь стало многое понятно :D

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

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

2a. {если требуемые характеристики производительности определены}
нагрузочное тестирование (здесь -- проверка соответствия производительности системы требуемым параметрам),
или
2b. {если характеристики производительности не заданы}
тестирование производительности (здесь -- определение характеристик производительности системы);

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

4. системные испытания (здесь -- совместная работа всех компонент системы в нормальном режиме);

5. стресс-тесты (здесь -- устойчивость при пиковых и поведение при запредельных нагрузках).

Примечания:
а) Несмотря на разницу формулировок, регрессионное тестирование сюда, на мой взгляд, никак не вписывается. В этом смысле очень показателен пример с удаленной командой, который приводит Case -- в этом случае никакой истории проекта просто не существует, люди получают новый продукт.
б) "Коридорный" тоже оказывается как-то не у дел: как справедливо замечает Oleshka, его ждали раньше; а сейчас-то что -- функциональность в этой версии все равно уже не меняется, а если нужны пожелания для будущих усовершенствований, так их можно замечательно собрать при бета-тестировании и позже.. Хуже от него, конечно, не будет, но и пользы не видно.
в) А вообще, при таких условиях и думать-то особенно незачем: неограниченные возможности плюс достаточное количество времени -- и вправду можно хоть по алфавиту все запускать, оптимизация не требуется :D

Может статью подготовите?
Согласен по всем пунктам.

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

Поддерживаю.
Прям как на пленумах :)
В опчем согласен.

Теперь стало многое понятно :D

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

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

2a. {если требуемые характеристики производительности определены}
нагрузочное тестирование (здесь -- проверка соответствия производительности системы требуемым параметрам),
или
2b. {если характеристики производительности не заданы}
тестирование производительности (здесь -- определение характеристик производительности системы);

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

4. системные испытания (здесь -- совместная работа всех компонент системы в нормальном режиме);

5. стресс-тесты (здесь -- устойчивость при пиковых и поведение при запредельных нагрузках).

Примечания:
а) Несмотря на разницу формулировок, регрессионное тестирование сюда, на мой взгляд, никак не вписывается. В этом смысле очень показателен пример с удаленной командой, который приводит Case -- в этом случае никакой истории проекта просто не существует, люди получают новый продукт.
б) "Коридорный" тоже оказывается как-то не у дел: как справедливо замечает Oleshka, его ждали раньше; а сейчас-то что -- функциональность в этой версии все равно уже не меняется, а если нужны пожелания для будущих усовершенствований, так их можно замечательно собрать при бета-тестировании и позже.. Хуже от него, конечно, не будет, но и пользы не видно.
в) А вообще, при таких условиях и думать-то особенно незачем: неограниченные возможности плюс достаточное количество времени -- и вправду можно хоть по алфавиту все запускать, оптимизация не требуется  :D

Соглашусь со следующими вопросами-оговорками:

Мне не очень ясна идея разделения функциональных тестов на две части - прогоняемые до и после нагрузочного тестирования и тестирования производительности. Если они разнесены по времени, четкого представления о качестве продукта не получится.

Если при прогоне приемочных тестов будут выявлены критические ошибки, то их, естественно, будут исправлять и после исправлений выполнять снова все приемочные тесты. То есть и работа удаленной команды тестировщиков может состоять больше чем из одного цикла тестирования. На этом этапе появляется регрессионное тестирование в двух вариантах:
а) надо провести те тесты, которые выявили критические ошибки, чтобы убедиться, что их больше нет ((с) Сэм Канер и др.)
б) еще раз выполнить приемочные тесты, чьи результаты служат основой для принятия решения о сдаче продукта клиенту. В терминологии el-step - это приемочные тесты.

Регрессионое тестирование будет выполнять не удалённая команда - у неё для этого нет набора всех материалов проекта и истории изменений. Регрессионое тестирование будет выполнять таже команда тестирования, которая вела проект и которая его выпустила в альфу или в бета версию.
Удалённая команда регрессионным всё-таки как я вижу заниматься не должна - потому как не может физически. Поддерживаю el-step.

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

Еще раз - если нет критических багов, то нет повода и вносить изменения. Вот если будут - тогда дело другое. И неясность не в вопросах нагрузочного тестирования, а в том, зачем разделять во времени функциональные тесты.

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

зачем разделять во времени функциональные тесты

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

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

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

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

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

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

На этом этапе появляется регрессионное тестирование в двух вариантах

Считаю, что Case прав: регрессионное тестирование как таковое будет выполнять команда, которая вела проект. Что же касается "удаленных" -- из скольки бы этапов не состояла их работа, шаги на каждом этапе могут быть теми же. Ведь в данном случае приемочные тесты -- это как раз и есть тесты, которые выявили ошибки. Поэтому все что требуется после исправлений -- снова начать с первого шага. Можно называть это регрессионным тестированием, если так удобнее -- вопросы терминологии на суть дела не слишком влияют :)

Если они разнесены по времени, четкого представления о качестве продукта не получится

Тут уже мне не очень понятно... Почему не получится? Я, честно говоря, не вижу зависимости представления о качестве продукта от порядка проведения тестов... Наверное, у нас просто какое-то разночтение :)