Когда вы прекращаете тестирование?

Question

В вашей практике какие показатели вы используете, чтобы узнать, когда пришло время прекратить тестирование приложения и перевести его в рабочую среду?

Answer 1

Для проектов в моей организации я обычно использую следующие меры:

• Нет проблем с серьезностью 1 (показать стопор)
• Нет проблем 2-й степени тяжести (нарушена основная функциональность)
• Допустимое количество проблем серьезности 3 (незначительная функциональность)

"Приемлемое число" - это, естественно, очень мягкое число, зависящее от размера приложения и т.д.и т.д.

Как только эти предварительные условия будут выполнены, я проведу встречу всех заинтересованных сторон (руководителя отдела контроля качества, разработчика, службы поддержки приложений и т.д.), просмотрю список нерешенных проблем и удостоверюсь, что существует согласие относительно степени серьезности, присвоенной нерешенным проблемам.Как только я удостоверюсь, что нерешенных вопросов Sev 1 и Sev 2 нет, я получу звонки "Идти / Не идти" от каждой заинтересованной стороны.Если все скажут "Уходи", я спокойно перейду к Производству.Если хотя бы одна заинтересованная сторона говорит "Нет ходу", мы изучаем причины отказа и, при необходимости, предпринимаем шаги для решения стоящих за этим проблем.

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

Answer 2

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

Во-вторых, когда ваши комплексные тестовые сценарии пройдут с приемлемым уровнем сбоев, вы будете готовы двигаться дальше.

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

Answer 3

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

Например:

• Косметические, орфографические ошибки и т. Д
• Некритические ошибки
• Критические ошибки и сбои
• Проблемы с данными.Ошибок не возникает, но с результатами что-то не так.
• и т.д.

'seeder' точно документирует, что было изменено для вставки этих ошибок, чтобы их можно было быстро исправить.По мере того, как команда тестирования находит посеянные ошибки, они также находят реальные баги, но не понимают разницы.Теоретически, если команда тестирования обнаруживает 90% заданных критических ошибок, то они, вероятно, обнаружили пропорциональное количество реальных критических ошибок.

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

Answer 4

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

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

Answer 5

Когда все основные заторы на шоу уйдут.

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

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

Answer 6

марен,

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

Answer 7

Джон,

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

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

Answer 8

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