I am currently working on a rather large project, and I have used JUnit and EasyMock to fairly extensively unit test functionality. I am now interested in what other types of testing I should worry about. As a developer is it my responsibility to worry about things like functional, or regression testing? Is there a good way to integrate these in a useable way in tools such as Maven/Ant/Gradle? Are these better suited for a Tester or BA? Are there other useful types of testing that I am missing?

  • 2
    While simplistic in practice, scale outwards as far as allowed in your environment while remaining conversational in practice versus isolated, which is what typically exists. Think of the end to end team as more than segregation and more about skill-set, each team represents a varying skill-set which should be leveraged for end to end success. The team should be responsible for success of which tests are needed to achieve. How they are tackled with regards to implementation is just that, an implementation detail based on skill-set. Dec 17, 2012 at 17:16
  • 1
    The answer to this question will also depend on the skill level of the other team members. For example, on a team where QA does not have strong programming skills, developers might find themselves doing more than on a team where QA can write their own test harnesses.
    – neontapir
    Dec 17, 2012 at 17:28
  • A good criteria is how automatable the tests are. Programmers are good at automating things with code.
    – rwong
    Dec 19, 2012 at 4:40

10 Answers 10


It is your responsibility to strive to deliver defect-free code. You should write, help write, or ensure tests get written or performed in order to give you confidence in the code you are delivering.

Note: I'm not saying you are required to deliver defect-free code. Rather, you should attempt to write the best code you can for the requirements you were given. Part of being able to do that means the code should be tested.

Whether that means you are personally responsible for functional and regression tests is mostly a function of how your company is organized. All of the highest skilled programmers I know don't ask themselves "is it my responsibility to write tests of type X?". Instead, they ask themselves "what must I do to make sure my code is properly tested?". The answer might be to write unit tests, or to add tests to the regression, or it might mean to talk to a QA professional and help them understand what tests need to be written. In all cases, however, it means that they care enough about the code they are writing to make sure it is properly tested.

Bottom line: you should be responsible for delivering high quality code. If that means you need to write some functional or regression tests, do it.

  • I agree whole heartedly with the delivering high quality code part. I was referring more to "above and beyond" good code. For example, do changes that are considered "bug free" within your perspective have a negative performance somewhere else. The best example I can think of is a requirement isn't properly vetted for load. So my code causes load issues on the server even though it is "bug free" (ok so the argument can be made that it isn't but humor me). P.S. I think your confidence part is key here.
    – Jackie
    Dec 17, 2012 at 17:11
  • 11
    It is your responsibility to deliver defect-free code It is the responsibility of the developer to build what was asked. Defects can and do surface from requirements poorly gathered/interpreted, environmental issues in a given deployment, conflicts within an OS, etc... Unless root cause analysis is performed on each and every defect, defect-free code to the business means they expect it to do what the user expects and anything less is a defect. It is unrealistic to assume a developer can remain involved throughout the entire SDLC to simply increase confidence; that won't scale. Dec 17, 2012 at 17:13
  • 2
    "Program testing can be a very effective way to show the presence of bugs, but it is hopelessly inadequate for showing their absence." -- Edsger W. Dijkstra, "The Humble Programmer" (Turing Award lecture), 1972. Dec 17, 2012 at 17:19
  • 1
    "It is your responsibility to deliver defect-free code." is fairy land. You can deliver what the scope requires but edge cases and business logic interpretations make your statement impossible to live up to. Why do you think every major release of software has releases and patches etc? Because we are all imperfect including the business logic. Dec 17, 2012 at 19:10
  • 4
    Would everyone who is taking issue with the first sentence of this answer be happier if Bryan had worded it "It is your goal to deliver defect-free code" ? Dec 17, 2012 at 19:49

This might help you:

The agile testing quadrants

Q1 are written by the developers.

Q2 are automated by the developers and written in collaboration with the business and/or testers.

  • Developers are often involved in Q4 testing as well.
    – neontapir
    Dec 17, 2012 at 17:26
  • The linked file can no longer be found. Dec 24, 2012 at 9:28

Are there other useful types of testing that I am missing?

There is acceptance testing for which I'd recommend BDD-style frameworks which use Gherkin language: JBehave (Java), Cucumber (Ruby), Behat (PHP), etc. This type of testing has some advantages over unit tests:

  • Tests are easily readable by non-developers, so you can show them to customers
  • Tests clearly describe business processes without going into implementation details (I don't mean implementation is not important - it sure is - but it's better when you separate business requirements from the code itself)
  • Tests do things which users will do using your application
  • They are easier to write (IMHO, may depend on the language and framework): no mocking, less technical details

Functional test can be automated just like unit tests, and are very useful for testing how the different components of your project work together, and how well your system reflects the business rules.

Also, this automated test, serves as regression and acceptance test suite for any major (or minor) changes you have to do to the software (bug fix, refactor, business change, new functionality, etc). This gives the developers a lot more confidence to do so.

There are several frameworks for this kind of testing, we are using fitnesse with very good results. Has a very good library for testing web pages (we use it for testing our web app and our web services) and it integrates very well with Maven and Jenkins.

We also used to do "cross functional testing", between developers, but this kind of testing is not "repeatable", so its usefulness is limited...


