Friday, December 14, 2007

Hiring Quality Engineers for Scrum Teams

I have frequently been asked "how do you go about hiring good Quality Engineers for an Agile team?" I really feel strongly that there are several proficiencies that needed to round out a strong test group for agile teams. These proficiencies can be enbodied in more than one person, but rarely is any one Engineer proficient in all of these disciplines.
  • Domain Knowledge:

  • As with any Quality Assurance (Engineering) team, there needs to be enough representation of the customer for each actor (user) of the system. This requires insights into the goals and intended use of of the system, and most likely may be someone hired from the user community.
  • Development Prociency:
    • Unit Tests and representative Acceptance Tests in an XUnit Framework -- This is a tennant capability for working with the developer on a story to write story acceptance tests first (or during the story development).
    • Separation of GUI/Presentation tier from Business Logic tier -- This is key to being able to exercise the business logic (where most of the work is accomplished) in tests that reside with the source of that production code. There is no need to drive these test with the overhead of the client presentation tiers involved. The client and presentation tiers need their own representative acceptance test for regression, and exhaustive tests (e.g. different environments).
    • Exhaustive Tests through data driven tables -- There are several approaches and tools for exercising acceptance tests with many combinations of data sets (e.g. FitNesse or Solenium tables, xml, csv, etc.)
    • Test Fixtures -- This is key to exposing all of the system for comprehensive story acceptance tests. As a company matures with agile, I prefer to create a Test Automation Architect role who is responsible for oversight and creation of enough test fixture infrastructure to enable the team to develop comprehensive regression test coverage that can run following build and unit tests completion daily.
  • Traditional Tests
    • Performance Test Automation -- This includes both local and load tests as found in traditional waterfall and other iterative SDL's (software Development Lifecycles).
    • Manual Tests -- There are some test that are purely asthetic or user experience oriented to assure that the application is pleasing to use and accomplishes all the user tasks and goals of each actor identified for the system.
  • Process Engineering:

  • This is discipline of best practices and well defined procedures that need to be in place for consistency across the team, and to maintain a project cadence. As with software, process can be over-engineered and requires a sensitivity to what is working efficiently, when to turn up the process to improve consistency and predictability, and when to turn down the process to eliminate unnecessary overhead.
The question that usually follows this list is "how do you find a Quality Engineer with a Development Proficiency?" There are talented Quality Engineers with CS and MSCS degrees with years of experience in both development and test engineering. If you can't find them, create them. Find a developer who has an affinity for methodical test coverage in their own work, or who is good at and enjoys testing their own work to step in to a Quality Engineering role. I have been able to convert a few developers to this role and the results are fantastic.

No comments: