Вот несколько советов по бета-тестированию продукта, рассчитанного на широкую аудиторию, — того, что я называю «коробочным продуктом» (shrink-wrap). Они годятся для любых проектов — как коммерческих, так и open source: главное здесь не то, что вы на этом заработаете — деньги, пристальный интерес или признание коллег, а то, что продукт предназначен для многих пользователей, а не для внутреннего употребления.

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

2. Лучший способ заставить бета-тестера прислать вам отчет — воззвать к его психологической потребности быть последовательным. Нужно, чтобы он пообещал вам прислать отчет, а еще лучше организовать прием заявлений на участие в бета-тестировании. После таких позитивных действий, как заполнение бланка заявления и установка флажка рядом с текстом «Согласен незамедлительно сообщить свое мнение и прислать отчет об ошибках», гораздо больше людей стремится выполнить свое обещание.

3. Не надейтесь, что сможете пройти полный цикл бета-тестирования меньше, чем за 8-10 недель. Я пытался это сделать, но при всем желании это просто невозможно.

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

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

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

7. Даже если у вас есть процедура регистрации тестеров, лишь один из пяти зарегистрировавшихся пришлет вам отчет.

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

9. Минимальное необходимое количество серьезных тестеров (то есть тех, кто пришлет вам трехстраничный отчет о своих впечатлениях) — примерно 100. Если вы кустарь-одиночка, то с большим количеством вам и не справиться. Если у вас есть группа тестеров или менеджеров бета-тестирования, постарайтесь обеспечить по 100 серьезных тестеров каждому, кто сможет заниматься обработкой отчетов.

10. Даже если у вас есть процедура приема заявлений, лишь один из пяти зарегистрировавшихся действительно опробует продукт, прислав вам отчет. Поэтому чтобы получить, например, 300 серьезных тестеров для трех тестеров из отдела контроля, нужно принять 1500 заявлений. Меньше — и данных окажется недостаточно. Больше -и вы утонете в одинаковых отчетах.

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

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

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