QA testing with a small team best practices

What framework are you using? And do you have any automated browser tests (e.g. selenium) Those would be a good way to try and prevent some major regression errors. Pushing that many times a week requires a significant amount of development operations overhead (or someone who is always on edge worrying and looking) to make sure bugs aren't being pushed. Sounds stressful. I've been there.

The engineers should, at the least, be writing unit tests. What kind of testing are you doing as the designer? Also, the type of QA infrastructure you need truly depends on the product being tested. Is this a web application, desktop application, mobile application (et cetera)?

This all really depends on the team size.  

Absolutely, engineers should test. But not primarily or exclusively by hand -- they should be creating automated tests (preferably developing using a specification-driven methodology, i.e. TDD/BDD). Don't aim for 100% coverage, but expect solid coverage of the more critical code paths (in RoR framework, I like to focus testing on models, which is where most of the business logic lives, and requests, to exercise end-to-end; and mostly skip testing controllers and views). 

These are great responses. I guess to follow up and clarify - I was asking more about testing different use cases and user flows, not actually unit testing. I totally agree that depending on what stage you're in and how quickly you are iterating unit test's will help, but might not be as efficient.

Unfortunately, there's no silver bullet answer.  I've seen teams test a lot and still create products that are inherently unstable.  On the other hand, I've also seen teams with little testing create products that are quite successful. 

Testing (and here, I distinguish between 'QA') is certainly a good practice and reduces the _risk_ of product failure.  But, like many risk mitigation strategies, it doesn't work 100% all the time.  Plus, there are certainly diminishing returns. 

The best thing to do is to have a team of skills developers who have shipped and maintained products successfully, many times, if possible.  They will have the intuition to be able to set a line in the sand between too much testing and too little.  The developers should certainly be doing most of the testing.  At least, they should have a good set of unit tests at all layers of the development stack.  They should also have automated functional tests as well as integration tests.  As the product is maintained a similar set of 'regression' tests should be produced and executed.

Ideally, they will want to automate testing as much as Humanly possible.  Testing is seriously time-consuming, and manual testing takes away precious time from value-added tasks.  However, there will still be some 'sanity testing' toward the end, where you and or the product-manager (are you the product manager?) walk through the application in it's 'test' environment.

This is a very deep topic.  But, I can quickly summarize some strategies and tactics: 
1. Test constantly throughout development.  Tests should be added in parallel with features in the feature branch.
2. Tests should be automated.  Use a continuous integration tool.  If your team is mature enough, consider continuous deployment, in some cases.
3. Use clean environments for testing.  That is, the development environments should look the same.  There should be development, testing, staging, and production environments.
4. Use bug tracking and regression tests.
5. Do acceptance tests, continuously (3-4 times a week), if features aren't exactly specified.
6. Keep metrics of errors found in testing environments and production.  Many bugs _are not reported_ by users; metrics will make you disciplined and help get an understanding of how many bugs are actually in the wild (and possibly destroying your customers' opinion of you).

Best,

Aaron

I agree with Jake you need someone to help just with testing. email me mike600@gmail.com and I can hook you up with my testing guy if you'd like. He's good and pretty cheap.

What I have found very efficient in small cross-functional teams is to block off some time (this could be several hours, a full day or more) where everyone does QA and files bugs. Ideally, there are flows and use cases that are prepared ahead of time, and everyone in the team uses the same task flows.

Hi Abby,