Coming October 25: PeerSpot Awards will be announced! Learn more
Buyer's Guide
Application Lifecycle Management (ALM) Suites
September 2022
Get our free report covering Atlassian, GitLab, Microsoft, and other competitors of Microsoft Azure DevOps. Updated: September 2022.
632,779 professionals have used our research since 2012.

Read reviews of Microsoft Azure DevOps alternatives and competitors

RobertCampbell - PeerSpot reviewer
Product Manager at a insurance company with 10,001+ employees
Real User
Great for collaboration, very stable, and extracting data is straightforward
Pros and Cons
  • "You no longer need to email people. You can mention them right in Jira and have conversations there."
  • "In Jira, say on the team, no matter the methodology, it doesn't matter what I'm practicing, if I am using the tool for a while and I've compiled some sort of history. If I want to change my workflow, say my team is today using to-do in progress done, and tomorrow, I decide I want to use to-do in review and done, and I apply that new workflow, I have just now effectively lost all of my histories in terms of reporting."

What is our primary use case?

We are using the product for general task management, largely. From a software development community perspective, obviously, we use the task management piece - the foundation to what leads into the development and the CI/CD pipelines and et cetera. Outside of that, it varies widely. At its very core, it's task management, however, then it's used by various functional areas within the company. For example, we have contracting and procurement that utilize it. And we have marketing that uses it and security, IT security, audit, compliance. Various functional areas across the company use Jira. We use it a lot. More and more business teams are using it today than were previously.

We also use it for reporting. With task management comes the Jira out-of-the-box reporting. We had Advanced Roadmaps before it was included in the product. And now that it's just rolled into the Data Center product, you obviously don't have to pay for it specifically anymore, however, that's the most scaled reporting that we have. Then, as far as any other apps are concerned, we really just use time and status for measuring continuous flow and have more of a Kanban approach. Of course, some workflow, add-ons, and things of that nature to add some value such as training for Jira.

I'm less concerned about marketplace apps due to the fact that, whether you go to Azure DevOps or Microsoft, or whether you go to Atlassian, there are countless apps out there that will extend the application itself. 

How has it helped my organization?

It's an organized, collaborative, transparent way of working and that's really helped the organization overall. Otherwise, many teams would still be managing work in Excel spreadsheets and/or SharePoint, which is just ridiculous. At least this provides some sort of structured approach that can easily be queried and have data extracted. I use Jira for everything at work. I don't even use email that much. It's through @mentions and all these different things. 

What is most valuable?

The solution is great for helping teams to collaborate.

There are tons of apps and add-ons for the solution that help you expand its offering via third parties.

The product allows you to become very structured in your approach to work.

You no longer need to email people. You can mention them right in Jira and have conversations there. 

It's easy to extract data and do queries.

What needs improvement?

The way that Azure DevOps rolled out their boards and made them flexible is something that Jira lacks. You want a workflow and you're configuring your columns and you're mapping status to columns, however, in Jira, you can't have more columns than you do status. Whereas in Azure DevOps from a Jira admin perspective, it's amazing as it doesn't care what you need in terms of what your life cycle is. The underlying process template is very generic. It's just like a to-do, in progress, done ordering basically, except they use the words inprog or active, resolved, and a couple of others. Open, active, resolved, and maybe one more.

No matter what they do to the face of the board, they can create 15 columns if that's what they want to represent their lifecycle, which gives them that visibility and the ability to then report on that. The reports will run off of that, however, they never have to actually reach out to an admin and say, "I need you to build me a workflow." On the admin side of Azure DevOps, they could modify the underlying process template to include things like that would be the equivalent. They refer to them as rules in Azure DevOps, however, it would be the equivalent of post functions and validators and these things within Jira.

The great majority of teams don't care about that. What they care about is just being able to properly represent their lifecycle. It provides a great deal of flexibility and it cuts down a tremendous amount on admin having to build a workflow for each and every team that feels that their process is somehow different than everybody else's. It lets them basically self-organize. Agility, being able to just boom, build out their workflow as they see fit. That's the biggest thing that I've seen so far that Jira could really learn from.

