Category Archives for "Testing Tips"

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.

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.


Test Driven development for API-first apps with Postman & Newman

Test driven development as you may already know is a simple practice of having your dev workflow in such a manner that your tests determine the flow of development. In simple words, you’re writing tests first and then developing the actual code that passes those tests. Here are some benefits of this approach in case you’re wondering.

API-first involves developing your API first (preferably with a well-developed API framework) and any other UI or client later. There are immense benefits to this approach, since API endpoints are much easier to test. All you have to document is input and output in most cases while developing monoliths you know it’s not as simple.

Another benefit both of these strategies offers comes from separation of concerns principle, since you’re dealing with backend only – it eases up any future debugging and deployment.

If until now you’ve found yourself spending a lot of time on monoliths then you can understand how painful impractical it might be to use Test Driven development. However if you enter into API development, things change and wonderful things start to happen when you chose TDD.

With tools like Postman, it gets even easier to do so which we’ll explore shortly.

To Do

We’ll be combining Test Driven development principles with API-first strategy and focus on a workflow which would be much faster than traditional monolith-style development.

We’ll also look at implementing collaboration within team (scm), so everyone in a team can contribute.

About Postman & Newman

Postman is a simple tool which allows you to make HTTP requests with various parameters and save different set of collections which you can refer later or trigger again.

Newman is another tool from Postman developers which is a command line runner for API requests.

You’ll need to install both of these tools before moving forward.


Our workflow is broken down in following steps:

1. Creating requests (equivalent of writing test cases)
2. Automating these requests for cli (so they can be used in build servers)
3. File structure for requests we create (to enable collaboration)
4. Bonus: Documentation generation from test cases

#1 Creating some requests using Postman (Test definition)

Since we’re talking test driven development here, let’s first create a request (or test) in Postman along with our expected result. We don’t have any API yet but let’s do it anyway since we need to define behavior first.

We’ll first create a collection in Postman so that API can be shared with team later. In that collection, we’ll make some requests.

test driven development - step 1

You can repeat these steps to document multiple end-points all at once or one-by-one.

#2 Automating requests with Newman

Now that we have some requests we’d like to execute, let’s see how we can automate them with our development environment. Right click on collection menu and export the whole collection to JSON file.

Your API collection can be exported to a json file.

It’ll enable you to maintain your source code control workflow and collaboration.

Alternatively, you can also generate a shareable link to your collection which is what we’re going to use for speed. Go to share collection from the context menu, then Collection Link to do so.

Now let’s run this collection with following command:

newman run <your collection json file or url>


As we have no API running right now, there are 2 failures which are clearly shown.

Now let’s develop our sample API and run this again:

We’ll use simple node/express code here:

const express = require('express')

const app = express()


