Assignment

In general: no job without an assignment. This also applies to a job like establishing the quality of a product. On a high level one could say, the assignment must make clear to the stakeholders what the aim, tasks, responsibilities and authorizations of the job are.

Assignments come in different flavors. For instance, an assignment in a traditional development environment will differ from an assignment in an agile development environment and an assignment in a low risk product environment will differ from an assignment in a high risk environment. Does this mean that no general activities to establish an assignment exist? No, on the contrary. The form – end result of these activities -, in a plan of many pages or only a sketch on a white board, will vary, but generic activities could be identified for sure.

Below a non-exhaustive overview of possible questions you have to answer in order to establish the assignment:

• Who is the client?
  • The client is giving the assignment for the job. Could be a business manager, project manager, steering committee, scrum team, etc.
• Who is responsible for executing the assignment?
  • Could be a scrum team, test manager, project manager, a third party, etc
• What exactly is the job?
  • Think of determining the quality of the product, covering (product) risks, meeting predefined test goals, etc - Who are the acceptants? Often the person executing the assignment is not the one who accepts the product. So who does? Could be a business manager, a product owner, a group of stakeholders, a scrum team, operations, etc. Please note that the client does not have to be the – only - acceptant.
• What are the acceptance criteria?
  • Acceptance criteria are very important. You could say that they largely determine the performance of the job. Acceptance criteria must be proposed and defined by each acceptant and can be very diverse. For instance, specified functional, security and/or performance criteria have to be met (often referred to as test goals).
    An frequently used approach is the following: all acceptants together create a list with test goals. Per test goal the risk level is established. Per risk level (let’s say ‘high’, ‘medium’, ‘low’) the acceptants specify the maximum number of open defects per severity class. After the tests, in respect to a specific combination of test goal and risk level, are executed one can easily see whether the amount of open defects per severity class stay within the agreed range or not. If yes, then the test goal is accepted by the acceptant. These acceptance criteria are available in various forms. As a section in a test plan, in the confirmation part of a story card, in a definition of done, etc.
    Example:
    Severity classes are assigned to found defects:
    Defect is a showstopper : severity class A
    Defect can be solved with workaround : severity class B
    Defect is cosmetic : severity class C
    
    Then with the acceptance criteria the relationship is defined between the severity class of a defect and the risk level of a test goal:
    - All test goals with risk class H must contain 0 severity class A defects, <2 severity class B defects and <3 severity class C defects.
    - All test goals with risk class M ....
    This way you can link risk levels, severity classes of defects and acceptance criteria together.
     
• Determine the scope of the assignment.
  • Determine not only what is in scope, but also what is outside the scope of the assignment. Determine, for instance, the boundaries of the system (which interfaces with adjacent systems are in/out scope), whether administrative organization procedures are in scope or not, where applicable which test levels (e.g. unit test, system test, acceptance test) are in scope and which are executed by other parties, etc.
• What preconditions must be met?
  • Preconditions describe the requirements imposed on the assignment by other parties within the assignment must operate. Such requirements can be, operate within the existing quality, risk and/or testing policy, meet already quantified aspects like risks to cover, results or quality to be achieved, a time limit in a business case or whatsoever plan, etc.
• How to report?
  • This can be done in many ways. Which reports with what content and when to report has to be agreed with the client and possible other stakeholders. Often risk and quality reports are desired. Reporting can be done at a regular or ad hoc basis and/or at the end of a project.