Teaching Quality Assurance (QA) Methods

Question

I'm in the process of trying to teach my team the ins and outs of Quality Assurance, but am running into some challenges distilling "QA" to its base elements.

I have many years of experience that spans all areas of development, QA, Graphic Arts, Engineering, now business and marketing, and now have a small team of under 10 whom are all junior (less than 1 year of actual production experience) developers.

I'm looking for some resources that break down the QA process to something they can quickly adapt and learn, ultimately to build up a skill-set over time. For myself, I'm from the era of self-taught development and learned the bulk of my understand of QA from working in a large publisher environment for many years. I am assuming it is my teaching technique (likely) or approach that is falling short in getting the team understanding why QA is important and how it fits in to development. They are workable right now, but are not yet really 'clicking' with the process and the quality of bugs reported right now are lacking.

The trick, is how to pass some of this down to my team so they get the salient points first.

Any chance someone here:

• Can point me to any online resources that get to the basics on QA?
• Can point me to a short-form list of best-practices in bug-reporting?
• Other resources that may be useful in on boarding/teaching the team with a QA mindset?
• perhaps connect me with someone who can help flush these out?

Any help is greatly appreciated!

Answer 1

A thumbnail definition I've used on occasion is "unit tests and good development practice make sure it's built right. QA/Test also tries to make sure we're building the right 'it'" - that is, tester focus tends to be more broad-based and with an eye towards the presumed end user.

Some of the resources I'd recommend are active here: Joe Strazzere (All Things Quality), Alan Page (Tooth of the Weasel). There's also the folks at the Software Testing Club and SQA Forums.

A few other points you might like to make:

• Tester mindset is usually different than developer mindset. Developers focus on building something according to the rules (requirements, user stories and such) they've been given. Testers look at those rules and ask "what happens if I break them?".
• Testing/QA isn't about being the gatekeeper ("Your code SHALL NOT PASS!"). It's about giving the rest of the team valuable information about the software.
• Nothing above the most basic can be fully tested. The built in calculator in most operating systems is a good example. It's simply impossible to check that all four basic functions work all the time (if your team hasn't been exposed to combinatorial math yet, this is a good place to start them - just to fully test addition of two single digits you're talking 100 (I think) tests. To add three single digits, that's 1000 tests. And so on... This is why the black art of testing is to work out where the boundaries are and test at those (and why testers are breakers-of-rules - each rule is a boundary).
• No software ever goes live without bugs. Ever. Because nothing can be fully tested, things get missed. Testing and coding work together to keep the worst ones out of production - mostly.

Improving the quality of your team's bug reports is something that can happen over time. You might like to highlight the best ones that are reported and point out why they're good - and do that with both the good bugs and the good reports (as I'm sure you know, the two aren't necessarily the same).

I'm not big on rigid formats or best practices (most of my answers here start with "It depends..."), but some good guidelines for bug reports are based off the What/Where/When/How pattern:

• What - Describe the behavior of the bug versus what the tester expected to happen
• Where - Where in the system is the problem happening (i.e., the environment). Is it only related to one configuration, or does it happen across multiple configurations. Is it browser or operating system specific?
• When - If possible, give some kind of idea when the problem started happening.
• How - How do you make it happen? Can the tester force it to happen every time or is it one of those annoying intermittent things?
• Optionally, Who - If active development is happening in module X and something breaks in module X, that development is probably "who" broke it. This isn't about assigning blame - it's about discovering unintended consequences.

Answer 2

I would strongly recommend that you consider signing up your team for the Association for Software Testing's excellent BBST series. It's a great introduction to the foundational concepts they'll need to understand why we test, but will also challenge them to improve their skills at explaining and analysing their ideas about testing and expose them to discussions with a variety of testers from across the world who work in all sorts of different contexts. The course is based on the materials in the link below (which are freely available), but includes so much more, in terms of practical exercises, tutor and peer feedback, that it's well worth the (small) investment in time and money. My team signed up our (at the time) junior developer and tester, and they both enjoyed the course and learnt a lot.

If you feel that you want something a bit quicker, then I'd suggest that you check out the excellent resources at http://www.testingeducation.org/BBST/ - and select a subset of those you think most relevant to your team.

Start with the Foundations stuff, the videos for lectures 2 and 5 sound pretty relevant at the moment. There's also the Bug Advocacy course, but as there's a lot of material there you might want to just pick lecture 6 (writing a better bug report) as a start - it walks through a handy mnemonic (RIMGEA) that's a great set of steps to apply to your bugs.

Answer 3

Quality Assurance means ensuring the client that all the quality attributes are achieved while developing the product. Now that you have a team under you and that team is to be trained for doing QA, a thorough system/domain knowledge will be very much helpful in finding out the actual and expected behavior.

Trying to find out what is not working is helpful for QA people than believing that everything is working fine.

You can use JIRA(bug filing tool) for filing the bugs properly. While filing a bug following components should be specified clearly, if possible :

Issue (Bug) Components

• Summary (Short one line statement of what's wrong exactly)
• Priority (Assign priority from P0(Severe) to P5(Low effect))
• Fix Version (Commit ID for the commited code if you have)
• Environment (Staging / Production)
• Description (Step by step description of reproducing the issue)

The following are helpful and should be included as appropriate:

• Screen shots (along with valid names)
• Screen recordings (using tools like CamStudio, ALLCapture)
• Net Activity Logs (Logs form Net Panel i.e. Firebug)

Also you may refer the following link for detailed description : http://www.chiark.greenend.org.uk/~sgtatham/bugs.html

If the team wants to be more efficient in QA, daily/weekly standups/scrum with the developers would be of great help. In the standup, discussing about the high priority issues will help the developers in keeping track of the important stuff that is to be fixed.

After resoultion of the issues those should be re-tested by QA to verify that they are not reproducible anymore.

Answer 4

There's a collection of testing MindMaps here that are really great and useful for communicating ideas and things to think about when testing - http://www.ministryoftesting.com/resources/

Answer 5

Online resources re: the basics of QA:

In addition to the good suggestions you already have, here is one more. My employer uses a website called skillsoft (aka skillport) that contains thousands of online videos and books regarding all phases of software, including testing. Skillport has the ISTQB prep classes. All their classes are self-paced with pre-test, quizzes during the video and post-test. They provide certificates of completion as well. I've taken at least 20 over the years encompassing several business aspects (negotiation, problem solving, communication, as well as testing related) and found them to be helpful.