August 5, 2008 at 10:05 pm
Comments posted to this topic are about the item Testing Testers
August 6, 2008 at 12:27 am
Testing is very very important phase. We have a dedicated team of testers who test the application from various angles. We have buid our testing team from various fields. We even have DBA in our testing team so that we should have a foolproof application. But I don't know how bugs still reported to us by the client. It is very difficult job.:)
August 6, 2008 at 2:17 am
Once again, an editorial making two points, and both good ones too.
Regarding testing, it's certainly an art rather than a science, since by definition you're trying to find the unexpected, so best practices are hugely helpful to share round. However, it's also a trap to think that if you're following best testing practices, that your testing processes are good one, since you may be following excellent processes that are simply irrelevant in certain areas. Once again, though, that is another reason why spreading the knowledge is a good thing.
Regarding adding value, I couldn't agree more. Doing your job as a box-ticking exercise is ultimately unrewarding and inefficient. Doing your job so it helps others do theirs more effectively is the epitome of teamwork, and the rewards are exactly the same as you might expect being part of a highly cohesive football or rugby team. As well as being successful, everything feels "right", and everyone feels a satisfaction from being a useful part of that.
Teach someone to fish, indeed.
Semper in excretia, suus solum profundum variat
August 6, 2008 at 6:37 am
Thanks Steve, for pointing us to yet another very interesting and very useful article.
___________________________________________________
“Politicians are like diapers. They both need changing regularly and for the same reason.”
August 6, 2008 at 7:02 am
Along with having qualified testers is having a good testing methodology and philosophy. When I started here our QA groups idea of testing was functionality only. This constantly bit us up in support with performance issues and application anomalies. I have still not convinced them to do heavy regression testing and try paths other than the expected path to break the app but they do some bandwidth and performance testing.
How qualified is qualified? Should QA people be developers\dbas? Should they be people who can follow scripts but not troubleshoot independantly. Should they be outside entities that do not report to development or product management? In my opinion the QA group needs to be a good mix of backgrounds allowing them to find and poke as many holes as possible in the application. They also need to report to a seperate entity than PM and DEV so that they are not pushed into releases for financial reasons. They need the autonomy to do a good job instead of just go through motions.
August 6, 2008 at 7:35 am
Timely post as we are testing a new release on Saturday - beginning to test I should say. I will work until my eyes glass over and I forget my kid's names, then testing will continue on Monday and on, until the next release. It never ends.
August 6, 2008 at 9:30 am
Great article.
I find in my own realm of the IT industry, testing is derived from a standardized form in which I'm supposed to estimate the exact path(es) to test and how to test them. More of a sign-off to the sales department than actual testing, and surely not a good measure of a solid application.
Teaching someone to fish is an interesting thing - like testing, teaching the motions is easy, but teaching the philosophy behind fishing or the skillset required is impossible. Perhaps some people weren't meant to fish, or test.
August 6, 2008 at 9:45 am
With regards to teaching someone to fish...we recently started have weekly peer reviews of some aspect of our work. I work in a development department with a total of 8 developers. The meetings last one and a half to two hours. The department lead picks the topic for the week. Everyone brings their own solution that is relevant to the particular project they are working on. This has turned out to be a fantastic system. There are some junior developers with 25 years of experience and everyone learns something new. You may learn some new technique or some new feature of a tool you didn't know existed before. It also provides great opportunity to discuss and debate best practices and approaches to problems so the department as a whole becomes much more productive.
August 6, 2008 at 11:11 am
Years ago, I had a brief consulting job to be QA/tester on small implementation. Over and over the programmer would hand over program saying "no bugs", and of course the first or second keystroke, it wouldn't work. The programmer was shocked and would immediately pop over to say "whaaat? what did you do?" No matter what I had done, the response was "well, don't do that". It still amuses me. 🙂
August 6, 2008 at 4:35 pm
It can be very frustrating when a tester finds problems with your code but I prefer this to having to release code that only I have tested. Developers tend to test their code the way they intend it to be used and will miss problems caused by "misuse". I believe that a good tester is worth their weight in gold to the developer. It can really help you see where your skills are lacking, whether that is in working out the logic, writing the actual code or interpreting the specification (hopefully there is one!).
Asking the tester's opinion of a developer's skills/progress may be very helpful at review time. It can also help to indicate the developer's soft skills. It can be hard to have someone rip holes in what you thought was well written code!
Nicole Bowman
Nothing is forever.
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply