Comments 14
А не могли бы вкратце рассказать, что такое ручные тесты?) Вдруг как-то веду их учет, и сам не знаю.
а то гугл выдает что-то в духе
>Hand-тест используется в клинической практике для выявления пациентов, склонных к деструктивному разрушительному поведению; в силовых структурах, профессиональном спорте — для отбора лиц, обладающих адекватной агрессией и «бойцовскими» качествами; в системе исполнения наказаний — для прогноза рецидивов и агрессивной делинквентности среди правонарушителей; в сексологии — для исследования особенностей психосексуальной ориентации, прогноза сексуальной агрессии и т. д.
а то гугл выдает что-то в духе
>Hand-тест используется в клинической практике для выявления пациентов, склонных к деструктивному разрушительному поведению; в силовых структурах, профессиональном спорте — для отбора лиц, обладающих адекватной агрессией и «бойцовскими» качествами; в системе исполнения наказаний — для прогноза рецидивов и агрессивной делинквентности среди правонарушителей; в сексологии — для исследования особенностей психосексуальной ориентации, прогноза сексуальной агрессии и т. д.
Ох. На сленге всех тестировщиков, с которыми я общался, принято разделять тесты на
* автоматические — стандартные юниттесты, встроенные в код, которые пишут программисты, либо хитрым раком автоматизированные тесты, тестирующие программу как «черный ящик» — записанные сценарии эмулирующие пользователя, мучающие программу через веб или обычный GUI-интерфейс. Сии тесты, будучи автоматическими, относительно дешево прогонять, и можно автоматически получить все результаты, не вмешивая людей.
* ручные. Т.е. вручную выполняемые человеком, на вход которому подается программа, кофе, и некоторое описание процесса — это могут быть сценарии тестирования (тест-кейсы), могут быть просто требования заказчика или просто описание функционала (по сути, некоторая дженерализация тест-кейсов). Автоматика с большой буквы ©Пелевин, так сказать.
Чтобы навести некоторую предсказуемость в этом процессе, требуется учет.
Обычно его ждут от «специально обученных» Test Management систем, но на практике, по моему опыту их мало кто использует… Собственно в этом я собираюсь еще раз убедиться, на широкой аудитории. Ну или разубедиться.
P.S. Если хотите гуглить англоязычный интернет, то, ручной там не «hand», а «manual».
Ну и вообще, кэп рекомендует en.wikipedia.org/wiki/Test_management
* автоматические — стандартные юниттесты, встроенные в код, которые пишут программисты, либо хитрым раком автоматизированные тесты, тестирующие программу как «черный ящик» — записанные сценарии эмулирующие пользователя, мучающие программу через веб или обычный GUI-интерфейс. Сии тесты, будучи автоматическими, относительно дешево прогонять, и можно автоматически получить все результаты, не вмешивая людей.
* ручные. Т.е. вручную выполняемые человеком, на вход которому подается программа, кофе, и некоторое описание процесса — это могут быть сценарии тестирования (тест-кейсы), могут быть просто требования заказчика или просто описание функционала (по сути, некоторая дженерализация тест-кейсов). Автоматика с большой буквы ©Пелевин, так сказать.
Чтобы навести некоторую предсказуемость в этом процессе, требуется учет.
Обычно его ждут от «специально обученных» Test Management систем, но на практике, по моему опыту их мало кто использует… Собственно в этом я собираюсь еще раз убедиться, на широкой аудитории. Ну или разубедиться.
P.S. Если хотите гуглить англоязычный интернет, то, ручной там не «hand», а «manual».
Ну и вообще, кэп рекомендует en.wikipedia.org/wiki/Test_management
а, спасибо, понятно.
сразу не понял, какой вообще смысл описывать словами (и где-то еще учитывать) то, что можно с примерно теми же усилиями описать в терминах какой-то утилиты автоматического тестирования, отсюда подозрение (не оправдавшееся) что ручные тесты — не антоним автоматизированных, а что-то другое )
сразу не понял, какой вообще смысл описывать словами (и где-то еще учитывать) то, что можно с примерно теми же усилиями описать в терминах какой-то утилиты автоматического тестирования, отсюда подозрение (не оправдавшееся) что ручные тесты — не антоним автоматизированных, а что-то другое )
Ты удивишься, но ручные тесты занимают огромную область в производстве ПО. В частности индусы отдают в аутсорс, помимо программинга, ещё и тестировщиков — и именно на ручные тесты. Просто многие области не так просто и не так быстро автоматизируются, чтобы отказаться от «ручников». Мой пример «под боком» — тестирование сотовых.
Однажды наблюдал как народ пытался насаждать добро TestLink палками но тестировщики, которые больше года монотонно сортировали doc-файлы по папкам и подпапкам, просто не поняли бенефитов которые он мог принести и после двух месяцев идея скисла.
Да, мы тоже пробовали TestLink и QATraq. С платными тулами, кстати, ситуация не лучше, несмотря на их платность.
У меня сложилась некоторая теория, почему это не взлетает, и что может взлететь.
Через полторы недели расскажу на одной конфе.
Тут решил просто сделать контрольный выстрел, еще раз проверить статистику. Выборка конечно неидеальная, но где же идеальную взять…
У меня сложилась некоторая теория, почему это не взлетает, и что может взлететь.
Через полторы недели расскажу на одной конфе.
Тут решил просто сделать контрольный выстрел, еще раз проверить статистику. Выборка конечно неидеальная, но где же идеальную взять…
Эх… человеческий фактор. Объективно спец. системы управления тестами — лучше. Однако не всем это очевидно.
По существу вопроса. В Motorola использовали TestCentral — огромный монструозный комплекс, предназначенный для больших команд.
Сейчас, если бы понадобилось вести инфу по тестам, выбрал бы решение на базе issue tracker'а. Просто обточил бы жизненный цикл issue, считая одну запись — одним атомарным тест-планом. Скажем, одна запись — группа связанных тест-кейсов, или даже на один тест-кейс (но большой). Ну и для очередного прогона просто клонировал бы записи. Просто, но для малых-средних проектов вполне. Проголосовал за этот вариант.
По существу вопроса. В Motorola использовали TestCentral — огромный монструозный комплекс, предназначенный для больших команд.
Сейчас, если бы понадобилось вести инфу по тестам, выбрал бы решение на базе issue tracker'а. Просто обточил бы жизненный цикл issue, считая одну запись — одним атомарным тест-планом. Скажем, одна запись — группа связанных тест-кейсов, или даже на один тест-кейс (но большой). Ну и для очередного прогона просто клонировал бы записи. Просто, но для малых-средних проектов вполне. Проголосовал за этот вариант.
Да, у нас пока доминирует именно issue-подход.
Местами наблюдаю подход от вики-систем (где как правило лежат требования, и там же тесты и прочее).
Ну, а вообще, везде (и среди знакомых), особенно где коллаборативность не жмет, доминирует супер KISS подход с вордами-экселями.
Местами наблюдаю подход от вики-систем (где как правило лежат требования, и там же тесты и прочее).
Ну, а вообще, везде (и среди знакомых), особенно где коллаборативность не жмет, доминирует супер KISS подход с вордами-экселями.
Кстати, ещё одно дополнение, может быть, пригодится для статьи.
Итак, у нас в мотороле тесты лежали в test central. Команд тестирования было 4 «на пике активности». Так вот, чтобы распределять прогон тест-свитов между командами пробовали разные подходы. Проблема была действительно глобальной, т.к. координация работы — вообще штука непростая, а тут процесс вообще непрерывный должен был быть.
Первым решением было использовать Вики — благо она уже использовалась внутри команды для разных целей. Было предложено и внедрено вести табличку на каждый день — какая команда на каком продукте какой test suit прогоняет. По окончании работы или же когда надо было передать следующйе команде, из соседней временной зоны — делась запись в строчке напротив прогона. Там указывался статус (закончено-прервано и т.п.) и промежуточные результаты. Кроме того, в Test Central Всегда можно было посмотреть текущее состояние дел. Когда начинался новый день, центральный менеджмент заводил новую страничку и переносил туда неоконченные активности — и всё продолжалось.
Однако такой подход оброс оброс проблемами:
— невозможность одновременного редактирования (а если залочил страницу и забыл снять лок — караул, все ждут одного)
— перезаписывание чужого текста (тупо по неаккуратности)
— необходимость большого кол-ва ручных действий
Было предложено использовать issue tracker eTraxis (http://etraxis.org). Его создатель был как раз начальником отдела СМ в нашей компании — и моим непосредственным начальником.
Немного обточили саму систему, пропилотировали на одном из подпроектов. В итоге что получилось и что использовалось (и, наверное, используется до сих пор).
— заведены отдельные шаблоны для контроля за работой тестовых команд
— для одного прогона test suite заводится одна запись и назначается на команду — и через её руководство на отдельного тестера.
— для разбиения на несколько человек заводятся подчиненные («вложенные») задачи
— по окончании работы запитсь переводится в промежуточное состояние с описанием результатов
— если другая команда подбирает задачу — она записывает её на себя.
— по окончании работы запись закрывается ответственным за отслеживание тестирование (в нашем случае это был СМ-инженер, как ни странно)
В итоге, все недостатки Вики были преодолены, появилась ясность в работе. Менеджмент доволен — они могут отлично отслеживать кто чем занят и что сейчас в работе. Тестеры тоже — у них появилась ясность в задачах.
Итак, у нас в мотороле тесты лежали в test central. Команд тестирования было 4 «на пике активности». Так вот, чтобы распределять прогон тест-свитов между командами пробовали разные подходы. Проблема была действительно глобальной, т.к. координация работы — вообще штука непростая, а тут процесс вообще непрерывный должен был быть.
Первым решением было использовать Вики — благо она уже использовалась внутри команды для разных целей. Было предложено и внедрено вести табличку на каждый день — какая команда на каком продукте какой test suit прогоняет. По окончании работы или же когда надо было передать следующйе команде, из соседней временной зоны — делась запись в строчке напротив прогона. Там указывался статус (закончено-прервано и т.п.) и промежуточные результаты. Кроме того, в Test Central Всегда можно было посмотреть текущее состояние дел. Когда начинался новый день, центральный менеджмент заводил новую страничку и переносил туда неоконченные активности — и всё продолжалось.
Однако такой подход оброс оброс проблемами:
— невозможность одновременного редактирования (а если залочил страницу и забыл снять лок — караул, все ждут одного)
— перезаписывание чужого текста (тупо по неаккуратности)
— необходимость большого кол-ва ручных действий
Было предложено использовать issue tracker eTraxis (http://etraxis.org). Его создатель был как раз начальником отдела СМ в нашей компании — и моим непосредственным начальником.
Немного обточили саму систему, пропилотировали на одном из подпроектов. В итоге что получилось и что использовалось (и, наверное, используется до сих пор).
— заведены отдельные шаблоны для контроля за работой тестовых команд
— для одного прогона test suite заводится одна запись и назначается на команду — и через её руководство на отдельного тестера.
— для разбиения на несколько человек заводятся подчиненные («вложенные») задачи
— по окончании работы запитсь переводится в промежуточное состояние с описанием результатов
— если другая команда подбирает задачу — она записывает её на себя.
— по окончании работы запись закрывается ответственным за отслеживание тестирование (в нашем случае это был СМ-инженер, как ни странно)
В итоге, все недостатки Вики были преодолены, появилась ясность в работе. Менеджмент доволен — они могут отлично отслеживать кто чем занят и что сейчас в работе. Тестеры тоже — у них появилась ясность в задачах.
Ну да. Достаточно очевидный подход.
Минусы — вся атрибутика крутиться вокруг «прогонов как заданий». Атрибутика «тесты в разных окружениях, с историей» теряется.
В идеале ведь хочется не перечитывать задание, выясняя, что протестировано, а что нет, а четко видеть галочки и состояния в прогоняемой тестовой сюите.
Вики-подход кстати можно было бы довести до ума — только сделать быстрое неблокирующее редактирование статусов (это немного AJAX — ткнул и статус поменялся, не надо муторно редактировать текст).
И странно, что у вас блокирующаяся вика была, нормальные обычно не блокируют и вполне мерджат изменения.
Ко вторнику я доделаю презентацию и покажу тебе…
Минусы — вся атрибутика крутиться вокруг «прогонов как заданий». Атрибутика «тесты в разных окружениях, с историей» теряется.
В идеале ведь хочется не перечитывать задание, выясняя, что протестировано, а что нет, а четко видеть галочки и состояния в прогоняемой тестовой сюите.
Вики-подход кстати можно было бы довести до ума — только сделать быстрое неблокирующее редактирование статусов (это немного AJAX — ткнул и статус поменялся, не надо муторно редактировать текст).
И странно, что у вас блокирующаяся вика была, нормальные обычно не блокируют и вполне мерджат изменения.
Ко вторнику я доделаю презентацию и покажу тебе…
Насчет атрибутов — как я уже сказал, трекер был дополнением для отслеживания именно ответственности и задач. Сами прогоны и планы хранились в спецсистеме.
А вот если использовать трекер как хранилище, где каждый тест — это запись, то там вполне нормально всё должно укладываться, включая атрибуты и подробности прогона.
А что до вики — да, она была достаточно убога. Благодаря этому и стал очевиден переход на другие средства ;)
А вот если использовать трекер как хранилище, где каждый тест — это запись, то там вполне нормально всё должно укладываться, включая атрибуты и подробности прогона.
А что до вики — да, она была достаточно убога. Благодаря этому и стал очевиден переход на другие средства ;)
Голосующие за «Что-то не подпадающее под перечисленные категории» — очень большая просьба написать-намекнуть, что же у вас это такое, для чего я не догадался завести категорию.
Sign up to leave a comment.
Как вы ведете учет ручных тестов? TestManagement-системой или иначе? (опрос для статьи/конференции)