I also advocate this concept now: “use fewer and fewer step-based tests in favor of gherkin”. I even wrote an article where I explain “full sentence titles” for test cases — and they are pretty much look like a “single-line gherkin”. For example: “Application continues to work fine when there’s no more space for logs left in /var/log” or “Application doesn’t start when there’s no free space in /var/log”. Simple. Clear. Details could be written in test case description if required (for example, commands on application start/stop and health status diagnostics) both with plain text or link to wiki/Jira/etc.

Telling “Knowledge Base” I meant this set of “full sentences” that easily read in a tree structure of suites (folders) and which describe your product from different sides, different conditions (both functional and non-functional). You see coverage, you see opportunities to add more tests, because you get more ideas looking on that “full sentence titles”.

If you don’t transfer these test cases to regression teams or automation teams who might be in another offices in another countries, then you don’t need to describe steps and bodies much or even at all. But if you transfer, then you kinda “cement” that functionality, saying that it will not be changed soon. That’s why, when functionality stopped changing so much or so often — this concept of documenting software with “knowledge-base style tests” looks pretty nice.

Another thing that helps with test cases administration — is application decomposition, microservice architecture. This helps to change and test not so many test cases when the time comes.

Hope you found the answers on your questions!

Thank you!

I write about practical and effective techniques that help me and my colleagues in everyday software development and testing.