In Jira, say on the team, no matter the methodology, it doesn't matter what I'm practicing, if I am using the tool for a while and I've compiled some sort of history. If I want to change my workflow, say my team is today using to-do in progress done, and tomorrow, I decide I want to use to-do in review and done, and I apply that new workflow, I have just now effectively lost all of my histories in terms of reporting. Now the issues themselves, of course, the activity, the history, all of it is still there, but you lose all your boards. Not the boards per se, but the reporting within them. That includes all of my past sprint burndowns, all my past velocity reports, some of that stuff gets completely wiped away. The only way to restore it is to replace the original workflow. It's insane. It's the way that the application is built and it's all tied in with it. I had it explained to me one time by Atlassian, however, it's just really a bad thing - especially when you're in a large enterprise organization and then you get somebody like me that comes around that they hire to come in and be the product manager. The first thing I say is, "We need some fricking governance. You can't have 100 plus statuses. What the hell is this? Or 500 custom fields that half the people aren't even using."

The statuses in the workflow standardization become virtually impossible as I can say, "Hey. This workflow that you're using is a terrible workflow. Let me fix it for you. Let me give you a better workflow. Let's talk about this. Let's build a really good workflow." We need to go through that pain and then I have to tell them that, "Oh, and by the way though, if you adopt this new workflow that I'm sitting here telling you it's going to be so much better, be advised that you're going to lose all your reporting history." How do you think that's going to go? Probably not so good. That is a huge downfall. 

For how long have I used the solution?

I'm an avid user of Jira and I've been using the product for at least a decade. At my company, I'm the product manager, however, I'm also the Jira admin support desk, and I wear all the hats for 4,000 plus users. Therefore, I'm very familiar with Jira. 

I'm learning Azure DevOps as well, mostly due to the fact that I'm being forced to. The company is adopting Azure DevOps. I'm fighting to keep Jira around. It still has the value that it adds to the company. The business side of our company is largely embedded in the tool. 

What do I think about the stability of the solution?

The stability is excellent. I've never had any issues. If anything, it's probably one of our more stable products.

What do I think about the scalability of the solution?

I have found it difficult to scale. With the Advanced Roadmaps, we do have the ability to add additional layers of hierarchy. However, that's been a struggle at our organization as we're trying to adopt a Scaled Agile Framework. Unfortunately, with the Advanced Roadmaps for Jira, the hierarchy is very inflexible, which I've actually opened up a ticket with Atlassian on. 

With the Scaled Agile Framework, you need to be able to move from the program - what was once called referred to as the program layer - and you may have a large solution layer, or you may not. If you don't, you go directly to the portfolio layer. That said, in Advanced Roadmaps, it's very inflexible. You can't skip a level if you want to. You have to go through this regimented hierarchy, which does not bode well for a Scaled Agile Framework environment. I've never been able to crack the code on how to get around that.

Also, the reporting in Jira seems to be very team-oriented. Yes, you can create boards and things using queries and combine items, however, I find it difficult to scale without an additional app or plugin. For example, if you've got a program and you've got a bunch of teams that are supporting said program, I find it difficult to be able to scale and show a program increment, a PI. That level of reporting is lacking. I know that there are apps out there for that. However, unless you're willing to spend a small fortune on a lot of apps, well, the core product doesn't scale above that of the team level.

The solution is extensively used in the company, and we are quite sizeable. We have about just under 4,000 active users. It used to be used it was 5,000 and then COVID hit and we lost a lot of contractors that were cut when COVID hit. It's that mostly and then some of the users are being siphoned out of the Atlassian tool stack now into Azure DevOps.

How are customer service and technical support?

99% of the technical support staff have been awesome. We actually have premier support. They seem to be very responsive and very helpful. Where I personally get frustrated is if there are issues and we give feedback and advice, and they respond with a "thank you, however, we aren't changing". They will tell us it's not a priority for them right now, and it can be frustrating. 

There's a lot of different things out there that people feel that should be included as basic functionality within the application. Maybe some of those I agree with, some of them maybe not. However, when I see something that I consider a bug and then they tell me that, "Yeah, that's not a priority right now." I find that very frustrating. Just now, I was trying to configure the application for the ability to create or comment on issues by setting up a mail server. And there's a known bug. I don't know if they consider it a bug. However, when you configure that and somebody actually does reply to a system-generated email notification, it will add it as a comment, which is great, yet it will also automatically attach your profile picture to that issue.

