I think it's rather sad that more programmers don't like testing and test designing. While I don't feel
especially thrilled about learning about test design per say, I do
like running tests on things to make sure they work – whether they
be things that I'm going to be graded on or things that I'm giving
others to use. Not only do I want the grade and I want others that receive my help to agree that I helped, but I have a sense of pride
when I work hard on a program. Testing is vital this to make sure
that it meets requirements – and who doesn't get a ping of pride
when a test, especially a rigorous one, is passed by one's creation?
I don't feel guilty when I test and make sure my creation works. I
don't feel guilty because I know I may have messed up – I know I'm
not perfect, and scoff at those who think they are.
I was intrigued by the notion of using
testing to prevent bugs, not just to catch them. It seemed foreign at
first, but after a thought this seems to be tied closely to
test-driven testing, and not so unfamiliar.
I enjoy how he broke down the "phases
of thinking" on testing. The fact that it's impossible to test
to show that software works is an important thing to remember and
should be stressed more. Similarly phase two's objective of "show
the software doesn't work" is also an infinite war between
testers and coders, though at least it gets us farther than just
trying to prove that it does work. Phase three – to reach a certain
degree of quality – is probably as far as most companies go. I
somehow doubt that most companies try to get their testers to do
further research into testing as a discipline – they probably just
test their things, assuming they having any dedicated testers at all.
Though I didn't particularly enjoy
re-reading, say, the definitions of an ORACLE, it's good to know that
things that I've been taught are also mentioned and important in real
applications.
No comments:
Post a Comment