К бете или не к бете.. это - [закрытый] вопрос

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

Я не согласен с обоими вашими делами.

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

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

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

Если вы ответите «да», тогда спроектируйте и соберите все и запустите его без бета-версии.

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

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

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

Так что бета, пока ваше содержание сердца.

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

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

Только тогда вы будете готовы к выпуск.

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

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

На данный момент вы готовы к выпуску,

Нет.

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

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

Мой ответ состоит в том, что есть много факторов, которые определят, что имеет больше смысла:

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

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

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

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

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

Несомненно, бета!

Некоторые преимущества периода бета-тестирования ...

• Повышение качества продукта, удобства использования и производительности
• Выявление ошибок
• Получение информации о том, как клиенты используйте свой продукт
• Оценивайте реакцию на новые функции
• Собирайте запросы на новые функции
• Оценивайте требования к поддержке продукта
• Идентифицируйте клиентов
• Получите отзывы клиентов
• Подготовьтесь к окончательному выпуску
• Повысьте шумиху о продукте выпуск

Запускайте быстро и повторяйте часто.