I've faced this question in an interview..But I couldn't answer it well...
Actually, I don't know the exact and professional answer for this one...Can anyone please help
On my mind comes at least three thing:
If unit test are developed by developer with focus on testing simple functionality: then you as tester (this highly depends on experience of developer with for example Test Driven Development or experience with testing his own work) can assume that basic function are working (review of unit tests is nice thing, to get to know what is already tested) and focus on covering more advance functionalities. And thus obtain better coverage
If there are unit test running after new build, you can get information about state of build earlier. So repair of broken state will be quicker, and you will not waste time with unstable build. With this is connected self-confidence of developer with their work. for everyone is better to discover their mistakes themselves. So if you can test your code before commit, there will probably be less mistakes.
Some testing frameworks are in fact based on unit tests. At least with selenium and Java, you will use JUnit to make assertion about states of application under test. And thus testing it.
Test efforts should use the Agile Testing Quadrants to see where Unit tests fit in. Also you should respect the test pyramid with most tests being unit tests and a much smaller number should be automated UI. So I recommend starting by making sure this common knowledge is shared.
End to End UI automation should test the front end and whether the user can get through the screens and understand what's going on and the screens work appropriately to provide/collect information.
So... unit testing is intended to:
With this knowledge, you will have a good sense of what should be tested where.
The fact that you have unit tests that test data combinations and different inputs mean that you do not have to test all those various combination through the UI (what I term 'data combinatorial testing).
I am seeing this right now in my work where traditionally we have 1700 UI tests. We have re-worked this to be 70 UI tests and are now in the process of creating the thousands of unit (and integration) tests that the 1700 tests was mostly testing.
In addition to the great answer of tugo I would say that unit testing can help QA/SDET (however you call them) in verifying test tools s/he creates.
For instance, if I create a testing library for mocking services in my tests, I want to make sure it works properly and bugs in my test tools do not mask bugs in a tested code. One of the rules I've learned when working on automation is to treat test automation code the same way as production code even if it does not land on production. This includes: versioning, code reviews, release cycles, CI and unit testing.
Above replies are correct, but one important aspect is also there,
In some some critical cases, when s/w patch has to delivered on emergency basis, and only tester executes P1 and automation sanity only, then a walk through of Unit test plan and results helps tester in decision making whether S/W can be released or not. Of course ownership lies with tester/test team only.