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.

This might help you:

Q1 are written by the developers.

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

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.

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.