Therefore, as many times as you comment or reply via an email is exactly how many times an attachment will be added to your issue, which obviously is ridiculous. That cannot be purposely designed that way. Who wants attachments of your own face added to an issue? And it just takes up space needlessly. Their response to me was, "Well, that's just not a priority right now." Basically, not enough people have complained about it yet and they must not be using that functionality, therefore they're not worried about it.

How was the initial setup?

I wasn't at the company when they originally set this solution up. There are certainly some things that I would do differently in hindsight, however, I wasn't here when they set it up originally and can't speak to what the process was like.

What's my experience with pricing, setup cost, and licensing?

Pricing information you can just get right off the internet. Atlassian is notorious for not negotiating. They have never negotiated up until very recently. They've started to negotiate contracts as they're really trying to push the cloud. They're trying to get people to move to the cloud. In some cases, they are willing to negotiate costs if you're willing to move to the cloud. Not only costs. Terms. They treat everybody equally, which honestly, I respect.

However, large enterprise organizations like the one I work for, hate it. They hate that as they feel like they have some sort of clout or they need to be able to throw their weight around a little bit and they needed to be treated specially. One of the biggest things that hurt Atlassian is its unwillingness to work directly with large enterprise organizations. It works well with smaller companies, however, their approach to large enterprise organizations really hurts them. The Microsofts of the world will send you a whole crew of people that will come in and do demos and meet with your senior executives. Atlassian has that in the equivalent of a TAM, technical account manager. 99% of the time if you call Atlassian, they'll say, "Whoa. You work with one of our third-party vendors." Which, okay, there's a ton of third-party vendors that are fantastic I'm sure, however, people want to see Atlassian. When you get into a larger enterprise organization, they don't appreciate the fact that an Atlassian representative can't come in and take the time to meet with people and do these things when they're spending that kind of money. It doesn't bode well. They really don't like it.

That's largely why they're being pushed out of Jira and onto other solutions. Microsoft, for example, has invested time and energy. Microsoft has also negotiated terms and pricing. Large companies would rather have a relationship with a company like that than a company that doesn't negotiate or come to see you.

Which other solutions did I evaluate?

I've started to look at Azure DevOps. I am personally the Jira product manager, and what I'm trying to do is have some sort of comparison. It all became very sudden. I was recently asked if, by the end of the week, I could provide a recommendation as to when one team should use Azure DevOps versus when one team should use Jira. I was told to look into why we should use one over the other or if they are so similar that it doesn't matter and we could just get rid of Jira. I've done very little research so far,

Obviously, Microsoft and Atlassian are competitors. Back when Azure DevOps was TFS, it wasn't even a close comparison in terms of boards. Jira blew TFS out of the water. It wasn't even remotely close. Well, then they obviously knew that they needed to improve and they basically made freaking boards look like Jira's boards and made some improvements on top of it in some ways. I suspect that there may be some underlying limitations with DevOps. I know that in Jira you could allow teams to just create the workflows that they want within reason, of course, while pulling from a series of predefined statuses and these things. Whereas, I don't know that you can do that in Azure DevOps. But then again, I don't know that it's necessary since you can already create the boards the way you want to.

I know that some people so far from customer feedback, tend to like the dashboards more in Azure DevOps. They seem to like the reporting options. They find it easier and more intuitive to use, however, I don't really know anything more about it than that. I just need to really know the pros and cons of each of these things. Here's what's surprising to me, if I'm at Atlassian or if I'm Azure DevOps or Microsoft, you would think that they would have something like that. You would think they'd be going, "Who is my biggest competitor? Well, I need to know these things so that I can improve my product and compete with him." However, when I reach out to them, I don't have any real comparison to work off of.

I did find one article online that was written by Atlassian and Azure DevOps versus Jira, however, it wasn't well-written.

What other advice do I have?

We're just customers and end-users.

