Test effort estimation ability is a standard for middle QA and above. But I realized that I was not producing these estimations for some time, and both the testing process and team were not affected. On the contrary, when the test effort estimation task arises, it looks more like test process degradation.

One not so fine day I've heard an opinion: "Testing is primitive: if you know equivalence classes and boundary values analysis, it's enough". It's not so important, it was said seriously or as a trolling. The question looks offensive and actual - I usually don't use complex test design techniques and software testing is advertised as a quick and simple way to get into IT. The opinion looks true, but is it enough? Or additional considerations can be added?

The product growth may result in the necessity for changing of core components working for a long time. And usual approaches are no longer usable. The requirement "it should work as it was before" can't easily turn to a test plan. We have to use new approaches, and the ironical phrase "code is requirements" suddenly turns into a working solution

On my first workday as QA, it was told to me: "We are working on Scrum, here is a book, read it". Since then, in different companies, I have observed Agile implementation with various levels of success. Despite the different conditions, these attempts had common features that can be systematised. And the unavoidable question "What shall we do?" can be answered by 75-year old experience and one word that is misunderstood frequently.

The experience of other industries is not entirely different from IT QA. Memorable stories from space exploration history are aimed to be an example and inspiration for software testers in their routine work.