0

In HPALM we have different options for 'Found in Phase', like: Construction, Implementation,Post Implementation,Initiation,and Strategy. How do we classify a defect to fit into one of these phases?

Ex: I understand "Post Implementation" would mean any defect reported when the application is in production.

Similarly, which defects fit in Construction/Implementation/Strategy?

1

There's a certain amount of flexibility in how you use these, although I'm sure the HPALM documentation has its own definitions for each of these items.

Ultimately, apart from Implementation and Post-Implementation (which are pretty obviously "while it's being developed" and "after it's done"), these categories are pretty vague and can mean whatever you want or need them to mean. The key thing is that your team all uses them in the same way and documents how they're being used so that everyone else knows what the terms mean in your environment.

That said, my suggestion would be:

  • Initiation - Depending on your methodology, this could mean problems that are found during project kick-off, problems found in requirements and/or requirements gathering, and so forth.
  • Construction - Again depending on methodology, this could be problems found in the functional specifications and/or use cases and/or user stories, or in any other design aspects or phases of the project.
  • Implementation - Most teams would use this to refer to problems found while the project was being coded. Realistically, most problems will fall here or in Post Implementation.
  • Post Implementation - As you've suggested, this would be problems found after the project has been completed. Customer-reported problems land in this bucket.
  • Strategy - This could refer to problems found with the project deployment strategy, problems found during the planning phase, problems with test strategy... I'd use this category to report problems with the process as distinct from problems with the software.

Honestly, when it comes to issue tracking, this isn't a particularly important piece of information. Things like a problem description that allows others to reproduce the issue, when and what version/build (for desktop applications) the problem occurs in, and how bad the problem is (does it crash the application or browser? Can the user work around it or not?) are the critical pieces of information.

| improve this answer | |
  • Thanks Kate. I agree with your last para. But its useful when we gather metrics. – Web Nash Sep 2 '14 at 12:19
  • Indeed Web Nash, Defects are much cheaper to remove if they are detected early (short after injection). So, these is a very valuable metris of your quality process. – Kris Van Bael Sep 4 '14 at 6:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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