Why code review is a underrated skill in testing

What is code review?
It's both looking over the code personally, and letting the linter - with rules decided as a team - inspect the code.

Code review is the last step after the development is 'ready for testing'. It's the first step of post development testing - you've scoped out the work, analysed the requirements, had a session with the developer and designer to discuss. This is the last chance to catch bugs without intense 'traditional testing', as it were.

It's a place to catch issues you would take a longer time to find when testing with other methods- security flaws, small but important business rule mis-interpretations, commented out code, code that could be tested with integration and unit tests that aren't - and issues you can't find when testing with other methods that can lead to product quality issues down the line, like hard to understand code, and unclear names.

It helps you learn how to code - that is useful for the inevitable programming you'll end up doing - whether it is fixing minor bugs, creating testing tools, or test automation.

It prepares you for defect replications later - you understand the code, and therefore the scenarios that the bugs are referring to. This enables more confidence when regression testing. If tickets are ever lacking the required details, or they assume knowledge you don't yet have, you can reverse engineer the intent, and then talk to the engineers when they are available to join up the dots.

It helps you refine your questioning skills - which is ultimately what we are doing as testers. Making observations and asking questions.