0

I am a BA for a software company and we are in the middle of building a project for one of our clients and following waterfall methodology

When I showed the timeline to the client's project management team I had similar estimated mandays for QA and UAT steps but they asked me "why the QA and UAT are the same? UAT should be higher than QA"

Is this is a standard practice in project management? Can someone explain to me if this is true?

I have tried to look online or through project management courses but never found a result for this

4 Answers 4

2

I find it weird. First to estimate it and then to compare it against other steps as if they had any relation.

UAT should be done by the client. That is the "U" in "UAT". As such, you cannot estimate it for them. If they are nice, they can tell you what they think they will take, but that's probably a guess anyway.

How long the client takes has nothing to do with how long your internal QA department takes. There is no relation at all.

So what should have happend is to simply not estimate and ask your client how long they will take. Whether your client wants to base that on your own QA man-hours, roll his most trusted bone dice or maybe have a more scientific method is really up to them.

2
  • If we don't estimate UAT how are we supposed to define the project go live date? Jun 11, 2022 at 13:20
  • 1
    The same way as every other step in your plan. You ask the people who are supposed to do it, how long it will take.
    – nvoigt
    Jun 11, 2022 at 14:20
0

There's no rule like that, but generally, "QA" is a work delivered by subject matter experts with a managed plan but UATs ( of the client ) are checks done by non-subject matter experts without a plan as a side hustle :) So, UATs definitely take longer, especially if you do not timebox them.

0

Over time, people adopt planning biases based on their observations and these biases can eventually become hard truths. Their reaction to your estimates is no different than when anyone one of us is challenged on our biased beliefs no matter the topic.

We all do this to varying degrees.

They likely have a history of observing either planned or actual durations where UAT took longer than QA/QC activities.

I agree with an earlier comment where the customer typically provides, or is heavily involved, in the estimation of UAT so turn that back over to them and let them construct their BOEs to provide the UAT planning value to load in your baseline. Then, share with them your BOE for the QA stuff and let them comment on that based on how cogent you created it. But in all cases avoid any discussion about the relationship between the two work packages because, if it is indeed their biases, you will just spin wheels and it doesn't really matter. Just focus on the BOEs.

3
  • Thanks that's great suggestion, but as u know UAT involves defects fixing from our side (things that couldn't be found by QA) shouldn't we consider this as part of our estimation? Jun 11, 2022 at 13:27
  • You estimate what you plan to do, given your best guess or experience how long the planned task usually takes. Defect fixing is not a planned task - you don't plan to introduce 15 defects, each of which takes 3 hours to fix, so your estimate for defect fixing would become 45 hours, but you plan for an after-UAT meeting with the customer where a decision regarding deployment, bug fixing, or project cancellation due to irrepairable brokenness is being done. What comes then isn't plannable now. Jun 13, 2022 at 11:18
  • @GhaithAljamal No. If it isn't part of the specification or definition of done, then any "discoveries" during UAT are simply new work. Bugs should be caught no later than QA. Wanting something different than what was delivered is properly pronounced "change request" or "scope creep."
    – Todd A. Jacobs
    Jun 22, 2022 at 4:30
0

There's no hard and fast rule, but user acceptance testing (UAT) often takes longer than an internal quality assurance (QA) in waterfall projects.

Because QA doesn't focus on proving whether the client will accept the work, it doesn't test the same things in the same way. QA also doesn't lead to changing requirements, which UAT can (UAT shouldn't, in theory, but the practice is often very different, which is why a robust change request process is necessary in waterfall).

There's no strict equation over how much longer UAT should take than QA. In my experience, whatever you predict for UAT will be too short. If the client has a UAT function, you could speak to one of their UAT Managers and ask for their estimate based on the requirements and any acceptance criteria the project has at the time.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.