In my previous blog post I provided six tips to improve the probability of project success.
In this post, I reveal a seventh tipspecifically focused on the Testing & Integration stage during the Software Development Life Cycle (SDLC).
In a typical SDLC you have the following phases:
- Stage 1: Planning – In this stage the Project Manager (PM) and staff are “planning” for the project or enhancement by building a project management plan and determining scope of the work. Think of this as baking prep: What to bake, when to bake and why you are preparing to bake.
- Stage 2: Analysis & Requirements – In this stage the Business Systems Analyst (BSA) is reviewing project scope to formulate the business requirements and create the requirements documentation – business / functional – for the implementation team. Gathering of the baking ingredients, and determine the ingredients for baking the requested item.
- Stage 3: Design – Using the requirements input from the BSA the lead software developer or Technical Lead (TL) architects the software solution to meet the business requirements. Think of this step as creating the recipe to bake based on the baking item requested during the requirements stage.
- Stage 4: Implementation (Coding) – Baking! Using the recipe developed by the TL; the development team begins coding and unit testing to ensure the outcome meets the requirements and the design previously documented.
- Stage 5: Testing and Integration – Time to eat…..the testing is typically done by Quality Assurance (QA) individual and his/her role is to ensure the outcome of the code developed meets the requirements as described during Stage 2 by the BSA. Inspecting the baked item to ensure it meets requirements such as a choclate cake with vanilla frosting as intended.
- Stage 6: Maintenance: Once the project is completed and is in a steady state a separate managed services team is tasked with keeping the solution running.
Tip #7
- During the testing and integration stage the testing should not be tasked to the BSA. Why? There may be bias inherent to the BSA peforminig both roles. Since the BSA has created the requirments they may not realize that certain assumptions haven’t been documented. The QA person has a different skill set to the BSA and will be as second set of eyes to catch any assumptions made. This approach also ensures traceablity between scoping, requirements and testing.
- Ideally all QA testing should occur in a pre-production environment that contains a code set that matches production to ensure the change is tested with a sufficient volume of data to accomplish regression testing. If at all possible QA testing should not be isolated to the development environment.
Kirt Morris is a Project Management Professional and a Delivery Engagement Leader at Merkle within the Data Management group. He has 18 years of experience in technology implementation and system integration delivery for data warehousing and business intelligence. In his current role, Kirt has end-to-end responsibility for the delivery of Customer Relationship Management (CRM) platforms for Specialty Retail and Consumer Package Goods clients. Prior to working at Merkle, Kirt worked at Cap Gemini Ernst & Young in the Critical Technologies group focused on data warehouse deployments for Telecommunications Media and Entertainment clients. Kirt has a B.S in Computer Science from University of Maryland, College Park and M.S in Management Information Systems.