2

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?

4

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.

  • The last sentence in your answer is a key - there are many ways to achieve the goal, the effect so code reviewing as a test case is not a good idea. – mathsicist Oct 19 '17 at 18:10
  • 2
    I'm very fortunate to be at a place where developers and implementation engineers (i.e. all code committers) are more than happy to receive feedback on their code. It sometimes spurs debate, but always in a positive way. QA has never been involved with the code reviews, but I have no doubt that if they were the result would be the same. But it all boils down to the culture of the team - if the team can receive feedback and spin it in a positive light, you're golden. If not, well you might have bigger problems than just code reviews... – corsiKa Oct 19 '17 at 19:45
5

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.

2

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.

2

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.

  • Can you tell more about your participation in code review? What's your programming skills and what was the project (web, mobile, desktop app)? I thought that testers do not take a part in code review; at least in code walkthrough – mathsicist Oct 19 '17 at 18:05
  • I always answer the skill question by saying "I'm a tester who can code." I'm weak at algorithms and don't have a formal CS background, but I've built out our test framework, dashboards from scratch (full stack, with redis for the backend, PHP for the frontend) for test results, etc. The current company I work for writes RESTful web APIs We're agile-ish/shifting left. We try to have as much review/quality stuff up front as possible, hence my participation in pull requests/reviews. We still fall into the agile-fall trap, where I end up doing lots of testing at the end though. – ernie Oct 19 '17 at 18:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.