As a developer I consider myself to be responsible for unit testing all my code and guarantee to the best of my possibilities that it has no defect. That's why we have so much tools at our disposal such as mocking. The goal of creating mocking objects in your tests is exactly to try and isolate your code from the "outside" world and guarantee that it's working fine and if there's anything failing, "it's not your fault".

That being said, despite the fact that it's not your fault and that your code is working as it should, that doesn't mean you can't help in the rest of the tests. I believe it's also your responsibility to help and integrate your work on the work made by others. IT Development teams should work every time as a well oiled machine, working together with other departments (like QA) as a bigger team to provide reliable software.

But that's the work of a team, not only yours.


Obviously integration tests; they are more important and more difficult to write than unit tests. It's like building a house; with unit testing you only assure the fact that the bricks are solid and resist the pressure, temperature, humidity and other conditions. But you have no clue how the house looks and behaves with the bricks put together.

The problem with large projects, especially Java ones residing in a container is that integration testing is difficult. So to facilitate system integration tests in large projects, a testing framework is needed, made specially for the project, which is the developer's job to code it. Recently great improvements have been made in this area and platforms like Arquillian greatly simplify the writing of a testing framework (or even substitutes it).


In the real world you are only as responsible as your team / boss holds you accountable to be. If you are paid or indentured to toil endlessly to find every nook and cranny edge case and jump to the whim of your boss's (or worse marketing's) interpretation of business logic bugs, then by all means, you are responsible for all.

So in other words, do what is required by the scope given to you. Its a nice extra to throw in some common sense or see others use the product you are building to get a sense of use cases and possible issues to fix but bring this up to your team or boss prior to "fixing". This includes the tools of your choosing. All your efforts should be something everyone is on board with.

If your question is of useful bug tracking, I like bugzilla, google docs, zendesk or basecamp in terms of communication systems.


I don't think this has already been covered - sorry if I missed it.

One issue is the efficient use of a developers time.

Developers often lack the skills to be good at certain types of testing. Partly, this is just natural. It's the same reason why authors have editors. It's very difficult to see the deficiencies in something if you're too close to it. But it's also about different skill-sets and different specialties.

That being the case, a developer spending time testing is poor in cost:benefit terms. That developer would be more productive doing other things, and a specialist tester would be more productive doing the testing.

Of course that's making various assumptions that aren't necessarily valid. In a small company, for example, it may not make sense to employ people who specialise in testing. Though it may make more sense to employ extra support staff and have them do some testing, or at least to get people testing code that they didn't write themselves.


I believe it is our (a developer also) responsibility to encompass all possible test scenarios before it is released for QA. The purpose of QA is to validate the software. Plus, hammering your own code for errors will always make you look good come QA time.

  • I think what I am trying to get at is what is considered effective "hammering".
    – Jackie
    Dec 17, 2012 at 17:18
  • That is definitely subjective. I'd say any type of test that applies to your project (not all test types apply to all projects, of course). Here is a decent list: softwaretestinghelp.com/types-of-software-testing. What you do yourself and what you choose to forego of course is dependent on your own time, resources, and ability. For example, you may not be able to perform Acceptance Testing because there are certain rules that only a user knew to follow. In short, do all you possibly can in the time you have. Dec 17, 2012 at 17:26
  • For my projects which are mostly web, I generally try to encompass Unit, Functional, Usability, Regression, Performance no matter what. If I have time, I go for White Box, Stress, Compatibility, even Acceptance if I know enough. My general style of coding is extremely performance-minded so I lower my priority on that. None of this means that QA won't find something wrong in any of those test types, it just means they will find fewer and make for a much easier round 2. Dec 17, 2012 at 17:30

Who better than a developer to know what test cases are the most relevant. The developer should be responsible for doing all the unit testing, where possible the developer should help to write and execute the testing scripts. Since this seldom possible in large projects time should be given for the developer to review all test cases. In addition the developer should have knowledge and use the wide variety of automated test tools available.

In my development career I find that projects end up with better outcomes were there is a tight integration between the development teams and the test teams.

at least one member from each team should sit in on the others planning and implementation meetings also.

  • 1
    The only issue I have with this is that there should be a degree of isolation between the developers and the testing team, otherwise the testing team becomes tainted with the developer's "the code works" opinion. QA and developers have opposing goals; the developer is trying to make it work, while the QA team is trying to make it break, and the developer does not always have the best perspective on test relevance. Dec 17, 2012 at 19:58
  • I disagree one hundred percent, but then again lately I have been involved with mobile applications and I think they require a level of integration a little beyond what is traditional. Notice I use the term integration. there can be isolation but both teams should review and contribute to the test cases. It is unlikely the developers would have access to all required test resources to do proper testing, its also unlikely that testers would have the knowledge to develop test cases for something as advanced as streaming video over cellular networks. too much isolation = trouble. Dec 17, 2012 at 20:19
  • further I think the more vertical the market and more specialized them more integration between the teams is needed. actually everyone should go into the testing phase with the notion that the code works under some tested conditions but is more likely flawed then not Dec 17, 2012 at 20:22
  • This seems to work, test team produces a use case document using the functional specification. Development team reviews use case document based on technical and functional specs and adds cases as needed. Test team develops test scenarios from use cases. Development test review test cases. Time consuming sure, but better then testing later in deployment or production phase. Dec 17, 2012 at 20:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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