Introduction to QA

Everything that's relevant to you as someone who wants to be on the QA Team, i.e. testing Alpha and Beta versions, and possibly contributing to LA Tech.

Summary

  1. You need a working Resonic Pro license for testing (see below)
  2. You have to be on Discord — discord.liqube.com
  3. Text channels: #betatest + #alphatest, Voice channels: studio + kitchen
  4. Report back every now and then, but on a regular basis
  5. Stick to current objectives, if there are any

Some Discord channels are locked, please request to be added to them.
Nicknames of active testers have a yellow tint.

Links

Documentation — How to handle Test builds (Alpha/Beta)

Latest Test Builds — stuff.liqube.com + betatest + alphatest
Latest Diff — stuff.liqube.com/diff
Official Releases — download
Forums — forums.liqube.com
Bug Tracker — bugs.liqube.com (if you prefer this method)
Facebook Page — facebook.com/resonicplayer
Facebook Users Group — users.resonic.at

You need a Pro license

As a tester you don't need to buy a Resonic Pro license.

Email or PM us your full name and email.

You'll receive a QA License, i.e. quality assurance, which allows you to test every build we release in full and without restrictions. You can also run official releases with your license.

To avoid hit and runs (see below) all QA Licenses are time-limited and expire after a few months. They are renewed on an activity basis, really meaning as long as you don't completely disappear.

Keep in touch

From testers we do expect that they're in touch every now and then and deliver something, even if it's just a heads-up about not having found anything new, or about not having too much time on their hands.

Your extra set of eyes and brain is the help we need. But it's only a help if you come to us with your findings and updates. Handling one tester is not a big problem, but the more there are the harder it becomes to keep tabs on everyone's progress.

How to Test

Stability and flawless function is the main goal.

Testing shouldn't be tense, mechanical, or over-complicated, but we generally work closely with our users and testers.

Get the latest .msi file (Setup version) or .zip (Portable version) from the stuff space. Higher build number means newer builds.

Everybody has their own way of testing software and we're not going to force ours onto you:

Test whatever you want in any order, but report back on some kind of regular basis. Go into detail with each new feature you can relate to, torture it, try to break it. Stay in a chat channel and report things as they happen, retreat for a few days, take notes, and come back with the results, use the forums, or the bug tracker, it's all up to you.

Sometimes we set objectives, things to focus on, things that need most testing at the moment.
Typically it's certain features that are going to be in the next release.

Where to Report

We primarily use Discord for testing.

Use the private #alphatest and #betatest channels for discussion. As a tester make sure you have access to them. Your nick name should appear in a yellow tint.

Anything related to official builds, or anything that might be of general interest, belongs in #bugs, #suggestions, or #resonic.
These channels are public, everyone can see what you post there. Other people might join in to the conversion.

There are public voice channels for group talks and brainstorming.

It is encouraged to use our new bug tracker to report bugs and suggestions as well, but either way is fine.

Change Logs

Make it a habit to read the changelogs for every new build. They tell you what has been added or modified.
They are called the same as the build .zip, but with .txt extension, and are also included with every build and release (whatsnew.txt).

To help you spot the differences between builds we have created a little online diff tool. It uses the latest build's changelog on the right, and some recent milestone on the left: stuff.liqube.com/diff

File Naming Scheme

The naming scheme of all Setup and Portable builds sticks to:

resonic[pro][-alpha][-beta][-major.minor.revision.build][.msi|zip]

For example:

resonicpro-alpha-0.9.4.1941.zip

That's it, really

You know where to get the latest builds from.
If you feel like there's more to be added here, say so.

See you on Discord.

Terminology

As part of the QA Team you should know the terminology we used in the past, and are still using now:

Alpha
The first phase of new software is usually called Alpha, and we used this label for the first few releases, but won't be using it again, except maybe for new products.
Beta
Resonic has been a permanent Beta and never really left this phase, which means that we haven't had a standard beta/release cycle so far, but unstable/Beta. We'll leave the permanent beta phase with the 0.9.4 release.
Unstable
Special builds that are intended for preview and testing purposes only, never intended for production use. This is really what should be beta in a healthy beta/release cycle. Unstables will become Alphas after the 0.9.4 release.
Early Access
The phase we're in where Resonic is sold for an introductory price, and to support further development, without resorting to other forms of crowd-funding. We intend on leaving this phase sometime after the 0.9.4 release.
Pre Release
Any build not intended for public release, i.e. unstable, alpha, beta (in a normal cycle), release candidate.
setup
The Windows Installer .msi version of Resonic that can be installed properly into your system's Program Files folder.
portable
The .zip version of Resonic that is not installed, but can simply be unpacked into a location with write-access, e.g. your Desktop, and run from there. All files remain in that folder, and it can be deleted after testing without leaving behind any traces. All Alpha versions are portable versions.
deployment
The automated process of preparing, building, and packaging a version of a program so that it can be delivered to the testers, or end users.
build
What a program is called after being built
build number
A number that increases between successful builds, it describes how often the build process had to run to get to this version. Typically identifies one unique version of a program, and is part of the version number.
version
We use two or three part version numbers (major.minor.revision) and a build number, e.g. 0.9, 0.9.4, 0.9.4.1941. The revision part may go past 9, e.g. 0.9.15