Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It only takes a minute to sign up.
Sign up to join this community
I currently work as a QA engineer and work a lot with Java, Selenium and test automation.
But, unit tests are something the developers have been doing and something that I fear. Is it difficult? Do you test engineers here at SQA work with unit-tests/white-box testing? Is it hard?
The second question is: Am I good with just working with black-box testing? I'm a little worried about my future.
Writing unit tests is not difficult - as the saying goes, it is matter of simple programming :-) So if you are competent programmer, and are willing to learn necessary skills and patterns, you can do it as QA engineer.
But IMHO (and best practices say that) developers are much better suited to write unit test - because unit tests use internal calls to application objects and methods - exactly the same calls developers already know how to use for application to work. So developers already should know how application works and what is expected correct result (change of internal status, which might or might not have equivalent in UI) of any internal method/procedure call, and can write unit-test for it without too much additional effort. If QA writes unit tests, s/he needs to learn all that.
Also, writing code which is easy to unit-test is good practice - developers should be doing it, because it forces them to write better code (code which is easier to test is also easier to understand and maintain). Ideally, in test-driven development, unit-test are written before code.
One reason why unit-test are good practice is that unit tests detect error closer to source where it occurred - unlike system-level test, which often detect error after it significantly confused system, and it may take complicated detective work to find core cause of a detected problem (which code unit is causing it).
You can learn these internal APIs and write unit test too, but with selenium, you test application from the "outside": which user actions will have which visible results.
You are right to be afraid to get pigeon-holed in single role. Learn as much as you can from adjacent areas - but decide what are your core skills, and put focus on those. I read somewhere that skills needs to be T-shaped: covering wide area even if shallow (not very deep), and deep in part of that area (your core expertise).
Nobody can give you guaranteed answer to your second question, only yourself can. Consider for current skills, your interests, company needs, paths to advance your career in your current company and other companies in your area, overall market, and possibly other markets it you want or are willing to relocate.
If you want to become developer, and your company is willing to get you training or even pay for it, writing unit tests for existing code might be a good way to transfer from QA to development. It will force you to learn how internal methods in core of your system work, and writing test is safe way to learn system because your code cannot break existing functionality. Bug in your test will be false positive (which is easy to detect and fix), or worse, false negative - test not failing when it should. But bug in test has no effect on user-facing functionality.
But if your company thinks that QA testers should write unit tests (and you cannot argue otherwise, even if best practices say it is better done by developers), maybe you need to look for an opportunity to work for a saner company (where you can improve your core QA skills more effectively).
Also, if developers in your company do not write and use unit-tests, they likely ignore other best practices, and you will improve your skills faster in different company (so you may consider looking for opportunity to work for a smarter company). Or you may try to explain your developers why unit-tests are good for developers too and THEY should write them (because it will help THEM to write better code, which is safer to refactor and improve).
A perspective from a developer:
A unit test is best written in conjunction with the code it's testing. It will shape the code to some extent: the need to write a test forces the code to be easily testable, which limits some code smells/anti-patterns. For example, a method that directly calls the database to obtain a user name will be hard to unit test until it's rewritten to rely on a mockable interface to get the same information.
Writing unit tests as a black box activity, after the code has already been written, and without development skills will be hard and very limited. You can only test what has a perfect API already - chances are that's not where the bugs are. It also eschew a major benefit of unit tests: encourage developers to write decent code.
I consider that writing a good test is often harder than writing the code it's testing.
Honestly, I've seen QA thrown under the bus many time by people thinking that (A) automated tests are a good thing, (B) developers are too busy/lazy to write them and (C) hey, it's a test - so QA can take care of it. I've never seen it work.
So that's the bad news.
The good news is that if you're interested there is an easy solution/career path out of it: learn to code. Do not focus on testing - just try to understand the code you're testing, take a couple Java (or whatever language) tutorials or classes. You might even push whoever had the brilliant idea in the first place to pay for it. Focus on refactoring (check out 'Working Effectively with Legacy Code' by Feathers). Find a partner in development that can explain how things work, what she'd like tested and collaborate on writing the tests. You don't need design/architecture skills at this point - just how the code works, and how to refactor it to effectively write a test.
Good luck!
tl;dr No, testers don't write Unit Tests for code developed by developers, but some developers/testers write automated tests that are not Unit Tests.
It depends on the definition of "Unit Test". There is still a large number of people who call things that really aren't Unit Tests "Unit Tests".
Real Unit Tests test small units of code, usually each test only tests a part of a single class, the class consisting of up to 200 lines of code. If a developer writes a new class by first writing Unit Tests - a practice known as TDD - they put a stronger focus on how the class will be used, since Unit Tests are simply the documentation of how a class can be used, and what behavior is expected. Unit Tests are about the ability to design and document code. There are several other benefits of Unit Tests, but this is the primary one by far.
From that point of view, it doesn't matter too much if the tester is good at designing and documenting code (aka if the tester is good at writing Unit Tests), because that's by definition what the developers are hired to do.
Unit Tests that are not Unit Tests
Quite a few people and companies have developed their own understanding of what Unit Tests are. Sometimes they start to call every test that's written in code a "Unit Test", while in reality there are other kinds of automated tests such as Integration Tests, or Acceptance Tests - to my knowledge the naming and scope of these has not been as clearly defined as that of Unit Tests.
These automated tests are a good thing. But erroneously calling them Unit Tests creates unnecessary confusion.
But who should write these automated tests? Someone who knows how to code and how to test. These people need to be found or trained, and are often recruited from developers or testers. Sometimes the position is advertised as "developer in test".
Mostly we have heard and read that whitebox testing can be done by Developer not Tester. It is because developer have more and depth coding knowledge.
But If you are having really good experience with coding and specific knowledge of programming language in which site/software build , then you can do whitebox testing.
Also about your second question it is depends on market. It is not necessary that tester must have expertise in whitebox testing. If you are excellent in blackbox testing with automation tool then its really fine for career enhancement.
Is it difficult?
This greatly depends on your development skills, but as unit-tests are often derived from from a TDD cycle I would think creating tests after the work is done is very hard. Its better to first write the tests first and then the code.
I would suggest you start reading the book "Test Driven" (it uses Java), this will make you understand how the TDD cycle works and gives practical examples. Also it contains a chapter about "Working with legacy code" also known as code that was not written in a TDD cycle.
I'm a little worried about my future.
There is always place for automated end-2-end and or automated UI tests, but if you look at the test pyramid its the smallest part of where you want to generate test coverage on the code.
I strongly believe the future of software testing is automated testing. As more and more teams switch from manual to automated testing I think on what ever level you build tests there will be work, until we can automate the creation of test-cases :)
Keep in mind that implementing these tests might shift more into the role of the developers, but there certainly will be room for designing the tests.
It's only difficult until you learn how to program. :) If you're already using Java and Selenium then you know how to program. You will have to learn how the code you're testing works and you will need to learn how to write unit tests.
tl;dr you can do it.
Usually QA do work related to high level tests like the functional ones. The unit tests are expected from the developers, as they are more aware of the circumstances of their development.
However, if there is time available on your project, verifying or even helping making those unit tests is very helpful as you can add new perspectives to what should be tested in this kind of test. Of course, you should know deeply enough the unit tests framework used by the developers, which usually are different from those used for functional tests.
Like Peter said, IMHO Unit tests are best done by developers. These tests really give the most benefit to them as it helps them ensure their code is working as intended at the most granular level, and it will help prevent bugs when changes are made to the code in the future.
If your company wants you to write these tests, but you don't have the skillset required at the moment, one thing we have done is to pair a developer with a QA person and have that QA person go through what would be good test scenarios and let the developer write the tests (this works best in Test Driven Design). This allows both parties to use their strengths while also gaining some insight into the other's way-of-thinking and techniques.
