How To Reuse Test Cases Across Multiple Projects to Save Time and Money

We all know the feeling of how frustrating it is to write a new test case for every application we want to test. It’s not just a waste of time, but also a waste of effort! Imagine a world where you can test your application without having to start from scratch. Introducing: TestCollab’s, Reusable suites, where you can write and reuse your test cases over and over again across multiple projects.

What are the advantages of reusing test cases?


Faster development cycle – There are less test cases to be written, which means you’ll save a lot of time and energy. You do not have to spend time rewriting the same test case over and over again, which leads to a quicker development cycle.

Save Money– If a feature changes, you only have to update one test case instead of updating several test cases across numerous projects. This results in a lower maintenance cost.

Effective – Test cases are written for specific features rather than the whole project, giving extra attention to each feature and resulting in more robust tests.


How to reuse test cases across multiple projects?


That’s what we’re here for 🙂 A new TestCollab feature: Reusable suites that lets you use test cases among multiple projects.

Lets say you have a test suite called “Billing” in Project A. Now, your team started a new project called Project B, which also need the same “Billing” test cases.


You can see how reusable suites feature works in this video-




Signup Now to try Reusable suites feature now.

Please feel free to email us on if you have any questions.

Test Case management is now affordable!


Most small teams lack the infrastructure and resources to do testing effectively – and they lack the knowledge and ability to select the right tools for the job. In order to solve this problem, we have introduced our Basic plan.

An excellent option for companies switching from Excel to test management software is the basic plan. You can have unlimited test cases and test runs. No more messy spreadsheets!

Plan starts at $17 per user.

Basic plan includes all free plan features plus:

  • Unlimited Test Cases
  • Unlimited Test Runs
  • Unlimited Activity Log
  • Export CSV
  • Priority chat support

The all-new TestCollab is here! 🚀

Our team worked on almost 2 years to create a whole new TestCollab based on feedback we received over the past 10 years.


What’s new in TestCollab 2?

– Brand New interface with focus on awesome UX

– Bulk actions for test cases and plans

– Better ability to filter including custom field filters, and saved filters

– In app notifications for work that is relevant

– Comments with @mention so you can mention team mate and they are notified. Also, comments can now be added to Test cases too.

– Keep tabs on work across multiple projects using ‘My tasks’ page

– Improved Jira Integration with ability to link existing bugs

– Ability for testers to update test case while running it.

– Test Runs to create a new run cycle for same Test Plan

– Configurations feature to generate multiple Test Plans

-You can also export results for a Test Plan for all configurations, so you can see that “test case A” Passed in windows and ubuntu but failed on Mac.

– You can now filter your test cases as well as test results and export in CSV. For example, find failed test cases from a Test Plan and export them or find test cases tagged as “need-update” and export them.

– Global custom fields can be added to all projects and you can also display custom fields in test case table.

– Our new import process is very intuitive, you can import test cases in one suite, or even create new suite from CSV or you can import test cases in multiple suites at once. We also have more advanced mapping in import too.

– Detailed activity log

– We have added new reports based on feedback from customers, like user workload, activity report, run comparison report, burn down for Test Plan. Excel export is great for creating custom reports too.

– A defect tab is added to project so you can see all bugs posted from Jira to Test Collab at one page rather than going to each Test Plan.

– Test Plan folders are also introduced so you can also group your test plans together.

and a lot more…


Signup now to try it out!

DevOps through the vision of a QA

The popular term DevOps is presented as a union of “departments” that has been promoting a set of processes and methods which lead to new thinking about communication and collaboration between them.

The main feature of the DevOps is to strongly advocate automation and monitoring in all stages of software development, integration, testing, release and management of infrastructure. DevOps aims to provide, shorter development cycles, increased deployment frequency, more secure releases, in close alignment with business objectives

DevOps will have one hand in the infrastructure and the other in development and, in some cases, they may also have a hand in the area of quality assurance (QA). It’s more of combining infra, dev, and quality.

In short, a DevOps must act as an agent of change, integrating development and operations. For that, it is necessary to invest in knowledge and constant updating.


Let’s discuss more about DevOps:

It’s more about shared responsibilities and about building the stuff together. So to be a DevOps enabled team, there should be a cultural shift which enables the whole team to work together as a single entity. In fact, the whole team should be involved. In one of my previous organizations, we QA’s do the Production Deployments. It was QA’s responsibility to release the product to production. After that, we monitored logs from Kibana, Sentry, Datadog, etc to see whether there are any new errors/previous errors are resolved or not in the latest release.

DevOps is about the way of working together, communication, collaboration & cooperation  across multidisciplinary teams.


How you define DevOps in Organization


Moving to DevOps is a change process and you need to handle the change management. I would like to share the questions/thoughts my last CTO shared when we decided to shift to DevOps: “What are we going to do?” “Why should we do it that way?” “What benefits will we get out of it?”. Without proper understanding of these it will remain as a blindspot for the team members.

