Top 8 Test Management Tools

Micro Focus ALM Quality CenterTFSTricentis qTestVisual Studio Test ProfessionalZeenyx AscentialTestTestRail by GurockBroadcom Agile Requirements DesignerZephyr Enterprise
  1. leader badge
    The integration with UFT is nice.It's fairly user-friendly. It was quite easy to use.
  2. leader badge
    Some of the valuable features are version control and the ability to create different collections in terms of segregating the authorization for teams who connect to small projects.
  3. Find out what your peers are saying about Micro Focus, Microsoft, Tricentis and others in Test Management Tools. Updated: May 2021.
    502,335 professionals have used our research since 2012.
  4. leader badge
    The most valuable feature is reusing test cases. We can put in a set of test cases for an application and, every time we deploy it, we are able to rerun those tests very easily. It saves us time and improves quality as well.
  5. The stability has always been very good.The ability to quickly make your own components has been valuable.
  6. It’s been really easy to automate the same application TestComplete struggled with. I have been able to automate two of our key applications in just a few months. I haven’t even taken their training.
  7. From a testing perspective, the management is awesome. I am able to do testing and then add the reporting and the evidence. It is fair in terms of the price that you're paying. You get what you're paying for.
  8. report
    Use our free recommendation engine to learn which Test Management Tools solutions are best for your needs.
    502,335 professionals have used our research since 2012.
  9. CA ARD has some beautiful features which I haven't found anywhere else. For example, when designing or creating our test cases and doing scenarios, we are able to restrict our flows. If we take a data link between two processes, we can actually restrict it, so that, in production, if our functionality breaks down, we can restrict that and all the flows related to it will be removed from the test data set.
  10. It has many features, but the main things that we need are the test cycles and integration with automation because we have automation for the web and mobile applications. We use it for test case management to run the test cases and get the results. At this moment, it is fulfilling our requirements. We are able to get the test execution report and the test pass and fail report. This summary is delivered to our management.

Advice From The Community

Read answers to top Test Management Tools questions. 502,335 professionals have gotten help from our community of experts.
There seem to be 2 different approaches in test management - BDD and TDD. What are the differences between these approaches, and what are the relative pros and cons of each? Thanks!
author avatarJulio De Lima
Real User

BDD is not about testing. It is about to have common sense about the application behavior and use this to develop a piece of software. As I mentioned, "to develop" software. Testing comes before and after it, not in it. Testers are part of the definition, he/she collaborates with the Developer and the Product Owner by defining the scenarios or examples that will be used by the developers during the coding. A big part of the companies misunderstood it and I believe I know why. Test Automation is something that works perfectly when developers and testers work together creating and maintaining the test scripts, but since the first time I heard about test automation, the tester was put as the exclusive owner. Also, the first time I heard about Cucumber, it happened again, testers being the owner of it. But, look, testers are not developing software in the companies that adopted Cucumber. So, where are the second "D" in the mnemonic "BDD"? If testers are not developing software, it is anything different than Behavior Driven Development. Summary of all, BDD is a development method used by "coders" (it includes the tester if he/she are programming the software the client will use in the future) where they look at the same behavior that he/she defined together with the tester and the Product Owner, and start to code focusing in to develop a software that is obeying that scenarios. It is not about testing.

Let's see an example:

Moment 1*: tester, developer, and PO meet and discuss a brand new feature
Moment 2*: they define some examples to describe better how this feature will be used by the user
Moment 3: they decide to write the examples in Gherkin, cause it is a common way to describe things
Moment 4: Three scenarios are written, it is not related to API or UI, it is written in a descriptive way instead of an imperative way (it is not an IEEE-829-1998 test case)
Moment 5A*: The API developer use the Gherkin feature files to create snippets to defined previously the way the API will be used after it became done
Moment 5B*: The UI developer does the same
Moment 6: Once the three scenarios were achieved, they are done with the task
Moment 7: the tester will take the software that already obeys the scenarios defined collectively in the Moment 3 and start to run the tests planned based on the features described in the Moment 1 and 2;
Moment 8: Tests passed, feature done.

(*) The tester is using the information get here to help to define him/her test strategy or even helping the team to understand better how to produce a better software


- Favor the collective understanding of the software;
- Brings the developer to think in the user;
- Backend, Frontend, and Testing guys know exactly what will be delivered.
- Produces a lot of documentation


- It takes time to do it right
- Produces a lot of documentation
- It is difficult to find documentation about the right way to do it

TDD is also aiming to focus the software creation on something different than tables, classes, interfaces, and repositories. The developer thinks about the feature to be created, then he/she defines what are the tests that will prove the piece of code that will be developed works as expected. These tests are written and run, it breaks in the first moment. The developer produces software code to achieve the test passing. After that he/she refactor the code to improve it since now they are confident that the test will validate that the code is working under that combination and state. Again, who produces the tests in the TDD approach are the coder (tester or developer who is going to implement a feature).

Let's see an example:

