Engineering Liability of Code
When does Engineering stop ownership
Some QA Engineers thinks that once a product hits production that they no longer have any ownership. They would be wrong.
As for Engineers, they own the change until the product actually ships. So during test periods, QA would assign any issues related to the change to that particular developer. They certainly can deferrer the bug to someone else, but in most cases, they should be a single point of contact of the change.
In my experience, I have found that developers will celebrate when code gets merged into the release branch. However, it isn't over yet. There still could be bugs/issues related to the change not discovered by initial testing.
Found this graphic on the WallpaperFool.com website. Imagine how much better code would be if all developers followed this?
Always be Updating the Test Case Repository
QA has ownership long after the product hits production. After a product/feature ships, it's the QA Engineer job to update the regression tests around the change.
If the change was small, such as a cosmetic image change, then there's no reason to go all out on automation and manual regression.
However, if the change is big, then the QA engineer responsibility is to make sure that regression test cases and manual test cases are updated. If they aren't other QA Engineers that run the tests may report the change as a bug.
When to Update Automation?
I believe that Automation should be updated once the feature is merged into the branch that's being shipped. (In some companies this would be the 'Master' branch.)
This way the automation test cases can still be run and may discover other issues that may be missed by manual QA.
Note: This topic came about when a developer once told me that they aren't responsible for a bug because it was merged into the release branch with no issues. Wrong! You own it because you made changes. This doesn't mean that you have to fix it, but you should figure out how/why a bug was discovered.