The term ‘tester’ gets applied to a whole range of professions that all do slightly different work. What testers have in common is that they

• try to break that beautiful piece of code you have just written
• look for edge cases and unexpected interactions between requirements
• provide their own, independent and uninfluenced, interpretation of the requirements
• look out for unexpected and/or uncomfortable reactions of the system

Some kinds of testers are:

• Test automation engineers are the ‘programmers’ under the testers. They generally write scripts in various languages to perform automated tests on a system. Usually, the system as a whole is tested as a black box, but sometimes the test scripts are more on an integration or unit-test level with a white-box system.
• Test engineers write ‘test scripts’ that are meant to be executed by hand, either by themselves or by the manual testers. These scripts should be based upon the requirements and/or issues that were previously reported.
• Manual testers are the ones that mainly execute (manual) test scripts and play around with the system as a kind of power user.

Traditionally, testers are not expected to have programming knowledge, and any testing that requires it (such as unit- or integration testing) falls under the scope of the programmers and the testers only come into view when you don’t need programming tools to interact with the system under test.

With test automation, the testers might come deeper into the code, but it is unlikely that they will ever start to work side-by-side with a programmer on a piece of code, because that would compromise their independent view on the requirements too much. This independent view is important, because it will bring unfounded assumptions and unclear or ambiguous requirements to light earlier.

I really don’t see any use of this. I wish I could just tell them what I coded and they would just write the tests.

Well, that’s not the world you live in. Besides, not everything can be done in automated tests. Additionally, “manual testers” are often people who have a lot better domain knowledge than the developers. Listen to them and you may learn a few things about why your system has the requirements you’re implementing.

I also have seen some brilliant software developers being testers at tech companies (Google, Microsoft etc.). Why do these developers want to become testers? Are their developer skills actually being used? If so, by how?

They typically have the job title “Software Engineer in Testing” or similar. And yes, their developer skills are used in writing tests just as much as yours are used in writing applications. Setting up a test infrastructure for a large scale system can in itself result in a complex test system.

I write the code and they write the tests...

Sure this happens at some of the top tech companies like google and facebook where they have full time, highly qualified quality engineers that have a programming backgfround such as you describe.

Now to the other 99% of the (‘real’) programming world: Most testers are doing most of their testing by running suites of unit tests, doing manual testing and writing some automated testing, however this is still in its infancy and not usually at the ‘per ticket’ level. Often more as smoke tests to allow mocking and stubbing in unit tests.

I would caution at the notion that they are not adding value as manual testers.
(btw I moved from dev. to test after decades of dev. myself.)

Manual testing still uncovers a great deal of issues including:

• different usage patterns and approaches
• integration issues
• different devices
• different browsers
• different browser versions
• different window sizes
• usability issues
• temporal issues
• bandwidth issues in real circumstances
• responses to invalid inputs

For your example: “a bit unnecessary for them to test a little functionality (ie this button submits a post request to xyz end point and sends these values).”

• What if they put in different values?
• How big is the button on a iPhone?
• Does the button have visible text on a Samsung 5 running Anndroid?
• Does the button and the button text have contrast to help color-blind users?
• Have the developer followed the company standards for font and font size?
• What if the network is down when they try to do the send?
• What if the button is an image from the CDN and the CDN is down, will it still work?
• How is the POST formatted, is it using the new PATCH type and is that accepted on the server?

I think the problem here is that you are confusing a particular sub-set of testing “unit test” with the much larger set of tests generally accepted as “testing”.

Unit testing is generally done by the programming team themselves. It could be manual but most often using an automated testing framework such as Junit.

Generally speaking the testing team does not care about unit testing there sole job is to test whether the system works to spec. They do not need to know how it was built, what languages frameworks were used etc.etc. to establish whether it works or not.

Testing apart from unit testing falls into several categories:

• Smoke test — start the system and see if it can stay up and running for a day so.
• Functional testing — does the program do what the spec says.
• Integration Testing — does the program play well with the other components in the larger environment.
• Non Functional Requirements — does the program meet any NFRs in the spec (response times, throughput, hardware requirments, memory footprints etc.)
• User Acceptance Testing — Get the real users to use it, confirm that the system is usable, and does what the business sponsors really want.

Its almost impossible to write code without introducing bugs. Worse its almost impossible to specify a module correctly.

So unless your name is “Bill Joy” you are going to introduce bugs when you code. Even if you code precisely to spec the finished module can still be wrong.

All good programmers that I know believe there programs to be full of un-spotted bugs, and know in there hearts that know matter how careful they are they will have done something wrong. Edge cases can be a nightmare to code correctly (should a loop execute n times or n – 1 times). Interface specs can be in-complete and ambiguous; you read the docs but you really don’t know whats going to happen when you call the API.

Testing is fundamental to the software development process, if 50% of the projects time is not devoted to testing of various sorts then the code will fail soon after deployment. The failures could be trivial, they could be deeply embarrassing, or, they could be disastrous.

So learn to love your testers! Rejoice when they find a bug, they just saved your ass!