4
В вашей практике, какие меры вы используете, чтобы узнать, когда пришло время прекратить тестирование приложения и перенести его на производство?Когда вы прекращаете тестирование?
A
ответ
8
Для проектов в моей организации, меры, я обычно использую следующие:
- Нет Критичность 1 (показать пробку) выдает
- Нет Уровень 2 (основные функции калеки) выдает
- Допустимого количества от проблем с серьезностью 3 (незначительная функциональность)
«Приемлемое число», естественно, очень смятое число, в зависимости от размера приложения и т. д. и т. д.
После выполнения этих предварительных условий у меня будет встреча всех заинтересованных сторон (руководство по обеспечению качества, руководство Dev, руководство по поддержке приложений и т. Д.) И ознакомьтесь со списком нерешенных вопросов и убедитесь, что существует соглашение о серьезность, возложенная на нерешенные вопросы. Как только я подтвержу, что нет проблем с выпуском «Сев 1» и «Сев 2», я получаю призывы «Go/No Go» от каждой заинтересованной стороны. Если все говорят «Пойдем», мне комфортно переезжать в «Производство». Если хотя бы одна из заинтересованных сторон говорит «Нет», мы изучаем причины «Нет» и, при необходимости, предпринимаем шаги для решения проблем, стоящих за этим.
В небольших проектах процесс может быть более упорядоченным, и если это всего лишь операция с одним человеком, ваш набор предварительных условий может быть намного проще, т. Е.«приложение обеспечивает разумную выгоду, имея (видимо) допустимое количество ошибок - давайте поместим его!». Пока преимущество, предоставляемое приложением, превзойдет раздражение ошибок, особенно если вы следуете «раннему и частому» релизу, который может сработать для вас.
1
На моем рабочем месте используется одна метрика, которая иногда используется, так это то, что мы достаточно хорошо протестировали, когда приступаем к поиску старых и незарегистрированных ошибок, присутствующих в последних версиях нашего продукта. Идея состоит в том, что если это ошибки, которые мы находим во время тестирования, и эти ошибки присутствуют годами, а клиент не жалуется на них, тогда мы, вероятно, безопасны для отправки.
Конечно, у вас также есть все ручные тесты, автоматические тесты, в которых разработчики также используют продукт, бета-версии и материалы для непрерывного тестирования, но используя количество ошибок, которые мы находим сейчас, которые присутствовали, но не сообщаются , в прошлых версиях была новая идея для меня, когда я впервые услышал ее.
3
Во-первых, вы никогда не прекращаете тестирование. Когда вы выполните, и вы его отпустите, все это означает, что ваши пользователи тестируют вместо вас.
Во-вторых, когда ваши всесторонние тестовые сценарии проходят с приемлемым уровнем сбоев, вы готовы двигаться дальше.
И, наконец, это очень специфично для вашего случая. По некоторым проектам у нас есть 3-недельный бета-тест, в котором многие люди могут взломать систему до самых маленьких изменений. В других областях (менее критичных) небольшие изменения могут быть вытеснены только кивком другого разработчика.
1
Когда все основные пробные пробки исчезли.
Серьезно, вы должны сделать тест приемки пользователей и позволить своим пользователям использовать вашу систему и выяснить, все ли они вырезаны для них. Если это непрактично, сделайте закрытую бета-версию с избранными пользователями, которые напоминают вашу целевую аудиторию.
Невозможно найти все ошибки в вашей системе, поэтому иногда единственное реальное правило - , просто отправьте его.
0
mharen,
Я считаю, что если у вас есть комплексные автоматизированные тесты, совершенно безответственно поставлять программное обеспечение, если все из них пройти. Автоматизированные тесты означают, что это области, которые являются либо основной функциональностью, либо ошибками, которые произошли в прошлом, о которых вы знаете, и можете исправить, чтобы иметь проходящий тест. Было бы безответственно поставлять программное обеспечение, которое не пропускает 100% своих автоматических тестов.
0
Джон,
Я не имею в виду тестовых сценариев подразумевает автоматизировано тестирование. Я имел в виду более традиционный подход к пошаговому списку того, что тестировать и как его тестировать.
При этом я не согласен с тем, что все автоматические тесты должны пройти. Все зависит от серьезности и приоритетности. В большом проекте у нас могут быть разработчики, которые не могут выполнить тесты, основанные на проблемах, сообщаемых пользователями. Поскольку мы не можем исправить каждую ошибку с каждой версией, это означает, что некоторые тесты просто не пройдут.
2
Одна интересная методология тестирования, которую я всегда хотел попробовать, - это «посев ошибок». Идея состоит в том, что у вас есть человек, который вводит умышленные ошибки в систему, которые попадают в разные категории.
Например:
- ошибки Cosmetic, орфографические и т.д.
- Non критические ошибки
- Критические ошибки и сбои
- проблемы данных. Ошибок не возникает, но что-то глубже в результатах.
- т.д.
Документы «» точно сеялки, что было изменено, чтобы вставить эти ошибки, так что они могут быть быстро отменены. Поскольку тестовая команда находит посеянную ошибку, они также находят реальные ошибки, но не знают разницы. Теоретически, если тестовая команда найдет 90% засеянных критических ошибок, то они, вероятно, нашли пропорциональное количество реальных критических ошибок.
Из этих статистических данных вы можете приступить к принятию решений, когда приемлемо иметь выпуск. Конечно, это не было бы даже близко к безупречному из-за случайного характера того, какие ошибки обнаруживаются (реальные или затраченные), но, вероятно, лучше, чем вообще не иметь представления о том, сколько ошибок вы могли бы выпускать.
0
Измерение количества времени тестирования, помещенного в продукт между «showstopper» или основными ошибками функциональности, может сообщить вам, что вы почти у цели. Во времена быстрого потока в продукте с новыми функциональными возможностями, для команды тестирования обычно обнаруживается, что большинство ошибок, о которых они сообщают, являются серьезными ошибками функциональности. По мере того, как с ними сталкиваются, часто возникает большое количество мелких, подходящих и законченных типов вопросов, направленных на улучшение гладкости и ясности взаимодействия; в совокупности они существенно влияют на качество продукции, но каждый из них не очень важен. По мере того как те становятся фиксированными и тестирование продолжается, вы, вероятно, продолжаете получать отчеты об ошибках, поскольку тестеры вставляют ошибки и необычные шаблоны использования.В этот момент это зависит от того, когда вы видите ценность бизнеса для выпуска и риск незаметных шоустов.