Integrating Test Activities and Dependencies into the Project Critical Path

In previous posts, I addressed the types of testing commonly conducted during IT projects, and common testing roles and responsibilities.  But testing isn’t just “one more task to do;” it should be at the heart of decision to proceed to the next stage of the project.  In this final installment, I’ll address how testing, as a quality assurance function, is integral to the critical path of the project.  Note that there are a lot of different kinds of IT projects, and a number of technical approaches and methodologies.  There is no universal approach that would be correct for every IT project.  But there are some useful rubrics for planning how and when testing should occur during a project, and what dependencies lead and follow each type of testing.

Most IT projects can be roughly grouped as either development or product life extension.  In a development project, a new capability is delivered by a team that acquires or develops a number of components, fits them together in some fashion, and puts into production a working system which delivers benefits to stakeholders.  The resulting system might include application and OS software, hardware, cable plant, services, documentation, change management, and any number of other pieces.  Typical examples include software development projects, installation of telecommunications or networking in a new facility, or migration from an on-premises application to a SaaS application.  The emphasis is on delivering a properly working, supportable system.

In the diagram below, development activities may consist of any number of software development, configuration, data conversion, hardware assembly, or other activities resulting in units to be tested.  Unit testing, smoke testing, conversion validation, and UX or usability testing are conducted, as applicable, with results fed back into the development activities until all tests pass.  Aggregation activities include those which assemble the tested units and components into a working system to be tested.  Integration testing, end-to-end system testing, load testing, and survivability testing are conducted, as applicable, with the results fed back until all tests pass.  Then a final round of acceptance testing, with may include parallel testing, is performed and a go / no-go decision made to proceed to delivery.

In a product life extension project, an existing capability already delivering benefits to stakeholders is updated, or given new capabilities, capacity, or made compliant with new requirements.  This isn’t corrective or preventive maintenance; it is typically a capital investment made to increase the value of an asset.  Typical examples include enterprise software updates, server refreshes, and network hardware upgrades.  In virtually all cases, the emphasis is on minimizing any disruption of service when transitioning.

In the diagram below, the product improvement activities might include implementing a software upgrade from the original vendor, or a replacement for existing hardware, or any number of similar activities.  Regression testing ensures that the proposed improvement doesn’t “break” the existing capabilities of the system.  If the upgrade process requires conversion due to modifications to the data model, conversion validation will be required.  Results are fed back into the product improvement activities until all tests pass.  Integration activities include those required to cut over the product improvements to a system already in production.  Integration, system testing, and load testing are performed, as applicable, until all tests pass.  Then acceptance testing is performed, resulting in a go / no-go decision to deliver the improvement to production.

As you can see, testing is both a feedback loop and a gateway to subsequent activities.  Consequently, it is important to properly establish each type of testing as both dependent on the activities whose products it will be used to test, and as a predecessor to the activities that build on the test subjects.  Thus, devising a workable project plan requires an early, detailed understanding of the scope and types of testing required, as it will impact both schedule and budget.

This entry was posted in Quality Management and tagged , , , by Dave Gordon. Bookmark the permalink.

About Dave Gordon

Dave Gordon is a project manager with over twenty five years of experience in implementing human capital management and payroll systems, including SaaS solutions like Workday and premises-based ERP solutions like PeopleSoft and ADP Enterprise. He has an MS in IT with a concentration in project management, and a BS in Business. In addition to his articles and blog posts, he curates a weekly roundup of articles on project management, and he has authored or contributed to several books on project management.