For ascertaining software quality dependencies, there has been a lot of work on software processes. CMMI is a multi-billion dollar industry working on formalizing process, yet there is no convincing evidence that better processes result in better quality software, especially today where software with no defects cannot be ascertained to be high quality.

We believe that software quality in any way you define it, starts with good quality people. If you have stupid people using a great process, the result will be mediocre at best yet it will be consistently mediocre. On the other hand, if you have smart people using ad-hoc processes, then perhaps you’ll turn out a high quality product sometimes. Of course the best solution is to have both smart people and good processes. And that brings it back to quality people. So given that, what is the definition of a  good quality software quality engineer? We took a look at this and listed out a few characteristics:

  • Domain knowledge: Has domain knowledge related to the domain of the software, i.e. banking, insurance, energy, etc.
  • Technical knowledge: Can demonstrate mastery of technologies and tools useful in the daily work of the product development.
  • Written communication skills: Can communicate ideas clearly and concisely.
  • Oral communication skills: Can communicate ideas clearly, and listens and understands others.
  • Team Collaboration skills: Shares knowledge with peers, participates in and contributes  discussion regarding team problems. Open to feedback and provides feedback.
  • Organizational and planning skills: Can organize complex processes and detail out a plan to get the work done in the time allotted with high quality.
  • Problem solving abilities: Can address difficult problems, analyze them, and provide practical solutions.
  • Motivation: Looks for what needs to be done rather than waiting to be told. Willing to take extra steps to get the job done independently.
  • Responsibility and reliability: Committed to carrying out tasks independently or in a team with reliable results.
  • Years of testing experience: Has sufficient related test related experience to complete the tasks at hand.
  • Years of work experience: Has sufficient work experience in various environments and technologies to adapt to the situation at hand.
  • Certifications: Has related professional certifications which may support the task at hand.

This is just a short list of criteria that could be possible when determining the ‘quality’ of personnel on your QA team. Just keep in mind that people are often overlooked as a key software quality dependency, yet without good people we really have no hope of delivering a quality product. Perhaps agile is a methodology which brings this problem or issue to the forefront.