I upgraded the application back in December, so we're on 8.13 right now. While we're currently on-premises, one of the things that were on my to-do this year was to consider moving to the cloud, which is something that we are very interested in doing.

Currently, we're using the Jira Data Center.

Our company has barely scratched the surface of the power of Jira in my personal opinion as they've just largely tried to do a bunch of customization. There was no governance set when I first joined the organization. People were just allowed to create whatever they wanted in any way they wanted, and it needed to be cleaned up, which doesn't help my efforts of course. 

There might, in the near future, be many people who get siphoned off of Jira as the company already made a decision that Bamboo and Bitbucket are going. They're moving all the software development activities into Azure DevOps. We already know that. That's already been decided. Atlassian doesn't know that, however, it's happening. The process is probably going to take a year, maybe two. We haven't really rolled it out yet or defined or planned it out. That said, it will happen. Whether or not Jira sticks around though, we don't know yet. I'm hoping it will as I love using it.

I'd advise new companies that one of the biggest things to do at the outset is to just put some governance in place before you go rolling out. It's a super-powerful application. However, if you are in a large enterprise organization, you need to establish an advisory board before you go rolling this thing out. Really think about a steering committee. How are you going to handle requests for customization? What will the board handle? What will the board not handle? Or the committee, whatever you want to refer to it as. They obviously did not do that here when they rolled this out. It can be a really great thing if you have that in place. It's not overly cumbersome.

I'd rate the solution at an eight out of ten.

Which deployment model are you using for this solution?

On-premises
Disclosure: I am a real user, and this review is based on my own experience and opinions.
Implementation Consultant at a healthcare company with 201-500 employees
Consultant
Useful for seeing if we are on target for work, but it is not intuitive and should have easier and user-friendly reporting without having to use the Excel add-in
Pros and Cons
  • "We use the roadmap features, and we're getting better at using dates to use the roadmap so that we can see if we're on target for work."
  • "What I don't like about it is that it is really hard to find old work to reference information and use the reporting section of the application in terms of trying to analyze trends. If I am trying to find out which interfaces took this long and I want to compare and measure improvement from one quarter to another quarter, the reporting mechanism within Rally is very troublesome. They have an Excel plugin that you're supposed to use, but you literally have to pull the raw data out before you can do the analysis. You can't do it within Rally, and if you can, it is a secret, and I don't know how to do it. It should have better, easier, and user-friendly reporting without having to use the Excel add-in. It is very clunky. There is a lot of data in there, but it is not organized in such a way that makes it intuitive. You really have to kind of look for where do you put your documentation or dates. Some customization is available, but it is not plug-and-play like Jira. When I switched from TFS to Jira, I just went and started using Jira, whereas with Rally, you kind of have to really get in and figure out what you need to do before you set stuff up, or you're going to get yourself stuck. You can just start using Jira and be successful."

What is our primary use case?

It is used to track any enhancements or new integrations. We have integrations from mainframe systems to RESTful services. We also have a few SOAP integrations. Essentially, we use the feature level of Rally to document what the interface is and then the engineers make the user stories within the feature to represent the tasks that they need to do to complete the interface, which includes everything from making the design document to the activities that they do in IIB, such as deploying the code to production. Our version has probably been updated within the last three months.

How has it helped my organization?

It is kind of set up for Scrum or Agile, but we sort of use it more in a kind of hybrid way. It does help build accountability because, during stand-up, you have to see what everybody is doing, why certain things are in red, and why someone is not where he or she is supposed to be.

What is most valuable?

We use the roadmap features, and we're getting better at using dates to use the roadmap so that we can see if we're on target for work. 

What needs improvement?

What I don't like about it is that it is really hard to find old work to reference information and use the reporting section of the application in terms of trying to analyze trends. If I am trying to find out which interfaces took this long and I want to compare and measure improvement from one quarter to another quarter, the reporting mechanism within Rally is very troublesome. They have an Excel plugin that you're supposed to use, but you literally have to pull the raw data out before you can do the analysis. You can't do it within Rally, and if you can, it is a secret, and I don't know how to do it. It should have better, easier, and user-friendly reporting without having to use the Excel add-in.

