Testing & validation

Today's post will focus on testing and validation procedures that are performed throughout a system development life cycle (SDLC.) As the different artifacts and deliverables are created, traceability and requirements management practices are used to ensure that the vision and direction for the project is maintained. Thus,

  • Business requirements are expanded into functional requirements.
  • Functional requirements lead to design documents.
  • Design documents lead to code generation.
Refer to the diagram below, the names used are not important but the objects they represent are.

From the perspective of testing and validation, testing is done as follows:

  • Code is reviewed.
  • Components defined in the design documents are unit tested (e.g., individually tested.)
  • Integrated tests are performed on components that work together (aligning with the functional requirements and architecture.)
  • UAT testing is performed to ensure that the objectives of the project are realized.
  • After the project goes live, performance against the key goals (e.g., improve throughput by 15%) are measured. Ultimately, this will be one of the factors that determines the ultimate success.

Testing & validation in detail

As new code is created, code reviews can be performed by other programmers and team members. Personally, I do not code (and am not familiar with this) so I'm going to gloss over this part.

Functional requirements are expressed as design documentation that support the requirements. Each component is tested independently (e.g., unit tested.) Inputs are simulated and the outputs examined to determine whether the component accomplishes its purpose.

Functional requirements align with their corresponding business requirements to identify the key characteristics and needs for a project. You must be able to drill back to the higher-level business requirements and down to the design documents to get the full benefits of traceability. When testing to see that functional requirements have been met, you must determine that the different functional components work with each other. Integrated testing is the key concept. Outputs from one component become inputs into the other related components. The terminology integrated system testing has been used to express this idea.

The business requirements define the objectives and measurement criteria for the project as a whole (see my post called, The sweet smell of success.) User acceptance testing (UAT) is done to ensure that the basic business objectives are satisfied (e.g., setup a marketing campaign.) Measurement against performance goals are done at this stage as well as after the project's deliverable goes live. You cannot determine if the performance goals have been attained until the end-users have been trained and passed through the ramp-up period.

1 comment:

Marcus Ting-A-Kee said...

I've made the Powerpoint slide used in this presentation available on esnips.com.You can download it using this link.

I look forward to hearing any comments or feedback.