I have been doing this a lot, reading application code base. Ours is in Python, so its lot readable. And it helps and support my testing. I am not a very technical person, still it helps.
I noted down some of the benefits that I experienced below in bullet points.
If you have anything else that you enjoyed. please let me know by your comments.
I wanted to ideally put all these in to a blog post.
this helps to be sure of that, the code has been pushed in to the right feature/sprint branch that I am suppose to deploy to my test env.
It helps while you form the test strategy of your code /release cycle -by knowing what all files have changed
it speed up the validation checks - by seeing all those if/else statements dev might have put
it helps to shift your testing to the left - by giving early feedbacks
it helps to improve the Test automatability - by asking dev to add easy locators techniques etc if it missing
I would like to add:
I don’t usual look at the code that often but I do like to view the unit tests also. When I create API tests I don’t want to have duplicated tests. Also seeing the mutation coverage on the unit tests is nice
Well, most apps are built using at least 3 languages from a bag of Vue/Java/React/C++/C#/Swift/Go!/Fortran/Django/Ocaml/PHP/Delphi/COBOL/F#/Haskell/Kotlin/Smalltalk/Modula2/VB/Pascal/list/NASM and so many rather languages. Often not in common with your test framework language.
But I’m biased, I was once a coder. But although I don’t profess to be able to write any Java , read Vue templates and understanding trans-piling from C++, BUT!!! usually you can tell if a code change, does what the bugfix ticket said it did. Read enough code reviews and you will soon “pattern” learn just enough of any code language to be able to know if the code change in version control at least was approximately the problem what the ticket says. So often this is a communication and keeping people honest job. It’s sometimes even OK to put a tick next to a code-review even if you don’t know that the code is good to ship, so long as it possibly compiles , or you can somehow run it locally. If you cannot compile the code, then you can ask the devs for help to set you up so that you can either build the code, or “deploy” the code automagically, as a way of being able to kick the tyres.
I’m not saying testers should be able to fix code, or even really read it properly. But they should at least show interest, it is after all the actual thing that is shipping. Imagine working as a QA at a hammer factory, and having no clue at all how the hammer heads getting added to the handles on the conveyor belt got moulded?
I do this as well, looking at the code can help, especially if you are dealing with legacy systems and the documentation is either outdated or non-existent. Reading the code helped me a lot - it is like a living form of documentation and in my particular case there a lot of comments in the code which was handy at times to get a feel of the context - why something changed for example. The only issue I face with comments in the code is at times when code would get updated but the commend remained the same, in those situations you just to got follow to flow of the code to figure out what it’s doing.
Reading code for me is key to my bug reporting. My aim is always to provide as direct analysis as I can to reduce required developer time. I’ve managed to greatly improved bug fix speed by giving developers a better understanding of the causes as well as the symptoms of a bug. Doesn’t mean that my analysis it always correct, but it defiantly helps the developers focus in on the issues.