It is very clunky. There is a lot of data in there, but it is not organized in such a way that makes it intuitive. You really have to kind of look for where do you put your documentation or dates. Some customization is available, but it is not plug-and-play like Jira. When I switched from TFS to Jira, I just went and started using Jira, whereas with Rally, you kind of have to really get in and figure out what you need to do before you set stuff up, or you're going to get yourself stuck. You can just start using Jira and be successful.

What do I think about the stability of the solution?

It is kind of hit and miss. Sometimes, it is really reliable. I'm not sure if the delays that we see intermittently when it hangs up are because we've all gone remote now, and there are different people with different types of remote devices. I don't know if they are because of Rally.

What do I think about the scalability of the solution?

Different teams that I've been with in the same organization use different tools. I have used TFS and Jira. I would go back to Jira or TFS in a minute. I don't find Rally good for scaling what we're doing. A good percentage of this part of my organization does use Rally, but I don't find it conducive to building transparency across the organization. We should either have TFS, Jira, or Rally. However, because of the lack of reporting, Rally won't be suitable and scalable for the whole organization. People want to see and measure what teams are able to do, and if they can't do that quickly, senior leadership is not going to be on board. If every team had to dig as much as I have to dig, it is not scalable.

In terms of users, we have implementation consultants, which is kind of a hybrid role between a BA, a PM, and a QA. We also have engineers, application developers, business analysts, managers, project managers, and directors. We have senior leadership, like AVPs, who periodically go in there and look at stuff randomly, but for the most part, it is usually used by managers and frontline staff like myself. About 80% of teams in our business unit are using Rally. My team has 15, but the number is easily more than that.

How are customer service and technical support?

I have not had to deal with them.

What other advice do I have?

I would advise others to make sure that they have full training in terms of the connection between features, user stories, and epics. They should also fully understand how to configure it in terms of providing visibility across teams that have to work with each other.

I would rate Rally Software a six out of ten.

Which deployment model are you using for this solution?

On-premises
Disclosure: I am a real user, and this review is based on my own experience and opinions.
AnujKataria - PeerSpot reviewer
Project Manager at Duck Creek Technologies
Real User
Top 10
One-stop solution that is useful, and makes things easier to manage, but the burndown charts are problematic
Pros and Cons
  • "Basically, the capacity to construct various products is something I find handy."
  • "I'm looking for specific options that aren't currently available, such as active status, new status, or what's currently in progress."

What is our primary use case?

We use TFS for project management.

What is most valuable?

Basically, the capacity to construct various products is something I find handy. For example, I could write a user story and then add some tasks to it, as well as subtasks and test cases.

Everything can be linked together, making it easy for us to track down and document hours for each and every task, whether it's a task, above, or anything else.

Everything is interconnected. As a result, tracking and viewing the bulletin board dashboard and burndown charts, among other things, is much easier.

It's a one-stop solution that is useful and makes it easier to handle.

What needs improvement?

The overall ability in the Agile process has some room to improve, even though it is interconnected. When I worked on Jira, it had the capability of better linkage.

When it comes to project management, we are having trouble with burndown charts, which we can't seem to display. As a result, we have created new tasks and realigning our process. Rather than creating larger tasks, we are creating subtasks such as development tasks, QA tasks, and deployment tasks.

An area of improvement is when there is a login for a specific user story present, it should display automatically. This is an area that where we are having difficulty and struggling in.

The scalability can be improved.

Linkage and task management are two areas that we are having difficulties with. It could be more like Jira, which has a number of different plugins. In addition, I feel that the status should include additional options. For example, they offer fewer options for a specific task user story or bugs.

I'm looking for specific options that aren't currently available, such as active status, new status, or what's currently in progress. I would like to see an in-progress capability where you can mark it active, but you can also write that it is in progress. When I look at the dashboard, there is nothing there to show me what has been done or why it is active or not.

For how long have I used the solution?

My company has been using TFS since it started. It may be more than 10 years. I joined the company a year ago.

We have been using it through the cloud during COVID and working from home. We can connect to it from any network.

What do I think about the stability of the solution?

There have been some lags in the past, and we have also encountered some latency when setting it up on the laptop. You may have some problems at first, but as soon as you connect to the internet and update your product, everything becomes stable.

