2

I don't really understand the concept of testers. I just graduated and before I joined into workplace I thought I'd be pair programming with testers and using TDD where they will be writing tests and I will be passing them or something similar. However that's not the case. Apparently none of them that I have seen knows how to code. A few of them knows using basics of scripting languages, but that's pretty much all.

So essentially what happens is, when I am done with my code, I write tests (unit, integration etc.) for that and then push my code in. I tell tester what it is and what it does, then the tester tests the functionality and approves or asks for further discussion. 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.

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?

I am so sorry, I am really confused about this whole tester concept (and yes, it's not taught at university). I also have read the question Are programmers bad testers? however it mentions programmers getting involved of manual testing. While I have no doubt that a tester is great at testing a project, I found it 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).

Sarp Kaya
  • 331
  • 2
  • 6
  • @KilianFoth that's not what I was looking for. – Sarp Kaya Sep 22 '14 at 11:59
  • http://meta.stackexchange.com/questions/194476/someone-flagged-my-question-as-already-answered-but-its-not – gnat Sep 22 '14 at 12:15
  • 7
    They're testing to make sure you didn't overlook something. When you wrote the tests, you tested what you thought could go wrong - but in reality there's a whole lot more that can go awry. A good tester knows this and will actively look for such cases. It's a different mindset, really - one tries to create things, the other tries to break them. – Pieter Witvoet Sep 22 '14 at 12:21
  • asked and answered many times before, see eg [Viability of a Development Team with no *dedicated* Tester role](http://programmers.stackexchange.com/questions/230163/viability-of-a-development-team-with-no-dedicated-tester-role)? / [Functional testing must be done by external party to avoid bias?](http://programmers.stackexchange.com/questions/100637/functional-testing-must-be-done-by-external-party-to-avoid-bias) and multiple questions linked to these – gnat Sep 22 '14 at 12:29
  • see also: [Do testers have to look at source code?](http://programmers.stackexchange.com/questions/77991/do-testers-have-to-look-at-source-code) – gnat Sep 22 '14 at 13:19
  • 1
    *"I wish I could just tell them what I coded and they would just write the tests."* - Good luck finding programmers who are willing to exclusively write tests for someone else's code! – Alex Sep 22 '14 at 14:55
  • At your shop, you'd switch to TDD and they'd write tests and tell you what to code. – JeffO Sep 22 '14 at 20:35
  • IIRC, I learned about black box and white box testing in university and that was nearly 20 years ago now. – JB King Sep 23 '14 at 02:39
  • @AlexG you might look up the SDET job description which is showing up in more and more organizations. Its *just* testing someone else's code... http://blogs.msdn.com/b/chappell/archive/2004/10/06/239001.aspx –  Sep 23 '14 at 03:26

4 Answers4

6

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.

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
Bart van Ingen Schenau
  • 71,712
  • 20
  • 110
  • 179
3

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.

Michael Borgwardt
  • 51,037
  • 13
  • 124
  • 176
0

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!

James Anderson
  • 18,049
  • 1
  • 42
  • 72
  • 1
    I think this answer could do with a bit less attitude. I personally find it a bit condescending. ( "Obviously you lack some real world programming experience." ... is that really the best way to start an answer?). Especially since the asker says right off the bat: "I just graduated..." – Selali Adobor Sep 23 '14 at 02:38
  • @Assorted Trailmix -- yeah maybe its a bit strong. I just find it amazing that anyone who has written any code in any environment cannot see the value of having there code (and assumptions!) tested by a third party. – James Anderson Sep 23 '14 at 03:23
  • 2
    The question makes it clear the asker has some understanding the value. They're simply questioning how effectively testers are able to do all that for various reasons (and why those testers don't do that by writing tests) – Selali Adobor Sep 23 '14 at 03:35
  • @Assorted Trailmix -- you were probably right :-). Made some severe edits to the answer when I realized the OP was confusing unit testing with testing in general. – James Anderson Sep 26 '14 at 02:30
0

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?
Michael Durrant
  • 13,101
  • 5
  • 34
  • 60