I would love to Beta test Dorico. I am the Assistant Professor of Music Technology and Music Theory/Composition at Texas Christian University. I am so excited about your new notation software and would love to have the opportunity to help. I would use this for composing acoustic and electronic music. I would also be hoping to use a variety of AU and VST’s with the notation software. Does anyone know how to sign up for the beta?
Thanks for your interest in beta testing Dorico. I’m sure you will appreciate that we have had many, many hundreds of people request to join our beta testing team, and we will not be able to accommodate everybody who has expressed an interest.
We will publish information about how to apply to get involved in the beta testing programme on the Making Notes blog when the time comes, but it may well be that we end up with some kind of a lottery system to select testers, as I expect we will be overwhelmed with applications at that time.
Hmm. If it were me I would want a smaller number of high-quality testers, covering a variety of usecases (e.g. some focussed on VST3 plugins, some only using the bundled sounds; some who use QWERTY note entry, some who use MIDI etc. etc.) I would want to be sure that people were willing to put time into the software and providing high quality feedback, not just curious and wanted to play with it. I would also want people who have some experience of testing software and know how to provide good bug reports.
Daniel knows a thing or two about assembling beta testers.
Yes, I was surprised that a lottery was being considered.
You don’t have to let EVERYONE enter a lottery.
Well, a beta-test is a serious thing… one cannot just play around. Candidates will need to know how to use such a program on a high professional basis to identify misbehaviour and bugs.
Or in other words one at least should know something about music-notation 
What I know about beta testing you could write on the back of a postage stamp - but strictly in product development terms, surely the goals of pre-release testing aren’t just to find misbehaviour and bugs? I would have thought that feedback from beta testers on functions, usability, speed, quality, learning curve etc. would be just as relevant.
In the phase of Beta testing it is almost too late for changes. Beta tests are mainly to test a program in a user environment when shared DLLs, drivers etc. can cause problems. It is a test in “real” life, so to speak.
But a feedback is always welcome.
But of course I cannot tell how Steinberg understands beta testing and whether or not they can change tremendous issues in the usability in such a short time.
What they expect a beta tester to report can only be answered by Steinberg, so… 
I beta tested several years for Steinberg in the early days (Cubase, Wavelab etc) and while it is a honor to be accepted to the team it is also a lot of work, emails, testing and such: the creative work may/will suffer. That is why I would say that people who work on “real” compositions that need to be done in time should consider twice before taking part in beta testing. You may lose your work with crashes, incompatibilities with beta file structures etc. Been there, done that. Still, it was fun!
Yes, but it is also about getting “a fuzzy” sample of usage patterns that may not occur to developers - in other words, doing things the wrong way may also produce valuable errors and info. Of course, the main goal (usually) is to make sure what it says in the manual works so.
The really important thing in beta testing is to honor the confidentiality agreement and keep the beta versions out of circulation.
Programming tools are today very versatile and object oriented code makes even big alterations possible, something else than writing assembly and hex tables in the old days The other things is that in a beta stage the manual is already written, mostly, and the threshold of making alterations to the usability, graphics or features is very high.
I never did beta testing for Steinberg but for some other competitors some years ago. I made some suggestions regarding to the work-flow but was told that adding features is one thing but keeping a continueos flow so that it fits the general workflow another.
But finally they added those suggestions a version later
But thanks for sharing your thoughts and experience. Those details give us a a better picture of what we should expect…
My own experience is that the documentation department is usually regarded as “they will handle it” and the programmers thus do what they want, when they want. To picture it: Imagine the programmers in a cigarette speed-boat drinking champagne, and the manual authors on water-skies 300 meters behind, in fear of what next 90-degree turn will result in. 
With modern tools and modular build for documentation and semi-automated localization it is not that difficult to make changes close to release. As there will be no(?) printed (ref.) manual, last minute changes are easy, and low-cost (compared to printed manuals).