So while I am doing my coding for a freelance project and updating my to-do list, one thing comes to my mind. Do you consider testing to be part of coding, or is it a separate to-do. Meaning, if Joe Programmer comes to you with this scenario:
Joe: “Hey, I have finished coding the part to arm the Laser-Guided Tracking System!”
Would you say:
You: “I wouldn’t consider that ‘finished’ until you have tested it”
or
You: “Well done, good and faithful servant! Now onto testing!”
I would consider unit test to be part of the coding activity. i.e. Your code works within itself, but without interaction with another program. If you just wrote the code, compiled it and said you were done, I’d roll my eyes at you, hit you with a clue by four and send you back to your hole to unit test it.
I’m a functional analyst.
I think there’s several parts of testing. The first part (basically “run it with some choice parameters provided by the analysts to make sure it can get to the end”) is the programmer’s responsibility. If I get a program for my own testing, enter the “basic case” parameters and get a data dump, I will not be a happy customer.
The second part (“run it verifying that everything requested is there and there’s nothing that evidently needs to be corrected, perhaps because it was forgotten in the original sendup to the programmer”) is my responsibility. This is where I detect things like “all the columns in the printed report are the same width, but some of them are for fields with only one character and others for characters with 32, please make the widths the same size as the original field,” which we often forget to send in because to us they’re obvious (a man’s “obvious” is another man’s biggest mistery).
The third part (“run it making sure that it fulfills business needs”) is the responsibility of my “superusers,” the people appointed by my clients to request code from me and do this testing.
I’m a programmer, and I’m with Nava - with one exception.
I will test my code to make sure it doesn’t blow up, and I consider that a part of coding. Then I perform my own testing phase where I make sure the program does what I had intended it to do and try to test all scenarios as I am aware of them.
After **my **testing is complete, I will then turn it over to user testing.
Is testing a separate process? Mostly.
I am a programmer and I am supposed to “unit test” anything I write. Which is a basic functional test that what you wrote does in fact do what it is supposed to do. Even if the work is trivial you’d be an idiot not to do this. Best practice suggests that you write/set-up your tests before you start coding. Sometimes the unit testing/coding is so tightly coupled that you could make the case that they’repart of the same process. I expect this is more often true for the more interactive languages, but I don’t work with any of those.
Once I think my code does work the program gets handed to a tester (who is not a programmer*) this is definitely a separate process. The tester should be working from a specification, not be hand-held by the programer(s). A tester is likely to (and should) test things the programmer never though of.
In my opinion, there isn’t really any difference between these. I need to make sure that my code gives me the results I want; it doesn’t matter where the error comes from as long as I correct it.
Testing has several parts.
Unit testing or sanity testing is the first level, and it is a part of coding. No code ever written in the history of time has worked correctly the very first time. Essentially the coder must test it to make sure it works under general conditions. there is no way it done until this level.
I a good system, the testing should then be passed on to an integration tester who makes sure it hasn’t broken anything else. Then finally it should be QA tested using indepth use-cases and verifiyable output recording.
I was an IT project manager for years and although I would include unit testing as part of the programming task I’ve seen other PMs break it out as a separate task. When I was a programmer I tested things as I was coding them. I would at least expect that their programs worked in isolation before we moved on to integrated systems testing. Of course that testing would shake out some more bugs in individual programs but that’s to be expected. Once the programmers and lead software engineer think it’s ready we moved on to QA testing and the programmers stayed out of that other than fixing bugs. The QA test plan was created from the requirements by the analysts and not from the programmers’ test results. Usually the business analysts and I did the first QA test to make sure that we wouldn’t embarrass ourselves when it moved to end-user testing. I tried as hard as I could to keep the end users away from the programmers so that they didn’t have to deal with interruptions by people who wanted to skip the change order process and revise the requirements without asking me first. They had enough headaches and weren’t always all that polite to the customers.
Testing in my organization goes through three phases:
In our shop unit testing is considered part of coding.
Sadly, so is project management, specification writing, mind reading and user testing.
Finally a subject that I can speak to with some authority. I have been doing software testing for more than 10 years.
Unit testing is definitely part of a programmer’s responsibility. There’s no better way to waste time and throw a project off schedule like when a software module crashes as soon as it is started. It’s like a home builder taking you to your lot and showing you a pile of lumber saying, “There’s your house. If there are any problems, just write up a list and I’ll get it fixed.” Where to begin?
A separate QA group is the best way to go. Maybe I’m a bit biased, but a simple 5 minute code change can involve hours of testing to make sure it didn’t break something else. It is a much better use of resources if the developer can focus just on writing the code and let the tester handle the testing.
I’ve also come to realize that a project manager, a developer, a tester, and a customer can have a lot of differing ideas on how something should function (I have never seen a spec that is foolproof). Testing his own code, a developer works under only his assumptions and may miss some other scenarios that he or the PM never thought of. Testers are taught how to work like customers and encouraged to do the most foolish things they can think of to mimic the worst case scenario the software could be subjected to. With newbie developers, it is quite easy to bring their code to its knees. Experienced developers learn to anticipate what QA will throw at their code and develop much more robust code the first time around.
[hijack] That is why it is bad to judge testers on the number of defects found. If a tester routinely works with experienced developers, then there will be a lot less defects to find. [/hijack]
Finally developers have a lot of code on their computers. That code tends to be the latest and greatest. It may not accurately reflect what a customer has on their computer or what is going into the next release. What they may have gotten to work with that new code may not work with the code the customers already have (resulting in the dreaded, “But it works on my machine,” excuse that QA engineers are all too familiar with). Thus it is best to install it and test it on a clean computer modeling the conditions that the software would be used in on a customer’s PC.
Once the we’re done with testing, the software goes into user acceptance testing where we give some of our customers the opportunity to try it out and make sure everything meets their expectations. Their goal is not to find defects and make sure the software is robust, but make sure that it meets their needs and expectations.
In all, testing can be rather fun. After all, the main goal is to break the software. What’s more fun than getting paid to break stuff. 
Anyone who might wonder why other people besides the programmer need to test code should read the classic Psychology of Computer Programming.
I agree with the general “everyone needs to test” responses, and want to add that machines should also do the testing. Random test case generators are very valuable test tools, since they explore corner cases that are often in the blind spot of an entire organization, and can find issue before the code goes to a customer who doesn’t see the world in quite the same way as the developer. I’m mostly familiar with these in hardware design, but hardware and software development is looking more and more the same these days.
I’m a programmer and agree whole-heatedly with this statement with the exception of the “seem” word. There is no “seem”. We are lousy testers.
I unit test my applications with choice data as stated above, but it would be absolutely impossible for me to fully test an application that I’ve written.
It’s like asking an author to proofread and edit his own manuscript.
Dreamy B:
Do we work at the same company?
I’ve found that as a programmer - and not a business person - that my testing quite often lacks the imagination of those who will use it. Yes, I got my specs from them and yes, I reiterated what it was that they wanted, but they still manage to do things that were not in the original specs or that I didn’t think of outside of the original specs. The code can give me the results I want all day long, but the users will always find something else. 
Afterthought: I don’t view this as a bad thing, nor am I complaining. Hardly. Sometimes a project is very large and has a great amount of detail.
Poor thing. I hate that model because it’s such a waste of valuable technical resources but I’ve seen it in smaller companies where technology isn’t their primary business. Analyzing business processes, creating requirements, creating plans and budgets and handling touchy customers is a completely different skill set that doesn’t require current programming abilities. I’m not sure how a PM with no technical background could do it without driving the programmers crazy, but part of my job was to give them good requirements and get out of the way, send donuts and pizza and let the systems architect and the programmers do what they did best. Often the best programmers were the ones that I would never let near a customer.
Qualification - IANA software project manager or even a programmer by trade, but rather a scientist who often programs as part of his work.
One very nice principle I read somewhere is that you should develop code that does something, and separate code that tests that first code, together. Thinking the two of them through helps clarify exactly what the job of the code that does something is. Of course, it also facilitates lots of tests of certain kinds. In fact, the tester might be written somewhat ahead of the code that does something, which is somewhat like writing the user’s manual first, as part of understanding the task to be done.
Another principle, not from programming, is that it is healthy to have other people study and check your work, including your closest buddies, and other people in your organization, and the customer - especially smart and/or critical people in the customer’s organization.
Based on these ideas I think there’s a first tier of testing that is integral to coding, and a later tier for the sake of all that is rightious and good in making sure you satisfy users and customers. And, because you won’t want that later tier to be the place that many dumb problems turn up, there are probably more tiers in between.
This is how we do it, as well. Testing is always a part of coding. There is more testing after that, however.
Where I work, software starts in the “development” phase and then goes into a “test” phase. The development phase is done entirely by the R&D department, and includes debugging and testing to the best of the developer’s abilities. Internally, with in the R&D department, you can say that the project has finished the “coding” phase and has entered the “debug” phase, but the word “test” in our company means that the project has been handed over to the testing department. The R&D developers are expected to produce good code, so if you hand over something to the test department that hasn’t been adequately tested by the developer, it’s just going to be handed back along with some fairly nasty comments about wasting the test department’s time with code that wasn’t ready for release.
In our company, if Joe said “Hey, I have finished coding the part to arm the Laser-Guided Tracking System!” it’s expected that Joe has coded it, tested it to the best of his abilities, and is ready to turn it over to test. Joe might also say that he’s finished the coding and is moving onto the debugging phase, and it should be ready for test by XXX date. Joe wouldn’t say the project was in “test” until the code was handed over to the testing department.
A developer won’t be handed another project until the project they are working on is in test. Once the project is in test, then it’s understood that the developer may be recalled onto the project to fix some bugs, but the project won’t be occupying the majority of the developer’s time at that point.
[ol][]Nobody, and I do mean NOBODY, can write extensive code that works perfectly the first time.[]90% of all development is testing, verification and rewriting.Does that answer your question?[/ol]
Missed the edit window, so I might add:
[ul][]The best person to test code is the person who wrote it, because he understands how it works.[]The best person to test code is someone who didn’t write it, because he isn’t blinded by closeness to the project.[/ul]