Moment 1:* The developer already know what should be developed and what kind of tests can prove it is working properly;
Moment 2*: He/she write eight test methods (in the project they are using to produce the software) exercising the conditions they believe that proves the software are working properly;
Moment 3: Now, the developer starts to code the software in order to make the eight tests pass;
Moment 4: It is good, let's mark it as done.
Moment 5: The tester will take the version to test with my 8 million test design techniques or my abilities to explore the software

(*) The tester can be consulted by the developer to teach some testing techniques that help the developer to assure what he/she is going to produce are working.


- Favor the software architecture
- Brings coders to the point where they need to think about testing in the very first moment
- Better code


- Does not works if you have a coupled legacy code
- A low number of developers doing this

author avatarWaqar.tufail

In TDD (Test Driven Development), the test is written to check the implementation of functionality, but as the code evolves, tests can give false results. BDD (Behavior Driven Development) is also a test-first approach, but differs by testing the actual behavior of the system from the end users perspective

You can consider as a example
TDD do not have specific file to write the test Case in Grammar language which describe the Behavior of application as a End User

BDD have the feature file where you can write simple language test case which simply describe that what is the scenario and what steps are going to execute

Scenario: Validate the Login Module
User open the Application
Enter the credentials and Click on Login
He should be redirected to Dashboard

All the code will be bind with these steps and report will have only above lines with the status

author avatarNancyMcClanahan
Real User

Test-Driven Development (TDD) is an "inside out" focused process. To understand the process, one needs to know that the writer of the test cases is written at the same time as the code or Build. So it is the developer that writes the tests. To answer, "Who reads the tests?" It is the Developers and the Testers. It's unlikely that anyone else will read them. Then it is essential to provide specificity. When testing a new department with a unique workflow, and the test fails - a defect is created, and the failure analyzed. It is known that the build of the area is where the fault is located. The Developer or Builder does a Unit Test on the component/module, which is in isolation—making a mockup may be required, but is (potentially slow) and has external dependencies. As a result, Unit Tests are super-quick to run. The higher the level of code or build coverage, the better the developer, Quality Assurance, and Project Manager will sleep at night. But 100% code coverage is rare/difficult to achieve where Unit Test is concerned, which leaves gaps in risk management that need to be discovered and tested. Also, any change to the functionality of the system will require a modification to one or more Unit Tests. (Remember: the tests change first!) Unit Tests are highly specific to the code that they cover; they are intertwined with interfaces and other models. Unit Tests are not transferable and will require version control.

Behavior Driven Development (BDD) is an "Outside-in" focused process. To maintain comparison consistency, we need to answer, "Who writes the tests?" The plain English format means that the tests can be written by the person that understands the customer the best: the Product Owner or Operations owner. Then to answer, "Who reads the tests?" Almost anyone: Developers, Testers, Stakeholders, Business Owner, Product Owner. The specificity is based on the coding of the module build. When there is a defect, we know something is wrong, but we have to investigate to find out what is wrong. Behavioral Tests are tests of the system as a whole. At Parkview Health, we consider this integration testing. The system must be "put into a known state," which is all builds for each module that has to be in the testing environment before every test cycle. Not particularly difficult to do, but not quick either. When defects show up, they have to be fixed in the build, but the test case stays the same. Code or build coverage percentages for Behavioral Tests tend to be high. 100% code coverage is not uncommon. Not all functional changes impact the external behavior; the high-level nature of Behavioral Tests means that they change infrequently. Behavioral Tests are not coupled to code. Without changing a single test, the Test Coordinator can:

• Rewrite the module or application in a different programming language;
• Refactor or influence the massive application into a set of Test cases by the workflow.
• Fix a defect and start a new cycle

In summary, the first step of the project is to discuss the behavior of the software or feature to be built. BDD is a methodology for developing software through continuous example-based communication between developers and business. This communication happens in a form that both the business and developers can clearly understand. The business owners talk in requirements to the developers, and developers talk in examples. The value of BDD is as follows:

• A better understanding of the business operations
• Better ideas
• Developers can improve the systems
• Developers can help the business reach their requirements

TDD focuses on the developer's opinion on how parts of the software should work, and BDD focuses on the user's view on how they want the application to behave. When using BDD, it is all about functional testing and specifying the behavior. The story BDD helps ensure that the development team understands the business on the same level that the client does, adding value to the released software or build of the software.

author avatarDiego Caicedo Lescano
Real User

Behavior-driven development (BDD) is an Agile software development methodology in which an application is documented and designed around the behavior a user expects to experience when interacting with it. By encouraging developers to focus only on the requested behaviors of an app or program, 

PROS: BDD helps to avoid bloat, excessive code, unnecessary features or lack of focus. This methodology combines, augments and refines the practices used in test-driven development (TDD) and acceptance testing.

See more Test Management Tools questions »
Find out what your peers are saying about Micro Focus, Microsoft, Tricentis and others in Test Management Tools. Updated: May 2021.
502,335 professionals have used our research since 2012.