That's a fair criticism. This approach might seem informal. But compare it to the agile iterative and incremental approach. There is iteration to improve the quality and incrementalism to adapt to changes. Same thing. You are testing the various functions of the application each time you get a new cut of the code, and you are breaking your tests into small increments, where one increment equals one test. Once a test is complete, you can pass it or enter a defect for it and then, with what you now know, decide what to test next. In agile that's called a retrospective. At the end of each and every test, you're looking back at what you've learned about this release of the code and then designing your next test right then.
I've seen testers on teams I've been coaching try to execute a full suite of detailed predesigned tests in an agile lifecycle and it generally doesn't work. It just causes frustration for everyone, especially the testers. It really isn't possible in agile to preplan and predesign all your tests. ET is, as far as I can tell, your only option.
Now let's take a step back and look at what is really different about ET. We are putting control of what is tested and how it is tested into the hands of the tester. The command-and-control structure is broken in favor of autonomous, largely self-directed testers.
What About Junior Testers?
It is pretty easy to see this working well with a stable of very experienced testers, but what about with junior team members? Won't they make all the wrong choices in deciding what and how to test?
Not necessarily. Agile has a fairly well-known practice called pair programming. But there is a lesser-known practice called pair testing. Two testers, perhaps one junior and one senior, can work together designing and executing tests. It can be very productive and pretty fun.
Also fairly common with agile testing is the idea of apprenticeship. A person who is new to testing, or maybe just new to agile testing, is matched with someone who is more experienced and can help them, answer questions and give advice.
Automated Testing and Agile
One more topic to tackle is automated testing. ET requires taking a new approach to automated testing. In a waterfall lifecycle, it is possible (and desirable) to construct end-to-end tests that execute an entire test scenario. In agile, this is neither desirable nor helpful. Think instead of a series of smaller test scripts that automate easily repeatable portions of the test scenarios. Maybe a quick automated script that fill in an entire input form with data. Essentially, the tester moves around the screens or pages and then presses a hot key when they need some brute force data entry or repetitive operation. Again, we are putting control of the testing into the hands of the tester instead of the automated script. It becomes less of a well-oiled machine and more of a human exploration of the software.
Agile testing is neither as crazy as some people think nor as intuitively easy as other proclaim. But it is possible and can be very productive and enjoyable, given the chance.