Code and Test Cases — are for humans
One can think, that the code is written for a computer, for a machine. But this is not true and is the one of the biggest mistakes that young programmers do.
Code is written not for a machine. Compiler/interpreter does that: it translates code to a machine language, to byte-code. It simplifies, optimizes, translates, etc. It will translate successfully both simple-and-clear and sophisticated code to a program that will work. But simple-and-clear code is easier for… human. That’s why simplicity and clarity is so crucial in programming, in writing the code.
Don’t be clever in your code, be clear.
This is important, because another people will read your code to understand and support it. Even if that another people will be… you! You in 1 month will be a bit another person, than you now. In 1 year you will be much more another person. And so forth.
The same situation with autotests! Automatic tests — are “small programs”. And these rules of simplicity and clarity are applied to them as well!
And the same situation with manual test cases!
If you deeply get into the nature of test cases, then you get that test cases are a knowledge base for your product or service.
Test cases — are a Knowledge Base for your product.
Specification is often not precise, out-of-date, i-think-it-should-be rather than it-works-this-way statement. Code is too difficult to understand, because you need to know the language, to get into the context of the part of the code, and usually still need to run that code to… to test, to double-check! That’s why tests (both auto- and manual-) — are good, well-rounded, easy-to-read knowledge base about your product or service.
And this is the way you should threat it! Test cases — are not a trash or scaffolding or a waste of time, but they are a Knowledge Base. They are a source to an answers on questions like “What will happen if …” And these answers have been obtained through the testing software itself. Real usage. Real execution. Because quality — is an execution level. And that’s what we check: if the app executes well (as expected) for the conditions we’ve set.
And that’s why Knowledge Base should be complete, simple, clear, useful, easy to manage, etc.
As to me, I deeply understand this. When I write code, test cases, build design for the system like SQA Mate test cases management tool, I think about simplicity and clearness, I think about those, who will use them. I want them to keep their brain cycles for their task, not for understanding of my staff.
P.S.: If you found this article useful, please, don’t hesitate to give it some claps! Thank you!
