- This topic has 5 replies, 5 voices, and was last updated 9 years, 9 months ago by
.
-
Posts
-
I found this blog post 10 Characteristics of a Bad Software Engineer which suggested ten attributes that a terrible software developer would have.
It was done for fun so it got me thinking, what would the characteristics of a bad software tester look like? I can’t think of any at the moment, I must only know great software testers 🙂
I am sure that are loads to think of though.
What would your suggestions be?@ Ronan,
I like to share my view, may be others add more views to this conversation.
1. Lazy testers – Bugs come from more lazy testers (testers who not ready to write any program & code (unit tests, automation effort) / not understand the application domain & architecture / don’t understand business goals).
2. Certification – Certification’s makes testers more lazy (Certification give extra confident, but that confident is just bubble in air).
3. Mindset – No one wants to be tested for lifetime (flucated mindset / no secure job in industry).
4. Zero effort – (Only one way effort) Automation tester do only automation only and run to home & manual testing do only manual testing and run to home.
Are you willing to do a good job (whatever it takes)?
Do you ask for feedback on your work?
Be certain that you have uncertainties and know how to deal with them?Just as everybody who is doing his work, you have to be motivated and critical on how you work.. Adjustments needs to be made to do the job better.
That should be your drive to do a good job and differs you from a bad tester1- The I found a bug bot. This person stops at the first sign of a bug and directly files his bug report. Don’t get me wrong filing bug reports is very important – how else can bugs be fixed? But a little investigation into the own test or environment could make a big difference in filing VALID bug reports.
2- The I-am-not-a-programmer: I don’t know how to code, I don’t want to know how to code, that is the programmers job. This person does not understand the technicalities of the software under test or the technical implications of the bugs he/she stumbles upon. At best the person behaves like a user functionally looking at the software, at worst the person revels at placing v’s in checkboxes.
3- The I-need-all-the-documentation-or-I-can’t-test: Some people get stuck in the test basis intake steps. They have no imagination and can not just start testing based on the product, code and information from the programmer. This tester believes that the world (or at least the company) will end if not everything is in place before the person begins with any testing activities.
4- The ugly: My tests work, but:
I can not write a decent bug report
Most of what I write boils down to “It does not work.”
There is no investigation.
No consistent testing convention, or reporting convention, or communication.
Bug reports all over the place, etc.5- The short term investor: The person tests. The person files reports. The person moves on. No attempt to learn the product, code or developers. You get tested software but nothing more is achieved. There is no knowledge added to the team.
6- The protester: The code sucks, the test plan suxks, I can’t do this, let somebody with more technical, domain, or any other knowledge tackle this. I hate this (ten times an hour).
7- The dictator: My way or the high way. It’s their “ideas” vs “your ideas”, not “project ideas”. It’s their solution vs your solution. I bet there will be an argument for sure. Somehow they will keep coming back to a test that you performed. This person is a big bottleneck to productivity and will be the first person to crumble under pressure and start pointing fingers. This person is not good for the team, however experienced/good a tester he may be.
8- The overcautious: The testers that freeze if not all requirements are set in stone. The tester that panicked when learning that not all documentation is available. The tester that cringes at not having 100% coverage (code-, functionality-, or anything else). These people will do anything to avoid getting out of their comfort zone. Good testers show a tendency to slowly/swiftly move out of their comfort zone in exploration.
9- The careless: Forgets to take a backup, snapshots, can’t reproduce bugs etc. This is a newbie tendency and gets better with more professional exposure.
10- The lazy software cracker: They pride themselves at using the latest tools and methods to test complex software. “This fourth generation, behaviour driven, automatically self testing software tool will solve all our quality problems!” 99 out of a 100 times this is a pose. They will invest a lot of time in getting the tools / environment ready and then it does not work without a lot of new investments. Getting the software ready and tested will cost much more than having tested it right the first time.
@kasper That’s a great list. I think a lot of these attributes could be applied to most jobs. I had never thought about the “Over-cautious” tester before but it’s a real valid point.
@Kasper what a great list! and I totally agree!
I have also encountered the self righteous tester. Meaning a tester who assumes just because they are a tester they should be respected. You have to earn respect from your colleagues be it tester, developer, product owner, sales person etc.
Also this sort of person cannot communicate in a positive way and thinks their bugs are the most important ones even if the Product owner has prioritised them according to the PO’s needs.Anyway rant over 🙂
- You must be logged in to reply to this topic.