Добрый день, коллеги!
Многие из нас встречались с ситуациями, когда динаимично развивающийся продукт пересыщается функционалом. Он становится неподъемным, и вероятность найти критичную багу в рандомном месте стремится к 1.
Расскажите пожалуйста как вы справляетесь с такими проблемами.
Моя вводная:
Прикладное приложение. Число тестовых шагов перевалило за 15000. Выпуски версий каждые 2 недели. При этом изменение функционала каждую итерацию происходит на 1000-2000 пользовательских действий. Также за итерацию на тест передается от 6 до 15 сборок-кандидатов, которые необходимо подвергнуть общему тесту. Имеем команду из 4-х тестировщиков: 1 штатный и 3 аутсорсера-багхантера.
Случается, что каждую итерацию тестировщики пропускают 2-3 критичных бага. Причем некоторые лежат на поверхности настолько, что вызывают недоумение у других коллег.
Пробовали тестировать на основе рисков — нереально выделить приоритетные места. Специфика отрасли такова, что разные клиенты по-разному интерпретируют дефекты, и порой критичность совершенно безобидного (на первый взгляд) бага становится максимальной, так как этого затребовал влиятельный заказчик.
Пробовали автоматизацию тестирования. Каждый год у приложения меняется платформа, и составить адекватную базу автоматизации оказалось не выгодно и не удобно.
Подскажите, куда копать, чтобы снизить риски сбоев. Может есть управленческие хитрости или интересные инструменты, способные помочь в ситуации. Сами используем TFS + Visual Studio.
Спасибо за внимание!
Здравствуйте, i_kruk, Вы писали:
_> Подскажите, куда копать, чтобы снизить риски сбоев. Может есть управленческие хитрости или интересные инструменты, способные помочь в ситуации. Сами используем TFS + Visual Studio.
Копать в сторону того, чтобы вносить меньше багов, а не находить больше.
Здравствуйте, i_kruk, Вы писали:
_> Случается, что каждую итерацию тестировщики пропускают 2-3 критичных бага. Причем некоторые лежат на поверхности настолько, что вызывают недоумение у других коллег.
пишите больше проверок инвариантов. assert'ы или как оно там в дотнете
_> Пробовали автоматизацию тестирования. Каждый год у приложения меняется платформа, и составить адекватную базу автоматизации оказалось не выгодно и не удобно.
должен же быть какой-то код, не зависящий от платформы.
можно ввести дополнительные слои абстракции, чтобы он появился.
In Zen We Trust
Re[2]: Динамичная разработка и тестирование - Проблемы и решения
Здравствуйте, rlabs, Вы писали:
R>Здравствуйте, i_kruk, Вы писали:
_>> Подскажите, куда копать, чтобы снизить риски сбоев. Может есть управленческие хитрости или интересные инструменты, способные помочь в ситуации. Сами используем TFS + Visual Studio.
R>Копать в сторону того, чтобы вносить меньше багов, а не находить больше.
Как тестировщики могут этому поспосбоствовать?
Re[3]: Динамичная разработка и тестирование - Проблемы и решения
Здравствуйте, i_kruk, Вы писали:
R>>Копать в сторону того, чтобы вносить меньше багов, а не находить больше.
_> Как тестировщики могут этому поспосбоствовать?
Ну, это непросто. Если у вас код так подвержен ошибкам, особенно это касается регрессионных — причина не в тестировании, а в том, что код плохой. Применение человека-тестировщика для поиска тупых багов — неоправданно медленно, дорого и унизительно.
Попробуйте найти для тестировщиков правильное место в процессе. Разберитесь, почему не работает "эффект пестицида". Помогайте писать модульные тесты — программисты могут быть еще и отличными тестировщиками, если их этому научить.
собственно, плохой код никаким тестированием не исправишь. только улучшением кода.
Здравствуйте, Abyx, Вы писали:
A>Здравствуйте, i_kruk, Вы писали:
_>> Случается, что каждую итерацию тестировщики пропускают 2-3 критичных бага. Причем некоторые лежат на поверхности настолько, что вызывают недоумение у других коллег.
A>пишите больше проверок инвариантов. assert'ы или как оно там в дотнете
_>> Пробовали автоматизацию тестирования. Каждый год у приложения меняется платформа, и составить адекватную базу автоматизации оказалось не выгодно и не удобно.
A>должен же быть какой-то код, не зависящий от платформы. A>можно ввести дополнительные слои абстракции, чтобы он появился.
Какой-то код есть, но тестировщики об этом не знают
Тестировщики тестят черным ящиком. Программисты пишут юнит тесты.
Поэтому тестерские проверки завязаны на пользовательский интерфейс. Кстати, часто случается, что какой-то контрол поменял свое название, и весь автоматизированный тест валится, так как не может найти нужный контрол.
Re[4]: Динамичная разработка и тестирование - Проблемы и решения
Здравствуйте, rlabs, Вы писали:
R>собственно, плохой код никаким тестированием не исправишь. только улучшением кода.
Тут скользкий вопрос. Плохой код или мало времени на разработку, а может недостаточно информации в ТЗ. В любом случае вряд ли какой-нибудь сотрудник хочет писать "плохой код"
R> Применение человека-тестировщика для поиска тупых багов — неоправданно медленно, дорого и унизительно.
С этим трудно поспорить. Однако кто-то или что-то должно это делать.
Re[3]: Динамичная разработка и тестирование - Проблемы и решения
Здравствуйте, i_kruk, Вы писали:
_>Какой-то код есть, но тестировщики об этом не знают _>Тестировщики тестят черным ящиком. Программисты пишут юнит тесты.
_>Поэтому тестерские проверки завязаны на пользовательский интерфейс. Кстати, часто случается, что какой-то контрол поменял свое название, и весь автоматизированный тест валится, так как не может найти нужный контрол.
Для тестирования тоже есть своя архитектура и паттерны
Если выделить логику поиска контролов на форме (по имени или еще как) в отдельный класс, то при изменении имени контрола достаточно будет поменять этот класс и все тесты починятся автоматом. Этот же прием спасает при изменении UI фреймворка, так как потребуется переписать только "классы обертки" форм.
Я называю этот паттерн FormObject (уже не помню где о нем услышал).
Сами тесты выглядят так:
var loginForm = new LoginForm(/*сюда можно передать все тчо нужно тестовому фреймворку, чтобы он смог "кликать" кнопки */);
loginForm.Username = "aikin";
loginForm.Password = "secret";
loginForm.LogMeIn();
Assert.That(loginForm.IsClosed); // Проверить можно все что угодно, например, что открылась другая форма или еще что
СУВ, Aikin
... << RSDN@Home 1.2.0 alpha 5 rev. 1539>>
Re[4]: Динамичная разработка и тестирование - Проблемы и решения
Здравствуйте, Aikin, Вы писали:
A>Если выделить логику поиска контролов на форме (по имени или еще как) в отдельный класс, то при изменении имени контрола достаточно будет поменять этот класс и все тесты починятся автоматом. Этот же прием спасает при изменении UI фреймворка, так как потребуется переписать только "классы обертки" форм. A>Я называю этот паттерн FormObject (уже не помню где о нем услышал).
Спасибо, интересное решение. И направление для развития
Как быть если мы не знаем, что контрол
а) изменился
б) переместился
в) был удален
?
Re: Динамичная разработка и тестирование - Проблемы и решения
Здравствуйте, i_kruk, Вы писали:
_>Здравствуйте, Aikin, Вы писали:
A>>Если выделить логику поиска контролов на форме (по имени или еще как) в отдельный класс, то при изменении имени контрола достаточно будет поменять этот класс и все тесты починятся автоматом. Этот же прием спасает при изменении UI фреймворка, так как потребуется переписать только "классы обертки" форм. A>>Я называю этот паттерн FormObject (уже не помню где о нем услышал).
_>Спасибо, интересное решение. И направление для развития _>Как быть если мы не знаем, что контрол _>а) изменился _>б) переместился _>в) был удален _>?
Не пробовали diff сорцов и отсев по контролам? Мы такое пробовали для Java. Но за ненадобностью отпало.
Re[5]: Динамичная разработка и тестирование - Проблемы и решения
Здравствуйте, i_kruk, Вы писали:
_>Здравствуйте, Aikin, Вы писали:
A>>Если выделить логику поиска контролов на форме (по имени или еще как) в отдельный класс, то при изменении имени контрола достаточно будет поменять этот класс и все тесты починятся автоматом. Этот же прием спасает при изменении UI фреймворка, так как потребуется переписать только "классы обертки" форм. A>>Я называю этот паттерн FormObject (уже не помню где о нем услышал).
У этого подхода есть много названий. Одним из популярных названий является PageObject pattern.
_>Спасибо, интересное решение. И направление для развития _>Как быть если мы не знаем, что контрол _>а) изменился _>б) переместился _>в) был удален _>?
Это может быть охвачено отдельными тестами, которые только и проверяют, что наличие UI-элементов. Данные тесты могут использоваться в качестве приемки для проведения автоматизированного тестирования. Но такую вещь надо либо сразу прикручивать, либо наращивать уже по мере добавления\изменения существующего UI. И да, это дополнительные затраты. Частично они могут упроститься за счет структуры фреймворка и возможностей тестового движка (например, возможность использовать рефлексию).
Re[5]: Динамичная разработка и тестирование - Проблемы и решения
Здравствуйте, i_kruk, Вы писали:
_>Спасибо, интересное решение. И направление для развития _>Как быть если мы не знаем, что контрол _>а) изменился _>б) переместился _>в) был удален _>?
Если честно, вопрос ставит в тупик. Ну не знаете и не знаете, и что? На что это влияет?
Если контрол изменился, то все тесты с его использованием повалятся. В ошибке будет что-то-типа "контрол МаленькаяСиняяКнопка не найден". В любом случае можно отдебажить тест и посмотреть что же там нажимается и почему валится.
Если же тесты не упали, то и фиг с ним -- пусть меняется.
СУВ, Aikin
... << RSDN@Home 1.2.0 alpha 5 rev. 1539>>
Re: Динамичная разработка и тестирование - Проблемы и решения
> Прикладное приложение. Число тестовых шагов перевалило за 15000. Выпуски версий > каждые 2 недели. При этом изменение функционала каждую итерацию происходит на