It is easier to introduce DevOps when that introduction is divided into smaller parts, alternating between cultural changes and technical changes. Instead of a big change, there will be a small cultural change, followed by a small technical change, followed by another cultural change, and so on. That way, teams will never feel that everything has suddenly changed. Instead, they will feel that changes have occurred more at a natural pace.


Integrating Teams


The key is collaboration between these teams which has four main axes: Culture, Automation, Evaluation and Sharing.

Culture: collaboration / end of divisions / healthy relationship / behavior change;

Automation: deployment / control / monitoring / configuration management;

Evaluation: metrics / measurements / performance / logs;

Sharing: feedback / good communication.

This improvement in the relationship and collaboration increases efficiency and reduces the production risks associated with frequent changes.

In short, DevOps must act as an agent of change, integrating development and operations. For that, it is necessary to invest in knowledge and constant updating.


Role of QA in DevOps enabled Team:


Continuous Testing is the key point in a DevOps enabled Team. QA should be aware of what tests to be executed after each feature changes. After the code commits, the automated tests should be executed in the CI pipeline and there should be proper metrics to track the results. Here, we should have proper monitoring to detect errors during early stages which results in lesser damage.

QA should be working closer with the Dev & Ops team to set up an automated build and deploy processes. These are the people in charge of creating a test environment for automated executions which plays a vital role in integrating automated tests with Dev cycle in continuous integration.

In the CI phase, automation adds value by building the automation framework and automated scripts for features.. And obviously, the missed parts by automation will be covered by manual smoke/ad-hoc tests on the particular build/commit. Here, there shouldn’t be a discretion between manual and automated testing, both play key roles.

The principle of continuous testing refers to better collaboration of QA with Devs & Ops throughout the DevOps lifecycle. Along with that, it’s our responsibility (QA) to verify that the correct coverage is achieved based on the risk profile or other model-based strategies.

Gitlab Test Management now available!

I am happy to announce that we have launched Gitlab integration with Test Collab. Now, all your failed test cases can be reported to Gitlab in a single click to your Gitlab as bugs so that you can focus your efforts on quality assurance rather than switching between different softwares.

Once you have setup Gitlab integration you can also get requirements from Gitlab linked with test cases in Test Collab so that you can have a better traceability and coverage analysis.

You can do following with Gitlab integration-


– Link Gitlab requirements or user stories to your test cases

– Create Test Executions on basis of Gitlab requirements or user stories

– Automatically push failed test cases to Gitlab as bugs

– Automatically close Gitlab bugs once the failed test case is passed.

– Generate Test Coverage report for Gitlab user stories or requirements


I hope you will find it useful. Try it out yourself with our free trial-


Test Collab outage 8 January 2020, Issue rectified

We just recovered our hosted application from an outage. As some of you might have noticed, there was a lag between ‘creating a test case’ and that test case showing up on test case manage page. This was due to unexpected replication lag between database slave server and master server. The issued was identified and rectified within 2 hours of first report of incident from client. We apologize for any inconvenience.

Should you get your testers certified?

Testers certifications has been a thing of debate. There are some points to be considered to settle this:

  • Why you need this?
  • Will this prove to be a paradigm shift for your organization?
  • Are the testers in your team ready for this? 
  • Is it going to be a costly affair and is it really worth investing time and money?

Are these the concerns eating out your mind? Then read on as we analyze the need by answering a few simple questions…

Continue reading


Using source code visualizations as a coverage map for testing

I’m not a big fan of tracing or linking dead text requirements documents back to test cases unless it is absolutely required. This got me thinking what else can be used as a reference map for testing….?

We all could use some sort of map while testing exploratory’ily(?) So doing some searches I randomly stumbled across this post by Fred Beringer and it struck me that source code visualization can really be useful in exploratory testing. The main problem while exploratory testing is that we could miss critical areas of application. But what if we have such a map?

Continue reading

When to stop testing or stop documenting?

As product managers, every now and then we have to make decision whether to continue testing that feature or move on? It doesn’t just apply to testing efforts, but also to test case coverage & documentation, i.e. to continue writing more test cases for a particular feature or move on to next?

How do you decide in such cases?

Maybe we can borrow a concept or two from behavioural psychology: maximizing and satisficing.

Maximizing is when you’re trying to do as much as possible within given means.
Strictly in psychology terms, Maximization is a style of decision-making characterized by seeking the best option through an exhaustive search through alternatives.

Satisfising is when you’re trying to do just good enough to be satisfied (MVP for ideas and decisions).
In psychology terms, Satisfising is a style of decision-making which would mean exploring through options until you find one just enough or acceptable enough.

So which one to use when?

Look how often your customer spend time on this feature. If it’s, say 80% – 90%, it’s certainly calls for maximizer behavior – and you want to put everything you have in your arsenal at this, in terms of testing and documenting.

If the feature is occasionally used, you can get away with satisfising. You just need to do enough so that you know it works as desired – nothing more!

Obviously this principle can be applied on all types of optimization problems: at work and at life in general.


1 2 3 7