Should QA Engineer read and review code of Web application?

Question

I'm creating a test scenario for new project and I'm wondering if it is a good idea to write Test Cases such as "Access to xxxxxxx/xxxxxx-xxxxxx and verify CSS & HTML properties" has even sense. Approach would be that the tester should open the documentation and compare whether all properties of the elements have properly values or not. Also the tester should verify if elements such as textbox are "number", "tel" etc. indeed.

I'm not a web developer but I understand a structure of HTML & CSS code so - in theory - I'm able do it. Question: Is it a good/widely-known practice or not?

Answer 1

It depends

If the coding standards of the organization require that each element has a clear name and limits the data to be entered, and the test team is typically part of code reviews, then by all means include these checks with your test cases.

If the organization doesn't require controls like this, it's probably better for your interaction with the development team not to review their code. I've encountered developers who dislike testers examining their code for any reason.

That said, there are frameworks that will auto-generate the HTML and CSS: many of these will also generate the properties and attributes you're considering, in which case you won't get the results you're expecting from a code review.

Answer 2

No, test-cases are about behaviour not implementation. The implementation could change, but most often the behaviour would stay the same.

Coupling test cases to implementation would mean you need to change the test-cases every-time you refactor the code. This is an anti-pattern. So don't specifically use test-cases to check how the application was implemented.

To your second question should QA have a look at the code. Sure, but beware that you do not add an extra level code reviews, certainly not reviews that have already been executed. Just like test coverage, try to cover each path with just enough effort.

Sounds OK to execute a bit of code-reviews during exploratory testing sessions though. Just to make sure it is not one big untestable mess. :) Maybe you are confusing test-cases with a test-process. In the quality process code-reviews are a must most of the times.

Answer 3

I am a former developer, now in QA automation and occasional manual tester in the time of crunch.

So what follows is not a rule, but anecdote.

On few rare occasions, reading the code allowed me to see the mistake in implementation which sneaked even code review. I admit I knew that the developer was one of the weakest we have (making change suspicious) and the way test case was described lacked the clarity - but I was able to discern the error.

But: this is less than 1% of the cases, outlier, not a strong rule. In 99%+ cases, reading the code will be over the QA person head and waste of time. It might make sense, but needs to be carefully evaluated. Use at your own discretion, YMMV.

Answer 4

On the team I currently work on, we're agile-ish, and I participate in code reviews. Definitely not 100% of the time, but I definitely catch bugs and implementation issues (as well as code quality issues) in the review process.

In the case you describe though, where it sounds like you have test cases written that are meant to almost be instruction like for someone else, then it sounds a little heavy.

It sounds like if there's a type discrepancy or what not in a form, that would come out during functional/manual testing (and likely be noted more quickly there than someone struggling to read code when it's not their forté), or if you've got any automation, the automation folks would notice bad IDs or what not while automating.