Community Champion
Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
So many of my projects involve technical development, and if that rings true for you as well, it’s helpful to know what different types of software testing you might encounter on a project. Then you can add them to the discussions about the plan.
Just to confirm – never pop them on your schedule without talking to the right teams about how long they are going to take and when they are going to happen. But at least if you know the different types of testing, why you would use them and when they typically happen in a project, you can ask the right questions.
Here we go!
1. Unit testing
What it is: Testing individual components (e.g. functions, methods, modules) in isolation.
Who does it: Developers.
When: Early in development. As each individual piece of the solution is delivered, it’s tested, or you might do all the software development and then test.
Why it matters: Catches logic errors early and makes debugging easier.
2. Integration testing
What it is: Testing how components work together (e.g. how modules exchange data).
Who does it: Developers or test engineers.
When: After unit testing, before full system testing.
Why it matters: Ensures that interfaces and data flow between parts of the system work properly.
If you have an integration engine, the team responsible for that would be involved, as this is all about how different tools link together. If you have interfaces or data moving from one system to another, you’ll definitely want to factor this in.
3. Smoke testing
What it is: A quick, shallow test to confirm that the most critical features work.
Who does it: Developers or QA, often automated.
When: After a build or deployment.
Why it matters: Gives fast feedback before deeper testing begins.
Smoke testing can happen at different points in the project. As the project manager, the question you need to ask is, ‘are we planning any smoke testing?’ and then you can decide together when to add it to the schedule.
4. System testing
What it is: Testing the complete, integrated application as a whole.
Who does it: QA/test team.
When: After integration testing, before UAT.
Why it matters: Verifies that the system meets technical specifications and behaves correctly.
This is the important testing, and you’ll want to leave enough time for it.
5. Acceptance testing (including UAT)
What it is: Validates whether the system meets business requirements and is ready for release.
Who does it: End users, product owners, or business analysts.
When: After system testing.
Why it matters: Confirms the solution works in the real world for the people who’ll use it.
While system-y people might be involved with the acceptance testing, the main focus for me is on the user testing. You’ll need to identify the right users, make sure they have access to the test system and most importantly, that they know what to do. They’ll record any bugs they find and the developers will put them right.
You’ll probably want at least 2 rounds of UAT, to allow people to find bugs, fixes to be deployed and then for testing to evidence that the fixes work.
Schedule in enough time for UAT testers to be trained on the system, test their access, attend a session on how to record bugs and for them to re-test the fixes. This always takes longer than you expect!
Next time I’ll share four other types of testing that you might need to include in your plans.
Posted on: October 05, 2025 11:06 PM |
Permalink