Another surprise today: 2 testers who were online, pinged me to say that they were doing a monotonous job. When I questioned them I was excited with the work that they had in their hand.
Take a look at one of the conversation:
tester_a: upgrade testing is awfully boring
pradeep: upgrade testing, what do you mean by that?
tester_a: testing upgrade of a product from older to latest version
pradeep: wow! It's exciting
tester_a: what would make it exciting?
pradeep: Thinking of what kind of update issues, the product or users might face
tester_a: there are no issues. it either works or doesn’t. its not scenario specific either
pradeep: ok, let me give you a list of tests that I might want to test, if I am asked to find important problems quickly.
*What bores a tester always interests the user*.
1. What if the product while it's getting updated, is hooked off the network?
2. What if an update file is corrupted?
3. What if an update file is infected with virus?
4. What if an update file for a specific platform is fed to another platform?
5. What if your reboot the computers while it's updated?
6. What if the server is reset while a client is updating?
7. What if an application on a client interrupts the update?
8. What if an upgrade fails? What more problems could be hidden with it?
9. What if an auto update and a manual update is attempted in parallel?
10. What if software is attempted to uninstall when an update to it is happening?
11. What if more than one method of upgrade is initiated from the same client with different instances of the application?
12. What if there is an upgrade of the platform happening while the product update occurs?
13. What if the resources required for the upgrade platform are squeezed?
14. What if the update file has wrong information in it?
15. What if the file date is changed to a date than the current version yet it has the latest update?
Now, doesn't that sound creative work?
tester_a: doing it on 45 platforms with 7 different ways = 45*7 might not be interesting!!!
a single platform ? Yes sounds "WOW" :)
pradeep: well, let me explain, How I would strategize...
Perform tests on one platform, first. Note the important problems. Look for similar problems on other 2 platforms. If they are serious problems - report and disqualify the build/release/update/whatever?
I would also negotiate with my manager for another resource or two who could help in getting this done effectively by saying, "I fear that any tester to my knowledge might find it tough to do all of that"
If you have been given time, its better you do it with passion.
*The company never thinks it is doing a monotonous job of paying you salary , every month!*
tester_a: lol that was a good reason :)
pradeep: Here is something that you might want to think: Soldiers are asked to work very hard even when there is no war. If they think it's monotonous and quit the job, we die at enemy's hands. There is a soldier guarding you somewhere, far away, and you better not call anything monotonous.
pradeep: Isn't that true?
tester_a: it’s a debatable topic
pradeep: ok, I suggest you debate with yourself on that.
Why is testing monotonous? The unspoken truth!
- It's made so by testers who *might* not be able to think or be creative.
- It's made so by testers who *might* be lazy to run those tests.
- It's made so by testers who *might* have not learned something that they could apply to the work that they do, to see a different result.
- It's made so by testers who *might* lack passion to test.
- It's made so by testers who *might* want to jump to development and needed a reason that others could accept.
- It's made so by testers who *might* not want to try any new test other than the script that they have been given.
- It's made so by testers who *might* want a reason to jump to another job.
- It's made so by testers who *might* lack motivation to test.
- It's made so by people who *might* be claiming themselves as testers but aren't.
- It's made so by testers who *might* not have skills to find bugs.
- It's made so by testers who *might* claim to know testing after knowing definitions and terminologies without knowing how to apply or practice them?
- It's made so by testers who are promoted as a test lead and *might* be happy thinking, "hurrah, no more test execution" and go completely wrong with their career in testing for thinking that.
- It's made so by test managers who *might* not want to allocate more resource for a huge task and yet get it done with a few testers sacrificing the quality and value.
- It's made so by testers who *might* want to do exploratory testing but are stuck in scripted approach.
- It's made so by testers who *might* be doing tasks with same mistakes.
- It's made so by testers who seek guidance from a person who claims to be a tester and who doesn't know much about it and yet offers great advice to his junior to learn tools like QTP, Winrunner, Load Runner, Silk... to get out of monotonous work. ( Actually, running tools for a life time and being a toolsmith and yet claiming to be a tester, is monotonous)
- It's not testing that is monotonous, it's testers thinking that is monotonous.
- It's made by testers who monotonously say "testing is monotonous"!
If you experience monotony, you aren't questioning. If you aren't questioning, you aren't testing.
( A couple of days left before the registration *might* close for an exciting workshop on testing skills. Look for the announcement in the left top corner and register before I start saying, "Sorry" )
-- Pradeep Soundararajan - firstname.lastname@example.org - +91-98451-76817
"Pradeep's first language is not English--his first language appears to be testing." -- Michael Bolton