Without question, this quote by the great statistician George E. P. Box certainly applies to software development in general and Beta testing in particular.

Beta testing is one of the most important phases of the software development lifecycle. Quality, performance, stability, security and reliability are some factors that are achieved by doing beta testing.

Beta testing is the best chance to find bugs and usability issues before a product is fully released. While internal testing can uncover many problems, nothing can truly simulate real users trying to complete real tasks.

HCL has released the 2nd code drop of the upcoming release of (Notes)/Domino “Danube” (12.0.2). Every customer with active maintenance can participate in the Early Access Program. The software is available for download at Flexnet. https://hclsw.co/flexnet

There is a forum where you can provide feedback https://hclsw.co/danube-eap-forum .

Tim Clark (HCL) recently said that “We’ve noticed that not many people are trying out the Domino Early Access drop.”

I do not know what the reasons are. I know for sure that Beta testing can be very time consuming. But you do not have to test all the features from a code drop. Test one feature and comment on everything you see or do not see during your test.

If you do not want to setup a machine just for the Beta testing, maybe Docker is an option for you. Daniel Nashed has done a great job providing Docker images for all kind of Domino server environments. https://opensource.hcltechsw.com/domino-container/

There are no guidelines how to do a Beta test. Also there is no “playbook” that gives step-by-step instructions how to test a feature.

It’s all up to you. Be smart, act stupid. Be a rogue. If you can break a feature, anybody can. Better this happens during Beta testing than in production, right?

If a feature works as described. OK. But I can assure you that in all the years I am participating in Beta programs there is always bits and pieces that needs to be changed to make a feature idiot proofed rock solid, make log messages and console output more understandable or improve useability. This all helps to build a great product. And you can be part of the process.

Always keep in mind that discovering the unexpected is more important than confirming the known.