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

Question

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

Answer 1

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

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

«Приемлемое число», естественно, очень мягкое число, в зависимости от размера приложения и т. Д. И т. Д.

Как только эти предварительные условия будут выполнены, я проведу совещание всех заинтересованных сторон (руководитель по обеспечению качества, руководитель разработки, руководитель службы поддержки приложений и т. Д.), Рассмотрю список нерешенных вопросов и позабочусь о том, Серьезность назначается нерешенным вопросам. Как только я подтвердил, что не осталось невыполненных выпусков 1 и 2, я получу звонки «Go / No Go» от каждого заинтересованного лица. Если все говорят «Иди», мне комфортно переходить на «Производство». Если хотя бы одна заинтересованная сторона говорит «Не ходи», мы изучаем причины «Не ходи» и, при необходимости, предпринимаем шаги для решения стоящих за этим проблем.

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

Answer 2

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

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

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

Answer 3

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

Например:

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

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

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

Answer 4

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

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

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

Answer 5

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

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

Answer 6

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

Answer 7

Джон,

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

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

Answer 8

mharen,

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