How can I introduce QA and break it into parts for various people?

Question

I was recently asked how to do this, specifically:

1. How to introduce QA into an organization?
2. How to break up QA into parts that others can do ?
3. How to prioritize what needs QA?
4. How to determine what to buy? code? etc.

The organization uses Rails on Rails extensively as the development platform

Note: I am posting a lengthy answer myself but I will also upvote additional good answers (and probably incorporate them into my answer).

Answer 1

1. How to introduce QA into an organization.

Quality Assurance happens at all levels of product development, from code quality to server environments to user experience. Introducing QA to an organization means looking at all the areas involved and seeing how QA processes and approach can improve the product quality.

2. How to break up QA into parts that others can do ?

OK this is more down to the nitty gritty. I will break this up into 4 parts:

Code Quality can be achieved using a number of tools and processes:

• Standards and Guidelines. For example for ruby code the Sandi Metz guidelines of 5 lines methods, 100 lines maximum classes, max of 4 parameters, etc. This will apply directly to the development team members writing the code for features, bugs and chores and should be assured through code review before code acceptance with the developers code review pair person.

• Code Quality. There are a number of tools that can and should be used to improve code quality. For example in the Ruby space 'reek' is a great tool to look for code smells. These tools can be used by the development team members and should be used by the code team leader when reviewing code with team members.

• Unit Tests for new code. New code should include unit tests as part of their development and they must be included in all time estimates of how long things take. Tools that can help out in this area to make sure that the code have coverage include simple_cov, rails_best_practices, rubocop, etc. As with Code Quality, these tools can be used by the development team members and should be used by the code team leader when reviewing code.

• User Experience and Integrated Testing. This is where the development and deployment teams make sure that the new changes work for the end user and work in all browsers and devices as expected. There are a number of tools and services that are very helpful in this area, including:

  1. For Ruby, Cucumber is a high-level tool that can be used to put together end-user scenarios. Cucumber tests are written be the development in close consultation with the product team, using language that reflects the users domain.

  2. For testing in actual browsers the long-term goal is to build up an automated test suite that can be run at will. The preferred tool for doing this is Selenium. Selenium tests can be written in two (broad) ways. Firstly they can be written by developers in the language of their choice. In practice this is rarely done in smaller organizations. They can also be developed by using a free Firefox IDE plugin. This is a great tool for lower level developers to easily write browser based tests. The developers that use it will need some training on css, xpath, IDE specifics and organization. Another item to address is how to address their feedback with the development team. For example how to address "I need a data-attribute on the login username field". Over time, Selenium tests amass to form a regression suite that makes sure the product works as expected after any changes. Selenium tests are often the exclusive domain of the QA group and are not developed by the main code developers.

  3. For device/browser testing a great (free) OS emulation tool is Virtual Box which is very helpful for testing ie6, ie7, ie8 and ie9. Virtual Box would be suitable for any developer wishing to check out 'old browser' views. In my experience it has been most useful for the QA / Delivery team who need to look at older browsers to be sure the product still works ok. Obviously devices such as cell phones and ipads should also be checked against and for this there are a number of tools such as iPad Peek, iPhone tester, Mobile Phone Emulator, MobiReady, Responsivepx and Screenfly. This is a rapidly changing area for products and tools. There are also external services such as Saucelabs that can help in running testing against multiple devices.

3. How to prioritize what needs QA?

This is where the product and developments team interface. The product team has a good idea of how the app is used, where it is used, what devices it is used on and the importance and priority of the application functions in relation to the mission of the organization. The QA team and developers have a better sense of how long it takes to write code and tests in Ruby, Selenium and other tools. The merging of the two sets of information will drive answers of what to test.

4. How to determine what to buy? code? etc.

When considering Quality and QA processes the main consideration is which parts of the development process to apply these processes to. For the most part, Quality in software development is mostly about internal processes and approaches. It's hard and unwieldy to out-source much of this outside of the development team. This leads to 'build vs. wing-it' rather than 'build vs. buy' decisions. This also means that the direction and guidance of QA needs to come from management.

The end result should be quality that is 'baked in'.

Answer 2

Your assignment¹ is not a good one because it doesn't have any specific or measurable goals for success². Once you've defined your goals the rest of the process falls into place.

1. How to introduce QA into an organization? [Choose Metrics]

Here's the process to follow:

• Choose your goals (an improvement in some metric).
• Before you change anything, do some measurements and see how you're currently performing³.

For demonstration purposes pick a couple sample metrics⁴:

• Down-time
• Regression bugs introduced

<sup>1. I'm assuming this question is about adopting new QA processes into an existing department.
2. What does it mean for quality to be "baked-in"?
3. Oddly enough you may find out that measuring something, paying explicit attention to it, solves the problem.
4. I picked these at random to show how the process works.</sup>

2. How to break up QA into parts that others can do? [Implement Changes]

This is the step when you make a single change, per goal, and then measure the results.

You have lots of options here. You might choose to pick a single person to champion each change and try to prove its effectiveness.

For reducing down-time you could implement:

• System monitoring (AlertSite)
• Testing of critical infrastructure

For reducing regression bugs you could implement:

• unit testing
• code reviews

3. How to prioritize what needs QA?

This should be the first step. What needs QA is something that has an associated metric that you're trying to improve.

4. How to determine what to buy? code? etc. [Automate What's Proven to Work]

Don't start thinking about what you can buy when the process starts. Only after you make a change and see that some metric has improved, should you consider automating that change.

^{For anyone who is better than I am at formatting posts feel free to change anything above}