This video shows you how to conduct systematic project acceptance using test suites in Leadtime. Instead of clicking through results in an unstructured way and collecting feedback via email, test suites offer a reproducible process with clear test cases, documented results, and direct bug ticket creation.
Test suites are part of the project tree and come along automatically when you import a component from the library. Just like work packages, they can have conditions: if the customer doesn't need an online shop, the shop test cases don't appear at all. You find them in the project under Configuration → Project Tree, typically within epics under "Testing and Quality Assurance."
Each test case precisely describes what needs to be checked and defines an expected result. Evaluation uses three levels: "Passed" (everything fine), "Passed with limitations" (basically works but with restrictions), and "Failed" (did not pass). With every rating, you can leave a comment, and for failed tests, create a bug ticket directly – with the correct project assignment and the test's context.
Test results flow into the Implementation Overview and show acceptance progress. Bug tickets appear in the regular ticket system, get handled by the team, and the test is run again after the fix – until all tests pass.
For formal acceptance, you invite the customer as a guest user and review results together. Combined with the specification, this creates a clean cycle: the specification defines what should be built. The test suites verify that it was built. Both reference the same project tree.
Your project is implemented, the tickets are done. But how do you know everything actually works? Before you hand the project over to the customer, you need a systematic review. In this video, I will show you how to run test suites in Leadtime, document results, and create bug tickets directly when something fails.
In practice, acceptance often looks like this: someone clicks through the result, finds a few things, writes an email, someone else finds different things. In the end, nobody knows what was actually tested and what was not.
Test suites in Leadtime make the acceptance process reproducible. Every test case has clear steps and an expected result. The evaluation is documented. And when something does not pass, a bug ticket is created directly with the correct project assignment.
This protects you in two ways. You can show the customer that everything was tested systematically. And you have traceable documentation if there are discussions later.
In video 29, you saw how test suites are created in the component library. They are part of the project tree, just like work packages and checklists. When you import a component into a customer project, the test suites come along.
Test suites can also have conditions. Just like work packages: if the customer does not need an online shop, the shop test cases do not appear at all. Only what is relevant gets tested.
You find the tests in the project under Configuration, then Project Tree. There you see them as separate elements within the epics, usually at the end under "Testing and Quality Assurance".
I open a test case, for example "Responsive Design". It describes exactly what needs to be checked: open the website on desktop, tablet, and smartphone. Expected result: all layouts correct, no overlapping, all elements visible.
I click "Evaluate" and rate the test. There are three options. "Passed" means everything is fine. "Passed with limitations" means it basically works but with restrictions. "Failed" means the test did not pass.
With every rating, I can leave a comment. For "Passed with limitations", for example: "On iPhone 12, the footer menu is slightly shifted but still functional." For "Failed", I describe the problem.
The key part: when a test fails, I can create a bug ticket directly from the test result. With the correct project assignment and the context of the test. The developer immediately knows what needs to be fixed.
The test results flow directly into the Implementation Overview. You remember: the column "Done versus Total" shows progress. For test suites, this means how many test cases have been evaluated and how many are still open.
This way, you keep track of the entire acceptance process. If out of twenty tests, fifteen passed, three are still open, and two failed, you see that at a glance.
The bug tickets from failed tests appear in the regular ticket system. Your team works on them, and after the fix, you run the test again. This cycle repeats until all tests pass.
When all tests have passed, you have a complete documentation of the acceptance. Every test case with result, comment, and timestamp. This is your foundation for the formal project acceptance with the customer.
In practice, you invite the customer as a guest user and review the test results together. The customer can leave their own comments and confirm tests. This makes the acceptance transparent and traceable for both sides.
Together with the specification, you now have a clean cycle. The specification defines what should be built. The test suites verify that it was built. Both reference the same project tree.
Test suites make project acceptance systematic and documentable. Clear test cases, reproducible results, direct bug tickets when something fails. Together with the specification, you have a complete quality process.
In the next video, I will show you project billing. How to invoice your completed project, set up recurring payments, and analyze the financial results in the insights.
