By James A. Whittaker
"Testing is boring." Don’t pretend for a moment that you’ve never heard a developer, designer or other non tester express that sentiment and take a moment to search your own soul for the truth. Even the most bigoted tester would have to admit to contracting the boredom plague at some point. The day-in, day-out execution of tests and the filing of bug reports simply doesn't hold the interest of most technical people who are drawn to computing for its creative and challenging reputation. Even if you find yourself immune to the boredom, you have to admit there are many monotonous and uncreative aspects of testing.
It doesn’t begin that way though. Early in a tester’s career, the thrill of the bug hunt can keep a tester going for many months. It can be as intoxicating as playing a video game and trying to find some elusive prize. And lots of progress in terms of skill is made in those early years with testers going from novice to pretty good in no time flat. Who can argue with a career that offers such learning, advancement and intellectually interesting problems?
But as the achievement curve levels out, the task of testing can get very repetitive and that quickly turns to monotony. I think, promotion concerns aside, this is why many testers switch to development after a few years. The challenge and creativity gets eclipsed by the monotony.
I think bored testers are missing something. I submit that it is only the tactical aspects of software testing that become boring over time and many turn to automation to cure this. Automation as a potion against the tedium of executing test cases and filing bugs reports is one thing, but automation is no replacement for the strategic aspects of the testing process and it is in this strategy that we find salvation from this plague. The act of test case design, deciding what should and shouldn’t be tested and in what proportion, is not something automation is good at and yet it is an interesting and intellectually challenging task. Neither is the strategic problem of monitoring tests and determining when to stop. These are hard and interesting strategic problems that will banish the plague of boredom. Testers can succumb to the plague of boredom or they can shift their focus from mostly tactical to a nice mix of tactical work and strategic thinking.
Make sure that in your rush to perform the small tactical testing tasks you aren't dropping the strategic aspects of your work because therein are the interesting technical challenges and high level thinking that will hold your interest and keep this plague at bay.
I mostly agree, except for the title: Boredom isn’t a plague, it’s nature’s way of telling you that you’re not using your head. Perhaps I’ve just been lucky in having enough test autonomy to be able to dodge this plague, but I think a good methodology which avoids some of the other plagues (e.g., the false sense of thoroughness and premature automation) will also avoid this one. As you’ve noted elsewhere, you’ve got to avoid automated testing as a complete substitute for (rather than supplement to) manual testing. But you need to avoid the other extreme as well, and boredom is a clue when you’re not.I confess that my test approach is often more a craft than a science: Get to know the territory, keep an eye out for bugs that you notice in normal use, and an ear out for complaints from other users. Then figure out a process which would have found those bugs, generalize it, and automate it once it gets boring.
I couldn't agree more.It is very frustrating to see bright guys getting off to a great start in testing and then, after a year or two, getting completely disillusioned about it. I personally know of many test engineers who sought escape in either development or automation. I recently interviewed more than a dozen candidates for a senior QA position. I was very disappointed to see that many of them took pride in how they learnt some automation tool on their own, or how they solved some very specific automation problem. Very few of them seemed to have given serious thought to the tests they were automating - about how one would design them so as to minimize the number of important bugs that reach the end user. I DO understand the importance of automation, but I think it is a tool to achieve the goal and not the goal itself.Yes, the strategic aspects of testing ARE very difficult, but I don't see why we, the QA community, should give up on it.
I have been a Developer since years and then moved to Testing/QA. Just because I love it. No wonder you get bored, if your Job as Tester remains there where he/she started, clicking on GUIs, filling up Reports etc for weeks or even months months.I just dont understand why Prashant is so frustrated!! When Charles Babbage invented the mechanical Computer he just wanted to bring down the errors in calculating and save people from the same boring job of counting using Pen, Paper and logarithmic tables. So, if you come across the same tests almost every day, then you should automate it. The benefits are: 1) Lesser Manual errors caused2) Requires lesser Testing/Release time3) The tests are repeatable, can be even used as Regression Tests later4) The Computer now does the "boring job", the Tester can concentrate on other Assignments or dig deeper into other complex Problems.I first start testing manually. Then I use my skills to automate every possible Tests with suitable tools, skripts or any Programming language. Periodically I inspect my Tests and Results/Reports and tune them. When a new Problem is found, I include that case in my Automated Tests. In this way the Quality of the Software we as a Team deliver improves every day. And everything starts to become "green"!! And it really motivates me to do more. After all, Testing is not just finding loads of bugs as fast as you can and scapegoat the developers for all that "bad software". It is all about improving the quality of the software system as a Team. Last but not least, it is the Job of the Test Dept. Manager to motivate the "bright guys" and show them that he/she can really learn more about all the different facets of QA and the processes every day. You did'nt opt to work in IT to do same routine work every day!! Its the same case with Testers also.
Any job as a matter of fact will lead you to same feeling if you are following same process every day, no wonder there is a term called "rut"If QA Engineers, QA with set process and they are tend to get bore, no question about it. To avoid this I give my engineers enough lead to do exploratory testing and do not stress on writing test plan in initial phase of any tests, I know I will be contradicting with many people, but that's fact, if you want engineers to break it and say," let me see what happens" then you are half way there as well as you are keeping testers interest in the game.Now to avoid rut, definitely we have to avoid repeated procedures by making use of flexible and light weight automation. Keep giving team members ownership and freedom to work on their component, coz with freedom comes responsibility, which keeps no room for boredom.
Testing is not (only!) about finding bugs or improving quality - where maybe the thrill of hunting gets lost over time - it’s about measuring quality. Think about those QA people who check aircrafts, cars or buildings. They won’t directly improve the quality of their project, they will inform the project what’s the actual status of the application under test. That’s what they are there for, to bring (all) positive or negative aspects to light, so that the project can stir into the right directions, based on their reports and results.So the defect as such is just the instrument to harden your judge, and it’s the team's job to bring the defects to light, but never forget to focus on the big picture which is “testing” with all aspects. On the other hand it can’t be that boring nowadays, because with our tight resources, especially within test, there is not much room for a lot of redundancies or maybe a high demand in changing test strategy to fulfil new requirements to softwaretest.Further, boredom is in my opinion a subject which hits every unit during the software development lifecycle, especially the developers. Think of recurring code fixing, always the same class which won't work after each release - bad QA guys throw the release always back to me.. :).Or simple maintenance bug fixing. It could be very frustrating to jump back to the "old" project over and over again to do fixing - and stop your creative process in the new one... or some would say… boring…When I talk to "creative" developers, they always bring the documentation topic, which they find very boring... (being highly creative in their coding one the one hand and comment or write it down on the other hand - some kind of stopping their flow – always writing the same preformatted text, the same diagrams and graphics..).So I think boredom hits every person some times (also don’t forget the subjectiveness within this topic), and it should be a chance (as said in the comments before) to start thinking into another direction to prevent it from frustrating you and as a consequence hopefully improve your doing on a daily basis - cause no one likes redundancy.
The comments you read and contribute here belong only to the person who posted them. We reserve the right to remove off-topic comments.