What is most valuable?
- Cross referencing between the modules: Insures traceability between requirements, tests and defects with easy maintenance and reporting.
- Traceability: Ensures that requirements are covered, test cases can be linked back to defects, and code is not pushed to production without testing or checking outstanding defects. Traceability reports are an audit requirement.
- Having the links maintained within the tool is a huge boon to reporting requirements, tests, and defects.
How has it helped my organization?
Having a system of record that maintains traceability ensures that reporting and audit items are managed in the same system. This has simplified the need for additional documentation to meet audit requirements.
What needs improvement?
- Cross project reporting is limited to similar database schemas
- Requirements are not managed as well as in other applications
For how long have I used the solution?
I have used this product since 2003.
What do I think about the stability of the solution?
We have a large ALM instance. The biggest issue with stability is related to reporting. To offset this issue, we are working on an alternative reporting solution that would use data warehousing and not affect the application directly.
What do I think about the scalability of the solution?
There are scalability issues. HPE does not support clustering of database servers.
In addition, a specific number of users, concurrent usage, or databases has not been supplied by HPE as a best practice for a maximum per node. To obviate this risk, we are looking at leveraging three load balanced servers and one standalone application server.
The standalone server would be used for third party integrations, reporting, etc. End-users and automated tests would leverage a single vanity URL with load balancing spread across three servers.
How are customer service and technical support?
We have HPE FlexCare. This provides for single points of contact, which is a must with a large organization.
Training is becoming an issue again with HPE technicians. That glib answer of issues being ‘fixed’ in a later release is being provided instead of true research of the issue. This is an ongoing problem we have seen working with them over the past ten years.
Which solution did I use previously and why did I switch?
We still use a variety of SDLC tools within my organization. However, HPE ALM has been determined to be the best all around solution for testing of software across the enterprise.
We are doing a number of activities to reach a common goal, including leveraging the ALM template functionality and defining fields and list values across all testing applications.
How was the initial setup?
HPE ALM Quality Center, (formerly HP Quality Center, and before that, Mercury Test Director), has been in use for over 10 years.
It is easy enough to set up an ‘instance’ of HPE ALM.
However, it is recommended to understand the business and process it will be supporting. This will ensure that standards, additional fields, etc. are incorporated early in the design.
If decisions on how the application will be used are not defined early on, then a later project to standardize it may be required.
Without standards, data cannot be shared easily between ALM projects, databases, and third party tools.
What's my experience with pricing, setup cost, and licensing?
If you have more than five users, a concurrent licensing model should be considered. With concurrent licenses, there is no need to search for machines with unused licenses.
What other advice do I have?
- Be thoughtful and consistent.
- Know your current business process and incorporate it into the application.
- Ensure that the management is handled at an enterprise level, as opposed to a department or group level. This allows the application to grow in a supportable direction, while allowing a certain amount of flexibility.
Which version of this solution are you currently using?