3

I have a book which mentions:

"There are many types of testing, including unit testing, integration testing, functional testing, system testing, performance testing, and acceptance testing".

It is often noted that many developers carry out unit-testing only, or no testing at all. From the types of testing above, which ones are to be conducted by the developer? What are the responsibilities of a developer when it comes to testing?

  • 1
    "every Java Developer carrys out Unit Testing" I wouldn't go that far.. Testing is a general subject and not language specific. Use the tests you need/like, this won't make a difference if you're a Java or a C++ developer. The major limitation for some languages would be the lack of a testing framework. – Jeroen Vannevel Jun 8 '13 at 10:19
  • I've entirely rewritten your question to clarify it. You wouldn't have attracted interesting answers, and your view of testing was pushing a bias on the answers. – haylem Jun 8 '13 at 11:34
  • 1
    In an ideal world then certain software development tasks will only be performed by the person with the appropriate role to perform said tasks... but in reality, there isn't always a QA assigned to your project, or maybe the BA also performs testing roles, or perhaps another developer, or perhaps there is no BA at all and you are responsible for gathering requirements. The bottom line is that in a job we are not always perfectly placed in our specific identifiable role. – maple_shaft Jun 8 '13 at 11:38
  • @maple_shaft: True. And our job in the end is to deliver software. Alone, or as a team, or as a group of teams cooperating together. If there are clear-cut definitions of everybody's role, stick to it and make the best of it, and support each other. If there isn't or your on your own, do what you've got to do and also make the best of it. We all need to work within our constraints; and then learn from our mistakes for the next project that comes along and try to improve the state of things. – haylem Jun 8 '13 at 11:49
  • possible duplicate of Should a developer also act as a tester? – gnat Jun 9 '13 at 20:28
8

All Languages Support All Kinds of Testing

The way you formulated your original question, I think you were approaching testing the wrong way and make too big a distinction between kinds of progammers and their roles, and making assumptions on the link between a language and the testing taught.

All languages allow for all kinds of testing. They may have built a more in-grained culture around testing, and may provide more tooling, and have some language features that facilitate it. And it's true that if you were to conduct a literature review, mainstream books about testing may have been appearing around Java's introduction and rise to fame, and relying on it to illustrate their points.

But all languages allow for testing of all kinds.

What's Your Responsibility?

Not Invented Here strip on testing

So, now, to try to answer your original questions:

What other testing does a Java Developer do from a Java Developer's Perspective?

and

As I have already mentioned every Java Developer carrys out Unit Testing. From the 1's I have described above, which 1's are done from a Java Developer's Perspective?

All the ones you've listed afterwards in your answer:

  • Unit Test
  • Integration Testing
  • Regression Testing
  • Performance Testing
  • ...

Of course, depending on your company some of the tests may not necessarly need to be performed by you. For instance, accpetance testing or performance testing are quite often left to other teams.

Plus, some testing may be done as "black-box testing", in which case it may even be best than you don't know the internals (or you may not have a choice to know at all), and in that situation it is of course less relevant for the original developers to be part of that testing effort. But they can still add their input, and they are likely to approach the problem in ways others may not have thought of.

However, I'd strongly recommend that developers, of any kind, participate in all testing efforts themselves or by directly working with whoever performs the testing in close-knit relationship.

It's a Matter of Culture/Philosophy, not of Technology

Most of the times, software shops host separate testing and development teams do it for the wrong reasons, or because they are kind of pushed into it (or feel lile they're pushed into it) by the development lifecycle and their methodology.

It's not a fatality and can be changed.

Also, some testing can sometimes be done on top of existing efforts by non-developers. It's best to even advise your clients to perform their own acceptance testing and performance to validate your results. And you definitely should press them hard to get involved in that, so you can make sure they know what they want, and that you know what they will expect from your deliverables!

A final note: testing is only relevant if you know what to test and how to interpret the metrics and results they deliver.

  • So, from you answer you mention some other left to other teams such as acceptance testing or performance testing. What about Integration Testing? Is it the actual Java Developer does it from a Java Developer's Perspective? – user2466019 Jun 8 '13 at 11:40
  • @user2466019: I say that some companies shift some testing to other teams. I also say I don't recommend to do that. And stop re-focusing this as a Java-only testing issue from a Java Developer's perspective (and why the capital on Developer??!): it's got nothing to do with Java. This is entirely language-agnostic, and in fact I'll add that tag right away. – haylem Jun 8 '13 at 11:44
  • 1
    @user2466019: Do integration testing if required for your job, and do what you can within the constraints of your project and role. If you don't additional human resources in your team or do not get to interoperate with other teams, it's all on you anyways. Think of it this way: your job is to deliver good software, that complies to spec and achieves its goals. You need to make sure of that. So if nobody else will test it, you shall. Doesn't matter if that was you or Joe's burden within anyone's perspective. – haylem Jun 8 '13 at 11:46
2

Boris Bezier says this:

"Programmers are responsible for software quality – quality in their own work, quality in the products that incorporate their work, and quality at the interfaces between components. Quality has never been and will never be tested in. The responsibility is both moral and professional."

If you are responsible for delivering quality software, how are you going to do that? The software must be tested. If you are in an organization that doesn't have dedicated testing resources, it is up to you. Even if your team does have testing resources, it's up to you to make sure testing happens. That may mean writing tests, or it may mean you follow up with whomever is responsible for writing the tests.

Bottom line: you and your team are responsible for the quality of your code.

1

"What are the responsibilities of a developer when it comes to testing?"

The explicit responsibility is:

  • write tests that exercise your code and ensure that it returns the expected output.

However I have found that the implicit responsibilities are:

  • ensure that the tests themselves don't have false positives - make them fail first.
  • make sure that the business owners know 'what' is being tested.
  • make sure that testing covers the users platform and not just the developers 'hot' machine.
  • make testing a part of features and aim to start getting some tests written before writing the code.
  • tell management that the tests are part of the software.
  • tell management that the writing the tests is what a professional developer does.
  • when bugs arrive, point to any lack of tests that would have prevented it
  • find stories about failures that reflected a lack of testing.
  • when bugs are found, write tests to reproduce & fix them and add them to your regression suite.
1

Testing is about verifying the correctness of your work. I think it's every developer's responsibility to do that.

I suspect that the author of that quote was primarily talking about automated testing. There's also manual testing, which is probably something that you're doing already.

What steps to you perform to verify that the code you wrote works? If those steps can only be performed with your participation, then you're performing a manual test. If those steps can be run while you check twitter, then you're performing an automated test.

If I assume that your question is actually:

What are the responsibilities of a developer when it comes to [automated] testing?

Then my answer is that you've got to make that decision for yourself. The rule I follow is based on "3 or more use a for". I'll tolerate running a manual test twice, but the third time that I go to run it, I force myself to take the time to write an automated test. I recommend developing a similar rule that you can follow.

-1

Depending on the type and size of your project, at least do "unit testing" of individual functions, then try to do some "system testing" i.e. put test data in the database, start the application like it would be done in production and compare the output with a saved copy of what you would expect. Between those ends there's "integration testing" where you test e.g. if some classes work together. Despite the name, you can do every kind of testing with the "junit" tool.

Not the answer you're looking for? Browse other questions tagged or ask your own question.