I have read about software QA/QC and software-test that in an agile environment the software QA process "directs" the software process, that is to say, that it doesn't ship until it's ready to ship and that SQA is a key part of the software delivery process.

So I'm a software development manager in a very small software company. We are currently very basic in our SQA practices. I think that as the leader here, it's my job to get more rigorous or at least, more effective software QA processes going.

I'd like to know from someone who has been or is in an SDM title or role, what they believe their job is, with respect to SQA, and what is their job to do?

1 Answer
1

I have not ever been an SDM, but I do have opinions on the matter so I'll answer the question anyways :-). After writing my response below I feel like it turned out a bit like "QA in a nutshell". Please continue to explore additional resources beyond what I outline, I am just trying to provide some simple ideas that could significantly increase quality within a lean, agile team.

If you have either 0 dedicated QA resources (meaning your entire team is responsible for QA) or all QA resources report up to you then you absolutely should take the initiative on putting more rigorous QA practices in place. On smaller teams you can often get away with no dedicated resources for QA - what you can't get away with is no QA practices in place at all. Everyone needs to pitch in and be a part of the QA process.

A popular and somewhat natural way for developers to directly increase quality is to adopt a TDD (test driven development) or BDD (behavior driven development) approach. The basic idea is that you create automated tests prior to writing code and as you implement your features they cause the test cases to begin passing. When all of the tests pass, your feature is complete. There is a ton of documentation on TDD and BDD all over the place, so I won't go into too much detail here.

You can also pair up developers with other developers and have them act as QA for the features being developed by the other. This would include doing some light test planning for non-functional testing which is easy to overlook without dedicated QA resources such as test cases that should be automated, performance/stress tests, security tests, localization/globalization tests, accessibility tests, etc.

Even without QA resources you should still plan a "stabilization" period at the end of your release cycle where the primary focus of the entire team is quality and your team is in mostly a QA mindset with a secondary focus of fixing bugs found. Just make sure that the bar for severity of bugs to be fixed during this stabilization period is high, you don't want to fix a bug only to destabilize the rest of your product right before you ship.

Another easy and sometimes fun way of having everyone pitch in with quality is a "bug bash" where everyone stops the feature work they are doing and exercises the product you are developing. You can give out prizes, etc... If you search this this site for bug bash you can find more info. This often happens after you are feature complete, right before (with enough time to fix any major bugs found) or at the beginning of a stabilization period.

Finally, you should ensure that all of your developers are following development best practices around code reviews, static code analysis, using code coverage tools to help drive unit testing, etc.