But programmers need to test too. I’m not talking about implementing Unit Testing or executing a script to exercise their functions, they’re already aware of that. They also need to test their functionalities interface. In other words do some black box tests. And why, you may ask? Obviously because it’s absolutely unreasonable to deliver a product to test that doesn’t work at all.
I got to introduce this measure for more than a year ago, but they still don’t do it right = don’t do it at all… The Dev manager makes them sign what they deliver but he himself doesn’t do it!
So imagine that we tested a setup today and when I tried to use my application one of the services didn’t work at all. The programmer tried to do the smoke test but since he slipped his deadline didn’t remember on time. That version included some rework on the services so the services should be tested…
You don’t compare black box tests done by programmers to black box tests done by testers, but they have to see if their interface with the user works…
Mistakes like buttons that aren’t linked to the methods, wizards that don’t finish… All that shouldn’t happen in tests environment, should be prevented by programmers!
And you might say, “Isn’t that testers work?” For that question I have the answer, there are bugs that are inadmissible, like when the programmer creates a new window and the button OK doesn’t work and it is much more expensive if this problem is detected in a release candidate by testers than by the programmer before the builds.
The problem often is that the developers have a deadline to meet to get the code into testing and they are measured on meeting that deadline, not the quality of what they deliver. This means that shortcuts are taken when the time is tight.
You might say that measuring developers on time and quality would, therefore, be appropriate and to some extent that is true (although more difficult). In many shops, however, if the developers are late, then the testers start late and they get squeezed. As always, there needs to be a compromise and I am happy to work with the developers to assist them when time is tight and I might take the conscious decision to take a piece of code that has not been fully developer tested to do that. The decision is always contextual and situational.
We are trying to introduce presentation meeting for code. Basically developers, QAs and managers are going through application together and most of the obvious mistakes appears immediately.
Why not try to introduce some pair testing? If the Developers have Smoke Tests already, or something they should be doing hopefully with input from you, why not take some time to help them out near the end of the Dev cycle? It gets you a chance to check out other changes, and makes sure that the tests are accurate and being done. It's helped me in more than one case.
Shouldn't an example of all required functionality be a requirement for release to testing? I know that this is not generally done, but if the developers cannot demonstrate a system that at least addresses the requirements, why do we give them credit for "delivering" code? (I accept that it may not work right, but it should at least LOOK like the work can be done).
This is much harder with gui based apps but as we learn how to write testable apps we should be able to demonstrate that within a very limited range of input that the application can function.
Peter, I don’t say you can’t help developers on their work but be aware that your programmers don’t get lazy only because they have the test team to save the software… I saw this happen!
mferris, I think that what you do is one of the many measures that can be applied to prevent mistakes and prevention involves lower costs and better quality both for dev and test teams
Michael, we did introduce a smoke test for them to do according to the type of change they do. However the check list, documented, wasn’t approved by dev manager, who says a signature is enough. Well it isn’t, sometimes they still deliver things without even trying the interface they have just created…
Whollymindless, requirements are tested, deliveries are intended to meet requirements, so QA always spend time rising what and how to test.
You can also use techniques where you design requirements as tests before programming, this is related to Agile.
