Should QA test features that are already covered by developers (according to what they say) with unit tests?

Question

Should QA test features that are already covered by developers (according to what they say) with unit tests? From the one point of view it could save time, from the other - after all many developers think that they have done everything right, covered everything with unit tests and QAs are useless )

Answer 1

There is no concept of overlapping testcases in different test levels,

Both are completely isolated

Just because API or Component works fine you cannot guarantee the whole system or integrated system works fine.

Imagine all your unit tests passing but user not able to use the UI or API workflow, Imagine all your UI working due to cached information but the actual backend is failing.

Ensure more low-level coverage like unit test and API test, this ensures that you will have faster test execution and build feedback. This will also ensure faster debugging as your tests will be more focused on component or feature.

In UI test actual business flow and error handling tests

In each test level we have different test scopes.

Unit test;

We don't test the business flow but the component and functionality

Integration Test

Integration with other components, how stable is the integrated subsystem to be able to be used to extend with higher-level components. Like API with UI

System Test

Here you test Usability, user interactions, visual regression, business logic and flow.

So there is no concept of overlapping tests in different test levels.

You can read the following answer for some of the overlapping scenarios:

https://sqa.stackexchange.com/a/45609/40022

Answer 2

What testing needs to be done is obviously dependent on the feature itself. But, I'd be finding out what unit tests have been written to see what the developers have covered as a starting point.

Then, based on the feature, I'd be thinking about what else needs testing and where I can test that (e.g. integration testing or full on end-to-end testing).

The unit tests may well cover a lot - they may even give very high code coverage of the changes. But they likely won't be covering integration or anything else (as then they wouldn't be unit tests). This is where additional tests come in (to investigate those areas of risk).

Answer 3

I'll assume you are keeping in mind what @PDHide said about overlapping test levels.

If developers say some part of the functionality is covered by unit tests, but you keep finding bugs that show otherwise, you have proof that they should either a) repair unit tests or b) stop saying that area is covered.

Answer 4

Given that in normal (non safety-critical) software development there is usually not enough time to achieve 100% test coverage it certainly makes sense to reduce overlap between tests and focus on requirements which are not tested elsewhere. As a tester I would, all else being equal, also listen to the developers and in-depth test parts of the software they feel most uncomfortable with, if necessary at the expense of other parts.

Even if the goal is to eventually have comprehensive tests on all levels it still can make sense to start writing tests for requirements that are not being tested elsewhere yet. The reason is that even cursory tests are better than none at all, and redundant tests have a smaller chance of detecting hitherto unknown errors than tests which extend the test coverage, and that it's better to detect errors early.

So in principle you should write complete tests on all levels, but in reality it may make sense to use limited resources most effectively, which includes reducing redundancy.

Answer 5

While agreeing with the existing answers, I have a different take: In many cases, QA should be approving the test cases, ensuring that they match the actual requirements. Some kinds of requirement communication, such as behavior-driven development, try to make the written requirements as close to actual executable tests as possible, and I've successfully run projects in which non-technical product owners were able to directly read the actual test cases (for this, Spock is fantastic, with Geb for Selenium testing).

If verifiers can, instead of simply performing manual testing, verify that the automated tests do ensure correctness, then that's a force multiplier for QA, for development, and for the product owners. This isn't always possible, but it's one mode of working that's been highly successful for me.