Сообщений в теме: 12

[Ekaterina]

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

[SALar]

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

Если мы что то дедаем, то делаем для чего то. Зачем вам эта метрика? Это не отвержение, это именно вопрос. Зачем вам эта цифра? Если она вам не нужна, то "по определению" вам не нужно ее считать.

[Guriy]

Если это для отчетов перед начальством, то да

[Ekaterina]

в план тестирования, конкретно в раздел - стратегия тестирования... ага, для начальства )

[PrincessSophia]

в план тестирования, конкретно в раздел - стратегия тестирования... ага, для начальства )

Обычно для начальства дают отчеты по тестированию где обычно черным по белому написано кто, когда и какие тесты делал.... Иногда такие отчеты генерируются автоматически....
Что именно вы хотите считать? Сколько раз выполнен один тест case?
группа тестов?

[AIN]

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

[Guriy]

в план тестирования, конкретно в раздел - стратегия тестирования... ага, для начальства )

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

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

[Ekaterina]

раунд тестирования это один цикл чтоли... первый раз про раунды слышу :)

"да это тестеры все так плохо протестировали",

я тут единственный тестер на всех программеров %)

[Angela]

раунд тестирования это один цикл чтоли... первый раз про раунды слышу :) 

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

[Ekaterina]

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

[Mike]

Екатерина, если вы действительно так делаете, то значит что у Вас просто очень "незрелый" (в смысле CMM - Capability Maturity Model) процесс тестирования. Советую почтиать RUP (Rational Unified Process, часть Rational Suite). Если же Вы не считаете нужным писать тест-планы, но можно использовать альтернативный способ управления тестированием - так называемый "session-based test management (explaratory testing)". Но и при этом способе, обойтись без планирования не удастся. Рекоммендую следующую ссылочку: http://www.satisfice...btm/index.shtml

[Azart]

а тупо тыкаюсь по всему функционалу...

Лучше тыкать с пониманием.

Если же Вы не считаете нужным писать тест-планы, но можно использовать альтернативный способ управления тестированием - так называемый "session-based test management (explaratory testing)". Но и при этом способе, обойтись без планирования не удастся.

Очень интересно, что вы понимаете под планирование в данном контексте.

Для тестирования некоторых приложений, процесс планирование тестов сводится к простому перечню необходимых проверок(Доки, инсталяции, Гуи, функциональность). В основном это касается систем с динамически меняющейся информацией, такие как системы безопасности(видеонаблюдения).
Я это всё свожу к тому, что иногда тыкание по функционалу, С ПОНИМАНИЕМ намного выгоднее, чем планирование, а потом тупое следование тестплану.

[Mike]

Azart, cпециально-же ссылку давал... Session-based test management тем и отличается от, так скажем, test plan-based testing что тестплана не требуется. Вместо test-plan'a используется чек-лист. То есть, перед тем как тестить вы описываете какие баги собираетесь искать, в каком функционале и ссылочку на Requirements. Ну а в логе уже описывете как это делали... Но чек-лист писать всё-же прийдётся. И подумать для начала, как тестировать - тоже.