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

[floyder]

Добрый день, коллеги!
Многие из нас встречались с ситуациями, когда динаимично развивающийся продукт пересыщается функционалом. Он становится неподъемным, и вероятность найти критичную багу в рандомном месте стремится к 1.
Расскажите пожалуйста как вы справляетесь с такими проблемами.

Моя вводная:
Прикладное приложение. Число тестовых шагов перевалило за 15000. Выпуски версий каждые 2 недели. При этом изменение функционала каждую итерацию происходит на 1000-2000 пользовательских действий. Также за итерацию на тест передается от 6 до 15 сборок-кандидатов, которые необходимо подвергнуть общему тесту. Имеем команду из 4-х тестировщиков: 1 штатный и 3 аутсорсера-багхантера.
Случается, что каждую итерацию тестировщики пропускают 2-3 критичных бага. Причем некоторые лежат на поверхности настолько, что вызывают недоумение у других коллег.
Пробовали тестировать на основе рисков - нереально выделить приоритетные места. Специфика отрасли такова, что разные клиенты по-разному интерпретируют дефекты, и порой критичность совершенно безобидного (на первый взгляд) бага становится максимальной, так как этого затребовал влиятельный заказчик.
Пробовали автоматизацию тестирования. Каждый год у приложения меняется платформа, и составить адекватную базу автоматизации оказалось не выгодно и не удобно.

Подскажите, куда копать, чтобы снизить риски сбоев. Может есть управленческие хитрости или интересные инструменты, способные помочь в ситуации. Сами используем TFS + Visual Studio.
Спасибо за внимание!

[CVDX]

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

Скажите, эти критичные баги на поверхности того функционала, который был протестирован тестером?
Или по каким-то причинам нет?
То есть, личный прокол некоего тестера или скорее недочет тестовой стратегии/манагера или кадровой политики в общем.

[Future]

Могу сказать по себе, т.к. мне приходится тестировать около 10 приложений с совершенно разным бизнесом. Есть такой эффект, под названием "Замыливание глаза", т.е. когда ты привыкаешь к приложение и даже очевидные вещи перестаёшь замечать. Мне помогает переключение на другое приложение, а потом снова возврат к нужному. В вашем случае можно пробовать менять тестировщиков, благо с удалёнкой проблем нет, при условии позволения таких действий со стороны руководства.

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

[Vasiliy]

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

И получите вы набор багов типа "Здесь не хватает запятой, тут шрифт не тот и еще картинки некрасивые". А за серьезными вещами никто не будет следить, так как времени на это уходит на порядок больше.

[kitsune]

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

Я бы на этих 2-3х критичных посмотрела процент утечки (defect leakage) и анализ танцевала скорее от неё, чем от чистого количества.

Может выйти так, что Вам просто людей не хватает.

Плюс раскопать, какое соотношение между утёкшими по типам:
- "некоторые [критичные] лежат на поверхности"
- "порой критичность совершенно безобидного (на первый взгляд) бага становится максимальной".

Это две разные темы, разные решения.

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

Сообщение отредактировал kitsune: 19 сентября 2012 - 09:41

[Future]

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

И получите вы набор багов типа "Здесь не хватает запятой, тут шрифт не тот и еще картинки некрасивые". А за серьезными вещами никто не будет следить, так как времени на это уходит на порядок больше.

А как насчет ввести "Весовой коэффициент" бага? Самые дорогие, например, перфомансного плана, а опечатки и прочая подобная фигня с неприлично низким коэффициентом.

[Vasiliy]

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

[Wolonter]

Как проходит BVT? Может объем тестов, выполняемых для проверки пригодности билда недостаточен? Их нужно больше? Они нужны в другом месте?

Если 3-4 пропускают, значит еще 30-40 не пропускают, так? Значит их пишут. Кто их пишет? Почему? Есть ли возможность влиять на программистов, на процесс разработки?

Возьмите десяток, проведите полное расследование, выясните причины появления. Может быть с ними что-то удастся сделать. Уточнить постановку, отодвинуть стол от окна, отрефакторить модуль. Хорошенько отмотивировать.
Как бы качественно ни проходило тестирование, баги надо не писать, а уже потом качественно искать.

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

[floyder]

kitsune
Статистику поднять можно. Но к ней нужны конкретные пути решений. Допустим, мы узнали, что defect leakage слишком большой. Что с этим делать?

Мне помогает переключение на другое приложение, а потом снова возврат к нужному.

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

Багхантинг не лучшая практика и приводит к

И получите вы набор багов типа "Здесь не хватает запятой, тут шрифт не тот и еще картинки некрасивые". А за серьезными вещами никто не будет следить, так как времени на это уходит на порядок больше.

а применение

А как насчет ввести "Весовой коэффициент" бага?

приводит к конфликтам, тк "Весовой коэффициент" - экспертная оценка и зависит от мнения конкретной личности.

Скажите, эти критичные баги на поверхности того функционала, который был протестирован тестером?
Или по каким-то причинам нет?
То есть, личный прокол некоего тестера или скорее недочет тестовой стратегии/манагера или кадровой политики в общем.

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

Можно ли как-то роботизировать данный процесс?

[kitsune]

kitsune
Статистику поднять можно. Но к ней нужны конкретные пути решений. Допустим, мы узнали, что defect leakage слишком большой. Что с этим делать?

Всё то же самое, что Вы делаете сейчас, но танцуя от относительно более объективной цифры.

[Vita]

Добрый день, коллеги!
Многие из нас встречались с ситуациями, когда динаимично развивающийся продукт пересыщается функционалом...
Специфика отрасли такова, что разные клиенты по-разному интерпретируют дефекты, и порой критичность совершенно безобидного (на первый взгляд) бага становится максимальной, так как этого затребовал влиятельный заказчик.

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

Мой знакомый: "Я в Германии закончил заочно институт - факультет информатики, так что мы в каком-то роде коллеги. Хотя по этой специальности я не работаю. Наше правительство очень умно поступило - лет 8 назад была большая нехватка программистов и прочих IT-шников, так они зеленые карты выдавали всем, кому не лень. Теперь перебор, программистов, никому не нужны. Поэтому я даже уже и не хочу искать. Работа в сфере информатики здесь очень сильно связана со стрессом и частой работой по выходным".

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