We have 1 frontend developer and 2 backend developers and 1 QA. QA is responsible for writing the end-to-end tests using Cypress. FE developer writes the unit tests. Backend developers write the unit tests in the backend repo while QA writes the microservice integration and e2e tests.

I'd like for QA and developers to be able to work in sync such that when the pull request is created by the developer, it gets reviewed but should be merged only when the integration and e2e tests are ready by the QA that should be worked on in the same feature branch.

Is this the right approach? What's the best way to keep the development and testing in sync?

Developers do not seem to like this approach much as they need their code merged into the develop branch at the earliest so their next feature branch that gets created from develop has the recent changes.

  • 1
    What did your devs suggest? I mean they are the one's that have to work with this system. – nvoigt Apr 16 at 6:53
  • @nvoigt doesn't the OP's last paragraph address that? – Sarov Apr 16 at 13:36
  • There are so many wrong things with this approach.. :) Devs don't even write tests for REST API themselves? That's new level of lazy :) You write e2e (I suspect you mean Selenium/Puppeteer?) tests for the features which are just developed? This is the most expensive code that you'll have in your whole code base. There should be few e2e tests and they should be written for stable functionality that has low chances of changing. You better get a manual QA who's going to really actually the functionality instead of someone who's doing work for lazy devs. – Stanislav Bashkyrtsev Apr 16 at 16:29
  • @StanislavBashkyrtsev Thanks for pointing out. Dev is writing the unit tests for the microservices. Not integration and e2e tests for the microservices. Is that not how it should be? QA writing e2e I meant Cypress . Also, QA is writing the e2e for micorservices. I was thinking we could push off the integration for microservices to the dev but is it so that the dev should be writing e2e for microservices as well? – S Khurana Apr 16 at 17:02
  • 1
    I'd push as much of automation to devs as possible. It's often hard to convince them to write UI e2e tests, but writing tests for API (be those e2e or not) is a norm. And no matter who writes them - the number of UI e2e tests needs to be small, if it's the beginning of the project - probably less than 10. They are huge pain in the neck and rarely pay off. It's certainly okay NOT to write them right after the feature is ready - users/stakeholders may ask to change the functionality after they start using it, so is it worth to invest so much time for something that will change soon? – Stanislav Bashkyrtsev Apr 16 at 18:12

One approach you could try is to have the QA working ahead of the developers.

It would work something like this:

  • Back end devs write stubbed API calls that mimic the behaviour of the finished functionality
  • UI devs create a boiler plate front-end that calls into the API (getting results returned from the stubs)
  • At this stage there is no implementation code written, just framework code
  • This should be quick to do
  • The QA starts work on writing their end-to-end and integration tests, using the boiler plate front-end and the stubbed API
  • Devs set about doing the actual implementation
  • QA finishes their tests before the devs complete
  • The devs don't now have any dependency on the QA - they can use the existing tests to confirm their code works as expected

This will take some coordination and you will have to plan things carefully. In effect, it is test driven development done at a feature level.


TLDR: Optimize for throughput and your people will become T-shaped.

First of all, I should address

Is this the right approach?

To which my answer is "Don't ask strangers on the internet. Try it and see." Agile incorporates two concepts that are relevant here:

  1. Attempt-inspect-iterate cycles
  2. Self-managing Teams

Regarding the first... try it and see. Make sure you have some measurable baseline, such as throughput (the time it take to get an individual ticket from 'In Progress' to 'Done'). Then try your suggested change for a week or three. Then measure again and inspect.

Because of the second, though, I would strongly suggest against just forcing this down on the Team. The 'try and see' approach should help this somewhat, but you'll still need to address their concerns. Which brings me to...

Developers [...] need their code merged into the develop branch at the earliest so their next feature [...]

To which my suggestion would be... don't immediately jump onto the next feature. The feature you just 'finished' may be done, but it's not Done yet! Instead of jumping to something new and cramming more work in-progress, focus on getting that one ticket all the way to Done first.

Now, yes, the non-QA devs don't have experience with

microservice integration and e2e tests

but... so? They can learn. One of them can pair with the QA while another researches on his/her own and the third can work on an unrelated pet project (for example). By including slack time (optimizing for throughput rather than utilization), you focus on getting individual tickets Done while allowing your team members to sharpen their saws. In this way, over time, your developers will gain new skills (become T-shaped) and may be able to take on some of the QA tasks themselves, thereby allowing the team to get tickets from In Progress to Done as fast as possible.

Which in the end is what you want, isn't it?

  • Thanks for your comment. I was a little worried about pushing off much work to developers and that it might affect the development pace. Generally, are developers supposed to be writing the microservice integration and e2e tests? – S Khurana Apr 16 at 17:06
  • @SKhurana Regarding "I was a little worried about pushing off much work to developers and that it might affect the development pace", it works both ways. Once the QA is done, the QA won't have any direct work to do, so s/he can assist the devs as well. If s/he can write integration tests, s/he can learn to write unit tests as well. – Sarov Apr 16 at 17:29
  • Regarding "Generally, are developers supposed to be writing the microservice integration and e2e tests?", if you want my personal opinion, yes, but again, I'm just a stranger on the internet. Every company is different. – Sarov Apr 16 at 17:30

One possible technical solution here might consist of asking them to create a second version-control branch. When the developers believe that they've finished their work, they move into a "pending QA-testing" branch. Final merges into production take place only from that branch.

  • In that case, what do developers create their new branches from? @mike robinson Devs wish to have the recent copy of the codebase when they are creating a new branch. – S Khurana Apr 16 at 17:25
  • 1
    @SKhurana developers would branch off of the 'devDonePreQa' branch. This approach could work, though it could get messy if a bug is found and you suddenly have to propagate the fix to multiple branches. – Sarov Apr 16 at 17:32
  • 2
    In modern CI the best branching strategies are those that use as few branches as possible. The most advanced of them is trunk-based development where there's only 1 branch. So I'd certainly consider other options before thinking of branches. – Stanislav Bashkyrtsev Apr 16 at 18:17

Here's a strategy that works really well for me, as a project manager who also has a very long history in pure software development: "that there are two distinct manifestations of the idea of 'software testing.'" Even though the identical term is used, they are in fact disjoint activities. Each one is applied at a different time, for an equally legitimate purpose.

(1) "Test-Driven Development" refers to the notion that the individual software developer can't "close the ticket" and "have his change accepted" until he provides both the source-code change and a test which proves not only that his change worked but that it didn't break anything. (These tests are to become part of an ever-growing library of tests which can be automatically and continuously applied by "the build process.") This is taking place at a "fairly microscopic" level most of the time.

(2) "Classical 'QA'" (for lack of a better term ...) is an independent and more business-focused activity – also frequently automated, but in a different way – that ought to be conducted by an entirely separate team. This is looking especially for customer-visible and business-impactful issues "that have nothing per se to do with 'the source code' or 'the latest change.'"

And there is – and is intended to be – a synergistic relationship between the two. If you wish, "one is focused on 'how,' while the other is focused on 'what.'" If that mistake-fish is going to "make it out into the river and cause trouble," it's gonna have to pass through two different fish-nets!

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.