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.
A little backstory first, a brilliant SaaS startup, we’ll call it FabulousApp. It opened it gates to end-users two years ago with its launch. Founders couldn’t be more excited as they watched people welcome and approve their idea with open arms. Founders were confident that this start-up will make their dreams come true from the very first day. At its core FabulousApp solved only 2-3 problems which was great for its quickly growing user base.
Ten signups weekly, turned to hundred and soon people started demanding more. It made perfect sense to founders who wanted to expand on their offering to grab bigger market share. But rarely do these things go as anticipated and founders learned this the hard way. What started as an application with 2-3 highly targeted features turned into big mammoth of 10-12 bulky difficult-to-use and unappreciated features. They saw rise in their customers while customer satisfaction dropped. They had added 4 more developers and 4 new QA professionals in past 6 months but nothing seemed to work. What really went wrong here?
In above case, what really went wrong here was: quality. But why did it happen?
Simply put, quality is a complicated thing to measure and manage. What works for a small project, won’t work for a medium-sized project and certainly not for very large project.
We are well aware of this problem, so we decided to survey some of our customers in past one year and came up with the successful patterns which you can use to scale your testing as your project grows more, or even if your team grows.
We’ve compiled the list of models for you to follow as per your project size. Doing so will only answer one single question, but a very important one nonetheless: how to structure your test cases. Because if you have a good structure, it’ll fit right in with the future project growth.
Let’s see these different models now:
1. Model #1 (For small projects – less than 5 API end points, 2-3 team members)
(Note that small and large are relative terms but we’ll do our best to clarify based on our users – it is still a generalization and may not apply to everyone.)
In this model, we simply keep test cases grouped feature-wise as that’s the shortest route. Small projects are also straight forward so you won’t run into any quality related challenges.
2. Model #2 (For medium projects – less than 50 API end points, less than 20 team members)
Once your app starts to grow more and more, you cannot stay on Model #1. Why not? Because you’ll end up with a lot of features on same level and not enough separation. That’s not a good structure for test delegation and measurement.
A good idea here would be to put a new classifier, ‘purpose’. A purpose refers to the purpose of the feature; what category that feature fits in. If we take Facebook for example, one purpose can be ‘Staying updated’, then there will be whole range of features like ‘Post an update’ or ‘View Photos’ that you can put under it. So this introduces a new degree of separation. This extra degree of separation also divide and assign responsibilities in your growing project.
Another purpose of Facebook can be ‘Connecting with new people’, and there, as you can guess features like ‘Add a friend’ or ‘Search’ would go.
It’s a good idea to not have more than 10 purposes at root level. More than that and again you’re looking at scaling issues with the process.
3. Model #3 (For large projects; 50 or more team members)
The best projects we’ve observed with large teams (more than 50 members) are ones where they are: a) either divided into small bunch of projects b) developed and tested as micro-services.
It’s quite unproductive to have so many contributors in one project. With such a large number not everyone would contribute when they should. So to manage a large project, we divide projects further into mini-projects with team members not more than 15-20 per project. Smaller the team, the better.
There are many innovative ideas we observed in our survey but documenting all of them isn’t possible. Besides the whole point of this survey was to locate what’s most popular and common among successful businesses so new businesses can learn.
Please comment and tell us about your unique model that you follow, or if you’re facing any challenged with your software testing currently.