app.get('/say-hello', function (req, res) {

 res.send('Hello World!')



app.listen(8080, function () {

 console.log('Example app listening on port 3000!')


And run it with

node server.js

And run newman again:


Note that I’m using URL as my JSON collection – for a typical development environment this would be a file in your local filesystem.

#3 Committing your work

Now you have API code + JSON collection, both are standard files which can be committed to any repository. You can decide any standard directory structure that works for you. For my example, I’ll choose:

/api (actual application)

/tests (for my collection file)

The good thing about having your collection file in source control is that all of your team members know how to call a particular API endpoint.

#4 Bonus: API doc generation from test cases

Another benefit is automatic documentation generation – Postman does a great job here. Each collection you upload to Postman server automatically gets a documentation page like this:


Apart from that, each collection file can be fed into a monitoring agent when you deploy to production. These are available in Postman pro edition but you can do this yourself too.


Tools like Postman and Newman combine both GUI and command line interfaces so APIs can be developed easily. It also makes TDD easier along with team collaboration without leaving our standard source code control tools.


7 old tools teams need to dump in 2017 for better ones, to develop better

Today’s post is about migrations from old tools and technologies to new and better ones. One cannot ignore how quick our technology is progressing, one small change in workflow saves enormous amount of time which otherwise is overlooked. When I say technology I do not mean technology on conceptual level, but technology which empowers common users and teams like ours.

We often get comfortable with the set of tools we work with daily, even though we really need to be more transparent and more objective with such decisions. We at Test Collab are often guilty of the same thing. It’s crucial to get some external feedback to see things more objectively. So that’s why I’d like to share some tools you need to dump and why, along with their newer and better alternatives.

#1 CI System: Old self-hosted Jenkins to any new cloud hosted tools.

Out: Jenkins

In: Shippable


Jenkins is a mature project and while it was a great tool few years back, it no longer works with essential requirements teams need today. The absence of pipelines and branching as first class citizens, and stricter environment level provisioning – Jenkins no longer works for moving up the ladder of continuous deployment maturity.

Apart from getting old, other issue is cost. Computing costs have gone down and most of the cloud tools provide a lot of functionality and builds at free of cost – at a starter level. These new cloud tools are extremely scalable and provides great ROI.

Other alternatives:

Travis CI, Semaphore CI


#2 Version control: SVN to Git

Out: SVN

In: Git


In beginning, I was a bit skeptical about the gains it would offer compared to the cost it would require to migrate. So I set out to do some experimentation and was pleasantly surprised by source code push/pull speeds and merging. Git uses compressed network transfer mode which made pulling out 2500 or so files in seconds as opposed to minutes in Subversion.

Although SVN is still an active project but I doubt they’ll push something as innovative as Git – so this seems like a good move.




#3 Project management: JIRA to any Kanban tool


In: Trello


While JIRA and similar tools make good issue managers to dump all your bugs in, they make a terrible project management tool. Really, think about it, what project really is? First there’s your product and any iteration you do on it is a project. Now in order to be kickass with your iterations you need to see where everything is, along with their respective statuses and if something is being worked upon for too long to quickly identify issues. JIRA and such tools don’t offer that (at least they weren’t created for this purpose)

With new Kanban board tools, you get to see full picture every time you open them instead of dead index of issues. I don’t know about others but I’m urged to push forward when I see the bigger picture.


Kanban Tool


#4 Test Management: Spreadsheets to Test Collab

Out: Spreadsheets

In: Test Collab


Okay, we maybe a little biased here but hey, we gotta pay our bills too. Spreadsheets doesn’t work well for test management tasks. Spreadsheets don’t delegate… Test Collab does. Spreadsheets doesn’t integrate with your issue managers, Test Collab does. Spreadsheets doesn’t track testing time and quality metrics, Test Collab does. So I guess that’s enough reason to at least try us. huh?


HP Test Manager


#5 Development environment: Desktop to C9

Out: Desktop

In: C9


Why code on your laptop when you can code in browser on remote workspace? Wait did I say workspace? Try tens or hundreds of workspaces. With tools like C9 you can launch as many workspaces as you want with clean OS and nothing else. Finally, you can focus plainly on all things creative instead of resolving dependency hell and desktop issues.

You can experiment more on OS level and quickly install / uninstall so many packages. Desktop lovers might be thinking, so what? We’ve got VM’s and now Docker, what’s the big deal? Yes it is a big deal – I can open 10 parallel workspaces and play with them without watching my laptop hard-drive go crazy. And another lovable fact: your packages download super-fast without hurting your bandwidth.


Code Anywhere


#6 Webhooks: Custom coded to Zapier

Out: Your hacky custom coded stuff

In: Zapier


There’s no reason to code several connectors among different web services anymore (well in at least 90% of the cases now). Because any service you can possibly imagine will most likely be found at Zapier and you can make your own integrations very easily. It has never been this easier to connect 2 or more services together and make data flow through them – it just works wonderfully.



#7 Hosted servers to Server-less computing

Out: Hosted servers

In: AWS Lambda


I haven’t seen a similar company as Amazon. These guys are so disruptive that they disrupt their own products – Lambda is such a product. AWS Lambda removes the need of always-on servers altogether instead your code runs in the cloud and you just manipulate the result. Migrating an existing API to AWS Lambda has steep learning curve and also requires some kind of shift in team’s mentality but it’s totally worth it. You can cut down your costs as much as 50-60% in some cases.


Google Cloud Functions

How to organize your test cases – lessons learned from some of our most successful customers

A small project can sometimes grow really fast in today’s marketplace. It can really be an unpleasant experience (instead of a positive one) to some teams who are less experienced or launched a start-up for first time. It helps to prepare upfront and this article is all about that: To equip you with the knowledge upfront which you can use now and in future.

Continue reading


9 things I wish I knew about CI/CD pipelines during first year of my start-up

We’ve been installing some upgrades to our release pipeline here at Test Collab. Such upgrades give you a good opportunity to find your past mistakes and eliminate them altogether. While doing so, I thought it’ll be good to share what I learned about continuous integration during lifetime of Test Collab and before.

Continuous Integration is a key element of your software. If not planned carefully and correctly, you’ll most likely have higher risk exposure to bad releases and bugs, resulting more costs on your business. Continue reading


The biggest lie by test automation tools vendors: Record & forget

While working with some of my clients, I realized how easy it is to push a test automation tool in organization. Managers are suckers for productivity tools, including myself. If you can prove to me that $x improves my team’s productivity by y%, there you go, you sold me. No questions asked! Right? Test automation tools fall under same category, easy to showcase and sell, but hard to implement.

Why hard to implement? And what you really need to know before you acquire a new tool or planning your test automation strategy?

Continue reading


Using Docker to manage and replicate test environments

About 5 years back I started this business, Test Collab, ever since then I was fortunate enough to work with so many developers, managers and testers. From micro-ISVs to Fortune 500 companies, I just loved how different people can give you so many diverse ideas.

So today I’m going to talk about an idea, or let’s call it a solution, if you will.


The problem

When you are manually testing an app, you have to deploy it again and again. To save time, some teams use shared testing environments, i.e. one app instance is used across whole team for testing (Not good – as it increases false bug reports).
Continue reading

1 2 3