How to save time on deploys and increase your team efficiency with transparency
Every time when somebody talks about any kind of documentation, we usually feel frustrated. Mostly because there seems to be always a lack of time for it. What if we say that there is a very simple document that makes deployment and preparation for it much easier and faster?
We are talking about the Product Functionality Map
What benefits you’ll get from it?
- I t will help you create clear checklists for your QAs or devs that working on a certain feature
- It will make your product more transparent to each team member
- It will save time on deploy preparation and after-deploy process by linking and prioritizing product features for testing.
- It will help with onboarding new team members who need to know about product features.
How does it work?
In most cases, before the deploy or release, it’s not so crucial to test every single user path through an app. Instead, it may be better to focus on the feature/fix that should be deployed + features that are essential for the product.
In a template file, that we have attached, you can find 4 columns:
- Primary functionality. The basic features of your app should be listed here. To define them, just simply go through the most important user paths in your product. These will be the group names that all other tests are organized under.
- Secondary. This column should identify the basic functionalities for each of the features in the first column. For example, if in the first column you have a login path, then here you will need to list: provide email and provide the password.
- Tertiary. A list that will include additional functionalities beyond the basic ones.
- Negatives. This column will include low-priority edge cases that should only be included in your regression suite if you’ve already covered everything in the Tertiary column.
And here is a cherry on top! All functionality described in the Secondary column becomes your smoke test suite. This test should be performed every time there is a new software build or fix intended to be released. And, at the same time, all the functionality described in the Secondary + Tertiary column becomes your Regression test suite. You want to do it when your product undergoes significant functional and non-functional changes.
We hope you found this information useful! In further publications, we will introduce more recommendations on how to make processes in your team smoother.