Within our organization, for example, we use Microsoft Teams for communication, chats, and for calls. We had some issues with it being unreliable and not fully airing the sound over the laptop speakers and mic. I discovered that as soon as we updated the product, the stability was restored. There was a problem with Teams, which they fixed and updated.

Initial difficulties are to be expected, but things are constantly improving.

What do I think about the scalability of the solution?

It can be scaled to some extent. The main issue is that, unlike Jira or any other tool, the burndown chart is not displayed.

How are customer service and support?

I have never used technical support because I've never been in a situation where it has gone down and I needed to contact them, but I believe that because Microsoft is a reputable organization with adequate technical support right now.

Which solution did I use previously and why did I switch?

I have also worked with Jira.

I come from a QA background, and we used to do automation. Jira was far easier to integrate with our QA automation frameworks because it has a large number of exposed APIs and public APIs that we could use, which is a positive development. Also, the burndown charts, as well as the ability to manage different Agile model frameworks, where we could use scrum in one project but also had to use Kanban. As a result, the transition from one framework to another was simple. These are the things I found useful but haven't seen in the case of TFS yet.

How was the initial setup?

Initially, TFS was a bit complicated. Now that it's Azure DevOps the initial setup is much easier.

It's a one-stop shop for building code repository, and a version control system within TFS or Azure DevOps, as TFS has been renamed.

What other advice do I have?

I am a project manager.

I would rate TFS a seven out of ten

Which deployment model are you using for this solution?

Public Cloud
Disclosure: My company has a business relationship with this vendor other than being a customer: partner
Filipe-Marcelino - PeerSpot reviewer
Head of Digital Solutions at Bravantic
Real User
Simple to set up, stable, and has Auto DevOps features
Pros and Cons
  • "The most valuable functionality of GitLab, for me, is the DevOps. Besides the normal source control based on Git, I find the Auto DevOps features most important in the solution."
  • "As GitLab is not perfect, what needs improvement in the solution is the Wiki feature of the groups or the repertories because currently, it's not searchable by default. You'll need an indexing service such as Elasticsearch to make it searchable, and that requires too much work, so for me, it's the main feature that should be improved in GitLab. In the next version of the solution, from the top of my head, the documentation could be improved. Besides the Wiki, it would be good if there's documentation that would be automatically generated based on the code repository. In other words, there should be some tutorials from GitLab for developers in the next release."

What is most valuable?

The most valuable functionality of GitLab, for me, is the DevOps. Besides the normal source control based on Git, I find the Auto DevOps features most important in the solution.

What needs improvement?

As GitLab is not perfect, what needs improvement in the solution is the Wiki feature of the groups or the repertories because currently, it's not searchable by default. You'll need an indexing service such as Elasticsearch to make it searchable, and that requires too much work, so for me, it's the main feature that should be improved in GitLab.

In the next version of the solution, from the top of my head, the documentation could be improved. Besides the Wiki, it would be good if there's documentation that would be automatically generated based on the code repository. In other words, there should be some tutorials from GitLab for developers in the next release.

For how long have I used the solution?

I've been using GitLab for almost three years.

What do I think about the stability of the solution?

GitLab is a pretty stable solution, and on a scale of one to ten, with one being the worst and ten being the best, I'm rating its stability a ten. My team just learned some details about the configuration of GitLab, so it's now tuned up, and right now, there's no problem with the stability of the platform.

What do I think about the scalability of the solution?

In terms of GitLab scalability, based on its features, it's supposed to scale easily enough geographically, but my company hasn't tried scaling it yet. It shouldn't be a big problem to scale the solution.

How are customer service and support?

In terms of the technical support for GitLab, I mainly use the forums and support sites of the solution. I don't use the direct technical support line of GitLab.

How was the initial setup?

The initial setup for GitLab is simple mainly because of all its features that allow you to make a startup instance of the solution simpler and quicker, and that's very good.

What's my experience with pricing, setup cost, and licensing?

