It always seems a missed opportunity when testers choose to ignore unit tests, yes they are usually hidden from sight (buried away with the code) and created and owned by developers, but the depth of information they can provide about the code and the developers themselves makes it well worth the effort of finding and deciphering them. Good unit test coverage will give you confidence in the product, you should be finding fewer problems with the basic workings of the system and can instead focus your time and skills on testing the complex business logic and integration of the software.
Unit tests are small tests written in code to check the basic functionality of a single block of code. They are not small tests (a selenium tests that checks a single field is absolutely not a unit test because it goes through all the layers of the system and is therefore an integration test). Developers tend to rely on them for fast feedback during coding but if you have unit tests running in your build process then finding out what gets tested by the build will give you a great start on sanity testing the product.
Unit tests alone won’t give you a quality system, just because a unit test passes doesn’t mean the user is going to see the right information. Always consider the layers of the system you are testing, even the simplest website is going to have some code and a frontend but it pretty common to find databases, web servers, load balancers amongst other things, you want to make sure each is working individually but you also want to make sure they work together. Maybe most importantly you want to make sure they don’t just work but are correct according to the business requirements. Just like any code product you’ll need to re-assure yourself that the tests are correct but after a few cycles of testing and building you should be in a position to trust the tests and start testing the real risks. Of course It is possible to test all of this with manual testing but you’ll find a lot of bugs so expect a fairly long bug-fix and retest period.
Unit tests will never be written by testers, and sometimes you’ll need some help to find and use them but testers shouldn’t ignore such a rich source of information about the system. Don’t duplicate testing, be smart and focus your efforts on things which are complex, risky or difficult to test with automation. If you have buggy builds, long build times or find developers showing a reluctance to re-visit old code then start voicing your support for unit tests, it’ll benefit quality for the users and the whole development team should benefit from faster build and release cycles.