I’d highly recommend it! You don’t even have to comment initially. Reading to start off with will teach you plenty about how the devs are doing what they’re doing.
2 Likes
You might take a while to work out the best way for you. Depending on how things are set up with you, there might be a variety of tools you can use, particularly if Git’s involved. Then there’s choice as to the order in which you tackle things:
- What’s the thing that will help you understand most quickly - the code changes, the test changes or the data model / API changes? By functional area?
- Is it most helpful for you to go top-down or bottom-up?
Then the author of the changes can make your life more or less easy. For instance, if it’s a fairly big change there could be multiple commits against one pull request, where the commits divide things up into helpful chunks.
I say all this not to get anyone stressed about reviews. It’s more that if you find a code review hard work or frustrating, there might be alternative approaches you could try that you would find better.
3 Likes
Here is my contribution for this month:
2 Likes
Not sure if I’m missing something when reading your blog post.
What is the underrated skill in testing?
1 Like
According to me, research is an underrated skill in testing. Before I test, I tend to look for additional information outside the user stories and requirements. This way I discovered new situations for testing.
Research is something I do unconciously. And somehow I do not use this term often.
3 Likes
THat’s very useful. Without it, you can easily find yourself wasting time testing using the wrong thing as an oracle because it’s outdated etc.
2 Likes
I wrote a blogpost about this topic on my blog.
4 Likes
I agree, and one of the factors that hinders refactoring of test code is the lack of tests for the test code! Refactoring production code is helped by the existence of automated unit tests (and other automated checks) that help you spot when the refactoring has accidentally changed behaviour.
However, we don’t usually have that safety net for automated tests, otherwise it would turn into a turtles all the way down / Quis custodiet ipsos custodes? problem. (If the automated tests have tests to help with refactoring, how do you refactor the tests that test the automated tests etc.)
The production code acts as a loose guide - if you refactor an automated test and it suddenly goes from failing to passing (or vice versa) with no change to the production code, then that’s a clue you’ve broken it. But, particularly if they haven’t gone through mutation testing, the automated tests might have started far from the boundary between valid and invalid, so there’s a bigger risk that a bad change to the test won’t show up in the test’s outcome.
2 Likes
It’s kinda crazy how much repetitive code and lack of comments I’ve seen in test code.
Knowing that you should refactor and how to, is def useful knowledge 
2 Likes
Reporting automation run on the pipeline is an underrated skill in testing.
Because it feels as if you’re valuable and doing teamwork and showing the team that your code is checking everything is correct or not.
I published an article on how we handle automated acceptance tests in our team at Dolap -the second-hand online marketplace-
2 Likes
A bit late to the party, but I got there eventually.
It’s a skill that is well worth improving. You can be the person that helps move things in the right direction.
6 Likes
Great post.
It reminds me that I heard somewhere that testers are like glue eh
3 Likes
Glad you enjoyed it. Very thought provoking topic.
2 Likes