In terms of the pricing for GitLab, on a scale of one to five, with one being expensive and five being cheap, I'm rating pricing for the solution a four. It could still be cheaper because right now, my company has a small team, and sometimes it's difficult to use a paid product for a small team. You'd hope the team will grow and scale, but currently, you're paying a high license fee for a small team. I'm referring to the GitLab license that has premium features and will give you all features. This can be a problem for management to approve the high price of the license for a team this small.

Which other solutions did I evaluate?

We evaluated Azure DevOps, but we liked the style of how things are built up inside GitLab for the end-user and the developer more compared to Azure DevOps, though Azure DevOps is also a very good choice.

What other advice do I have?

I'm using the latest version of GitLab.

My company has a small team and only has six users of GitLab.

On a scale of one to ten, where one is the worst and ten is the best, my rating for GitLab, in general, is nine. My company likes the solution very much, especially over Azure DevOps.

I would recommend GitLab for others to use.

My company is a customer of GitLab.

Which deployment model are you using for this solution?

On-premises
Disclosure: I am a real user, and this review is based on my own experience and opinions.
Flag as inappropriate
National Solutions Architect at a computer software company with 10,001+ employees
Real User
Top 5
Lots of features for testing, scalable, and good linkage and traceability between the test cases and the defects
Pros and Cons
  • "It is a tool, and it works. It has got good linkage and good traceability between the test cases and the defects. It has got lots of features for testing."
  • "It can be quite clunky, and it can easily be configured badly, which I've seen in a couple of places. If it is configured badly, it can be very hard to use. It is not so easy to integrate with other products. I've not used Micro Focus in a proper CI/CD pipeline, and I haven't managed to get that working because that has not been my focus. So, I find it hard. I've often lost the information because it had committed badly. It doesn't commit very well sometimes, but that might have to do with the sites that I was working at and the way they had configured it."

What is our primary use case?

When I use it, it is mostly for test management. The instances I've used are mostly on-prem.

What is most valuable?

It is a tool, and it works. It has got good linkage and good traceability between the test cases and the defects. It has got lots of features for testing.

What needs improvement?

It can be quite clunky, and it can easily be configured badly, which I've seen in a couple of places. If it is configured badly, it can be very hard to use. It is not so easy to integrate with other products. I've not used Micro Focus in a proper CI/CD pipeline, and I haven't managed to get that working because that has not been my focus. So, I find it hard. I've often lost the information because it had committed badly. It doesn't commit very well sometimes, but that might have to do with the sites that I was working at and the way they had configured it.  

The feature that I would have liked to see is more integration into CI/CD pipeline and agile pipeline. It should have integration with third-party tools such as Jira, DevOps, and the cross-platform type of thing. The versions I've used are older, so these features may have already been included in the new versions.

For how long have I used the solution?

I have been using this solution for 10 to 12 years.

What do I think about the stability of the solution?

I've had many cases where I've lost data. I had bugs where I couldn't record, and the records got lost or locked, but rather than the actual product, it had more to do with the way it was set up at the sites I was working at.

What do I think about the scalability of the solution?

It is scalable. I've seen big organizations using it.

How are customer service and technical support?

I've not had to deal with technical support.

Which solution did I use previously and why did I switch?

I also use Microsoft Azure DevOps. I don't really have a preference. It is horses for courses, and it depends on the type of application you're running. For older style waterfall projects, you can probably go with Micro Focus, barring pricing and others things. For agile or particularly a Microsoft Azure-based product, I would go with DevOps because of the better pipeline and the whole end-to-end integration.

How was the initial setup?

I never had to set it up from scratch.

What's my experience with pricing, setup cost, and licensing?

I've never been in the procurement process for it. I don't think it is cheap. Some of the features can be quite expensive.

What other advice do I have?

Generally, it is pretty good for what it does. As a standalone tool for managing testing, it is good.

I would give Micro Focus ALM Quality Center an eight out of 10.

Which deployment model are you using for this solution?

On-premises
Disclosure: My company has a business relationship with this vendor other than being a customer: Implementor
Buyer's Guide
Application Lifecycle Management (ALM) Suites
September 2022
Get our free report covering Atlassian, GitLab, Microsoft, and other competitors of Microsoft Azure DevOps. Updated: September 2022.
632,779 professionals have used our research since 2012.