There has been a good discussion here of the next level. Here are some things I’m thinking of…
Understanding the strengths and weaknesses of the different types of testing. For instance, unit vs integration. Using the masonry example, unit testing would involve x-raying the bricks to make sure they don’t have defects and testing the mortar for the correct consistency. But I could still build a structure that fails by placing bricks at odd angles, have it lean outwards, not using mortar, etc. Integration testing would ensure the structure is put together properly.
And after you master the basics of functional testing, you could go deeper into that area (what happens if I use duplicate keys, try to corrupt data, destroy referential integrity, etc.), but testers may decide to branch out into load, performance, stress testing. Or usability testing, accessibility, compatibility, interoperabillity testing, etc.
Then there are techniques like pairwise testing. You may have developed your own techniques. I have a technique that I call “escort testing.” This is where I try to save data as soon as possible, without filling in the required fields. The app “escorts” me around to the missing fields and requires that I enter valid values before allowing me to save it - or at least it should. This has revealed many bugs. Warning: You may get some strange looks or laughs when you mention “escort testing” as in the U.S., the term “escort service” is a nice way to say “prostitute.”
What I’ve found is that you will find yourself moving upstream to make improvements (or ask them to be made) in development and requirements to make testing easier or more thorough. Does your development team calculate cyclomatic complexity or some other measures to prevent their code from becoming spaghetti (untestable, unreadable and/or unmaintainable)? How good are the requirements given to you? How complete? Do they cover what should happen in every different condition? Are the unambiguous?