Review – is it something in the programmer?
About the problem
At tester interviews, I usually ask if the team does reviews. And I often hear different variations of “no” in response: the developers do, but I didn’t delve into it; we do not need, we communicate a lot; no one knows python, and the tests are written in it. So, is review really only for developers?
Let’s start with manual testing. I hope I won’t surprise anyone with the fact that the review is not only about the code. Everyone has long heard about shift left, analytics and prototype reviews, test case reviews. We heard, of course, but didn’t implement it, because a) we don’t need it, we have good specialists, or b) we don’t have time (yeah, everything is busy with useful meetings, I understand).
I sincerely believe that both points are rationalizing the same fear. We are afraid to show our work to others. It is scary to discover gaps in knowledge and lose in comparison. Did you recognize yourself? Then culture review is for you.
About culture
Still remember that you can’t write “your code
Practice for seals not touchy colleagues. Learn to give such an OS, for which queues will line up like a new iPhone. After your feedback, it should become clear to a person what exactly was done wrong, how it can be corrected, and how wonderful his life will be if he does this. And seriously, it’s time to learn how to give OS directly to a person. And accept such an OS too.
For me, the ideal review contains justified criticism, proofs, new knowledge or a reasoned view from the other side. From the review with the comment “no comments :)”, I feel sad and ask you to look again.
Code review
When talking about reviews of autotests, the argument often expressed is “tests are not real code, why waste time reviewing them.” Guys, everything you use in development is real. Even if it’s a script written on a napkin during lunch. And all this deserves respectful consideration, in the process of review, of course.
What tests to review? Everything that is within reach. Can you see the developer tests? Please send them to you for review. Poor understanding of the project language? Look at least for scenario coverage (and learn the language). Are you embarrassed to review the tests of a more experienced colleague? Do it once, find 5 mistakes, and throw your colleague off the pedestal that you yourself built.
I remember a good example. I once held a master class on reviewing developer tests among testers who were not confident in their knowledge of the code. In 3 hours of work, inexperienced automators dismantled one test class and found three problems: insufficient coverage in one place, excessive coverage in another, a complete mismatch between the requirements specification and implementation. 3 hours is a lot or a little? A lot for daily work, normal for the learning process. I do not urge you to spend all your time on reviews, I suggest you try it and see the benefits.
And finally, during the review, you can benefit not only the other, but also yourself. Watch how others write code, ask about obscure constructs, view reviews as a mutually beneficial process, and not a manifestation of distrust.
Instead of an afterword
If someone is still not imbued, I will give examples of the problems that I find on the review:
the developer copied and pasted the test cases and did not delete the excess, identical cases remained
the analyst described in the TOR only a positive scenario, no “if-then”
the tester wrote selenium tests where screenshots were needed
the analyst introduced the variables Т3 and ТЗ (can you find the difference?)
the tester made the private method public, although he could do without it (this tester was
Albert EinsteinI)the developer did not write tests for changes in the API (there was a dialogue “why didn’t you write?” – “I don’t have an answer to this question, I’ll go and write”).
Do you want the same fun? Go ahead and review!
