September 28 & 29, 2020 | Virtual
Please login or join to subscribe to this thread
It all depends on how you set up your contract and statement of work.
I usually start by building some functional testing into my scope to be completed by the project team before the software is provided to the client for acceptance testing.
You then have to discuss with the client if they will create their acceptance test cases or if they want to build them from yours. My preference is to let them do their own as it builds ownership as well as providing better testing coverage.
When it comes to acceptance testing, I usually go with at least two rounds of it. Each round includes acceptance testing by the client, testing support by the project team, and some allowance for rework. My first round is usually longer than the second.
The trick with client testing is to give them a period of time to do it in, for example 4 weeks. It is up to the client to recruit a sufficient amount of people to do the testing during that period. If the client decides to extend the duration of a testing round, you need to start talking change request with your client. Because your fixed price is based on a fixed scope, making the acceptance testing longer adds, at the very least, additional testing support.
In your scope statement, you should have negotiated what will represent completed acceptance testing. I usually do that by stating something like "all critical and important defects are fixed". The trick here is you need to define what critical and important means. Then you and the client review all defects and only assign them to the category if they meet the previously agreed definitions.
Now comes the hard part: providing support after going live. You have two choices. The first one - the one I prefer - is to make post-go live support time and material, rather than fixed price. The second one is to give your client a set number of support hours. For example, you can say that you will build in your project exactly 80 hours of post-go live support. The problem with this is that you need to have an operational agreement in place to pick up where your project ends.
Your contract or scope statement must clearly define each parties responsibilities beyond the project in terms of defects. You may wish to give them a set period guarantee beyond the project. Just make sure it's built into your price.
You should offer your client purchasable warranty or support options. If you do, be clear what are each other's responsibilities. For example, you allow a client to report a defect. You may do the triage to figure out if the problem is in your delivered product. If so, you may suggest that the fix will provided in the next product release. Of course, you can negotiate all kinds of permutations of responsibilities. Just make sure to price them accordingly.
This shouldn't be the case!
For the Software development projects, a Copy from the Production Software is validated through User Acceptance testing (UAT) before the launch of the Software application.
If for any reason later after the project is finalized and the product is delivered, a Customer has found a bug to be fixed, this should be addressed as a statement in the contract.
However, leaving it for just open time is not the right case, you should have very clear Scope with the client and a time frame to deliver according to the requirement.
Normally UAT has 1-2 rounds from the client side. First should be to uncover any missed defects, 2nd to have final testing. The cost of this if lies on your side then it should be calculated in CoQ (cost of quality). Also, known risks should be updated for this to have proper cost to cover.
So, if you want to save the cost for client found defects and sign the contract then requirements and quality management should be done well.
No. Eager to know how it works in product companies.
Please login or join to reply