Feature branch testing before code is merged?

Most of the software testing company follow the strategy of performing black-box testing on feature branches if QA team has enough time in the testing cycle.

In feature branches, QA team only do the feature testing and run a smoke test on the feature just to make sure that basic functionality works fine.

There are a lot of benefits if QA team perform testing on feature branch like:

1. If the developed feature is not as per the business requirement then it can be raised to Dev team in the early testing cycle.
2. QA team focuses more on feature testing and in-depth testing can be performed for each and every part of the feature.

A lot of things can, and sometimes/often will, go wrong with merging. So any tests done before the merge will not spot any bugs (re)introduced during merging. This is something you have to keep in mind when you (partially) test before the merge.

Most of the above answers have explained the concept of "Context" when making such a decision .

I would like to iterate on test strategies when planning to test feature branch:

1. You don't have to do regression test in feature branch
2. You can do feature testing (testing of the feature that was newly developed)
3. Sanity test (basic functionality works fine)
4. Smoke test critical functionality works.

In sanity and smoke try to identify overlapping use-cases which will cover both sanity and smoke use cases in one go, e.g.: for firmware update you will have to upload firmware and update the firmware. Here both uploading functionality (which is basic) and firmware getting updated (critical) both are covered.

So you don't have to spend too much time figuring out what to do, in most cases smoke test will cover sanity also.

Benefits of feature branch testing:

1. It can be more agile and can provide faster feedback
2. If a feature is not working as expected or requires improvement you can communicate it earlier to the dev team
3. You can learn more about the feature and thereby improve your overall domain expertise, which eventually will help in devising better test approaches
4. It helps in more feature focused testing than software as a whole. This helps in finding more use cases that you would have missed out otherwise.
5. More dev-QA collaboration, chances for white box testing if you create an etiquette with the developer where developer will be explaining why a build failed what code block was causing the error.
6. Avoid feature reworks and unnecessary context switches for dev team, which in turn will help in more smooth relation between QA and Dev.

Note: even if it's feature branch or integration build, dev team should pass it to QA only after basic test from their side.

Disadvantages:

1. If there is no proper communication and effort estimation, then this will be more workload for QA. You might lose productivity in testing as you might get less time testing the actual integrated build.
2. Bombarding limited QA resources with testing across all test level is like running an engine above its capacity and things won't take time failing.

So, see if you have enough time, and resource to do this, then it's a really good opportunity to learn and be more proficient in your domain.

If you are a single QA who handles all this then it's a BIG NO you will just exhaust yourself and feel like the environment is less supportive and more toxic.

As others indicated, there no standard norm but more like each company norm.

I had the same question as you before with my previous company but at that time we started moving towards microservices and with Agile there are lots of featured/improvements being done in 2 weeks. So we are divided in team for the features/improvements and each team have QA member to support them.

As a QA person on that feature team, we are encouraged to do the smoke testing locally before the manager approved it to be merged on develop branch. And if all feature passed through, the develop branch will be deployed in staging environment. All QA will be require to test it thoroughly.

As my manager told me, in this way, we are making sure that there will be no left out cases on the feature branch and making sure that the develop branch will not have lots of merging due to miss out.

This is just on my experience though.

I wrote an answer to a similar question on the Software Engineering Stack Exchange.

There is no "industry standard".

In a perfect world, I would want the testing to happen twice. The "first pass" of testing is on the feature branch. This gives the manual testers the opportunity to create their test cases, make sure they all make sense, and that the feature or change is well covered in isolation. The primary objective of this pass is not so much the testing, but the discovery of what and how to test. Of course, it could find issues that a developer missed as a result of that discovery. The "second pass" of testing depends on your release process. In gitflow, where you have release branches, the second pass is done in the release branch. A different release and branching flow may have it done somewhere else. Developer-led testing, both manual or automated, would be done during development, reviewed during any kind of code reviews, and I would expect it to be done before or in parallel with the first pass of manual testing.

However, we don't live in a perfect world. Manual testing is expensive, so doing it twice is doubly expensive. It may be a little less than doubly expensive, since the first was a dry run and the testers are more familiar with the test steps and how to execute them. It may also be more if a large amount of evidence needs to be recorded for compliance.

There are a number of paths to follow. Perhaps the "happy path" tests can be run and constructed against the feature branch and the release process can include more negative testing and exploratory testing. Depending on the features being developed, there may be ways to combine testing during the release process that isn't feasible during feature branch testing.

It's up to the organization to evaluate the costs and risks of different options and choose the one that makes sense for the given context.

I am not sure if there are any standards for that. I believe this might depend on a lot of factors specific to your project.

In my experience we do not perform any sort of manual testing against feature branch because there are usually a lot of features in release scope. So we have a release branch and we do development auto-tests/CI when feature is being merged to the release. After having all the features merged we can be sure the app has the completed state according to the design implied by the release scope and it is safe to run all the sorts of QA tests.

From the Context-Driven Testing Principles:

"The value of any practice depends on its context."

There is no "industry standard" for this, and even if there was a 99.9% consensus in adoption on one practice or the other, the value of the practice is still dependent on your context.

That being said, some things that you may take into consideration when making this evaluation:

• Features branch testing would yield better information the closer your branch is to the state the change history will be after merge.

If non fast-forward merging and long-lived branches are the most common cause in your repository, the info you uncovered by testing is more likely to not be valid after merge.

To mitigate this, constant rebasing and constant merge against master.

• Feature branch testing (earlier testing) means an increase in building and deploying for testing. If your building and deploy process is slow and error-prone, you will spend a lot of time in test preparation rather than on product exploration.

• Feature branch testing works better when communication is direct and honest. If the relationship between testers and developers is primarily through documents and bug tracking systems, in a pipeline fashion; rather than face to face and through pairing, the testing activities may be a bottleneck and create situations like raised on the first point.

How to know which would fit better? Create experiments.

Plan what are your goals, propose metrics that would tell you how were these goals achieved;

Perform the experiment in a timebox or in a couple of features;

Collect the metrics;

Adapt your practice based on your learnings;

Repeat until satisfied.