6

Background : Currently working in a firm which follows a practice where the QA's e2e and API automation suites are mandated to be reviewed before being pushed in a CI pipeline. It's a practice that is being followed across multiple projects within the firm.

Issue : I'm currently working in a project where I am the lone testing/QA member, along with 3 Front End (Angular/React) and 3 Back end developers (Ruby). The e2e suite uses Protractor, Cucumber with Typescript - loosely based on this framework given by Ram Pasala. The API suites use vanilla JavaScript and use Chakram as the framework.

In my monthly discussion with my QA manager, this point was raised that the code needs to be thoroughly reviewed before being pushed to the pipeline - however there is no one with required understanding of Protractor and Typescript or JavaScript in the overall QA team that the firm has - almost all of them work in Java or C#.

Now I'm left with this choice that any one of the Front end developers, who has enough expertise with TS/JS should review the code. I have never faced this situation before and I'm not sure if this is a good idea or a bad idea. I have generally seen that the QA team members generally review the code (within the team or someone QA from outside the team), but I also think it is not something which is a standard practice.

I would love to hear any thoughts/pros/cons regarding this idea. Is this a good/bad practice?

Improve this question

3 Answers 3

Reset to default
8

It's an okay idea with some guidelines. QA code is software. And software engineering principles should still apply. Since none of the developers know protractor, they should be trained. They may be able to add tests to their application on their own eventually.

As for who to code review, the frontend developers are probably a good choice. They might have good pointers and tips you can learn for writing Javascript code. It's always good to have a second set of eyes on your code. It keeps you from writing lazy code because someone will call it out. That thereby keeps your codebase cleaner. If they say something you disagree with, one of you is going to learn something. Either they will convince you their way is correct or you are going to teach them something about testing. As long as everyone is civil, it also builds relationships which is important between developers and QA.

Pretty much all the QA code review at my company. At least one approval is required to merge code, enforced by automated check on Jenkins. Optimally, to your point, code review should be done by someone who knows about the frameworks you use. You probably should suggest training for the developers doing the code review. Try to say that they should also be writing/contributing to the test suite because they are trained.

Improve this answer
1
  • Yes. You make a good point. I put forward the idea that the FE devs should have a training on Protractor. However, they are not very keen on it.
    – demouser123
    Commented Jun 19, 2018 at 6:27
3

Why do you view it as 'Developer' reviewing 'tester's code?

A team member is reviewing another team member's code is perfectly fine as long as vice-versa is also true and accepted equally.

Having said that, All code is code, where the standard best practices can be applied and reviewed irrespective of any specific framework (Protractor) knowledge.

I would not worry as long as I know I have been applying the basic good practices like keeping my code DRY, simple & readable with clear & consistent variable naming.

Rest all will be an learning experience.

Improve this answer
1

I don't agree with this.Test code should not be reviewed by development team as it may get biased. You can groom people from test org. to be proficient and there are enough materials and best practices available over internet to do that. Am little harsh hear due to the reason: Test and Dev. difference culture is not good for an organisation where it comes to coding or capability, they should be treated equally. So, empower testers and give them strict timelines so that things will fall into places.

Improve this answer
3
  • 3
    In what way a development team will get biased after reviewing testers code?
    – dzieciou
    Commented Jun 19, 2018 at 12:42
  • If you follow Behavioral driven in your coding, then code bias possible. If development team also used same tool for unit test e.g. protractor or spectron, they may get biased with way you handled your scenarios.
    – SANTI SANTOSH MAHAPATRA
    Commented Jun 19, 2018 at 18:13
  • 2
    If one is biased in a review, others can point out the errors in his comments. Productive discussion is healthy.
    – João Farias
    Commented Jun 20, 2018 at 0:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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