QA Testing

At Little Arms Studios, we are still a very small team at the time of writing this (14 people), so we don't have a dedicated QA or testing department. That work tends to fall on the developers and even sales team members on occasion. Even during MVP development, we are constantly testing as developers. At the end of every sprint, we will show off feature progress and look for any feedback or suggestions. We also do a lot of pair programming and often find ourselves debating the best ways to solve complex problems with at least a few other developers.

After a feature is first implemented, we then begin testing by handing it off to a fellow developer who was not involved in the implementation to get a fresh perspective. Assuming no errors are found, we will then ask sales team members to test themselves and eventually create a custom development build to show off at trade shows and get hands-on feedback from potential and current customers on what they like and, more importantly, what they don't.

This allows for a lot of testing and a good amount of eyes on the product before a new release; however, it's far from perfect. The quarterly release system I talked about in the production page improves on this workflow, allowing for a minimum of a full quarter to test internally and externally before an update is released. It also allows us to get more alpha testers from product champions and loyal customers who are willing to get access to new features earlier in exchange for providing feedback on their experience and a less stable experience.