The Early Worm gets the Bird

All too often QA is an afterthought, contacted during the final stages of development for a quick check before the app is pushed live.  Ideally you’d have QA working in some capacity along the entire lifecycle, but companies like us understand money doesn’t grow on trees (especially for indies who have grown mere saplings in the yard).  Regardless of your budget, reach out to prospective test teams long before you need them.  Get the project on their radar and perhaps a short test cycle:  Nothing is worse than finding out there isn’t enough time to test something or that more finances are needed to change gears on a feature.  Discuss your options and get creative with juggling resources.  For instance, small developers looking for the most bang for their buck will usually agree to have us look at each major milestone and slowly ramp up the effort as the backlog comes to a close.

Project Size and Timeline

Nothing starts a chain of correspondence and phone calls faster than a two-liner email requesting a quote for an undisclosed freemium game. To get the fastest and most accurate response you’ll want to provide a good idea of your title’s complexity: Is there multiplayer? Is progression linear or branched? How long is a typical play through? How does monetization work? Have you integrated social networks or other 3rd party APIs? Can you compare it to existing applications on the marketplace?

Describing a potential QA effort outside the context of its schedule is like ordering pizza without any plans to pick it up. Try to close as many gaps as possible by sharing your target milestones and intended feature lists. Where are you right now? What remains to be done in development? All of this information helps the tester craft a plan that works in tandem with the development schedule (so that they don’t waste time on untestable things, asking the wrong questions, or burn hours when not appropriate).

Documentation

Agile development is a popular style we’ve come to appreciate for its emphasis on lean processes, collaboration, and iterative development but it tends to fall short when a vendor is introduced into the chain. A complete lack of documentation means you’re retelling the entire story on the phone. Testing houses like ours have learned to adapt and expect the unexpected, but if you have any documentation that can be shared it’s in your best interest to pass it along. It doesn’t need to be in-depth, overly technical, or pretty: The most useful things you can send at a quoting or kickoff stage would be a short concept or design document, a user experience flow, and a high-level feature list for the upcoming release. We’ve managed to put a couple quotes together based on photographs taken of a team’s whiteboard! Everything you provide enhances the quality of test cases being drafted for the application. Help us help you.