- This topic has 12 replies, 12 voices, and was last updated 7 years, 3 months ago by
.
-
Posts
-
Confession time:
I am bad at functional testing.
Don’t get me wrong – I can read the specs and write test around them, but I am interested in the inner workings of a system and I get bored only tweaking input to look at some output. When I am bored I am not as good as I should be and consequently I take longer than I have to to complete the job. I take longer because of my exploratory excursions, on the fly automation and my incursions into the code, especially triggered by events that raise my interest with respect to my chosen field of security.I can’t do all testing. Since I am writing this in a terminal on a heavily personalized version of Kali Linux using Vim you can count me out if usability testing is on the table.
I can root my phone, install another OS and tweak it to my liking but I have zero experience in testing mobile apps.
I am a fair scripter and I have a descent understanding of databases but even so
I am not the best performance tester around.I am good at understanding (and sometimes writing) Java, Python and Ruby but I have only a passing knowledge of .net and the Microsoft universe.
I have a dislike for the latest buzzword in testing. No matter what the buzzword is. I don’t believe in test driven design, risk based testing, Agile testing or whatever the latest buzzword is.
I do believe in professionals doing their job. PERIOD.
The can do all universal enveloping testing theories are just that, theories that won’t survive in the wild wild world of connected applications – unless constantly supported by a group “believers”.
For me doing my job is making sure that the programmers are following the agreed upon coding standards by properly configuring static code analysis tools and performing inspections.
It is checking dependencies for known security issues.
It is performing tests based on knowledge of the requirements and the code and doing so in my way – including all the excursions which lead to a lower percentage code covered per time unit, but a higher rate of bugs found per time unit.
It is coaching more junior testers in not only testing theory but also relevant technology, tools, programming / scripting languages and even how to do a meeting or a talk.
It is making sure I stay up to date with relevant developments and adapting strategies and tactics when (not if) needed.
What is your job description?
OYE – HA – this is a good one! Can you be an excellent tester and hate functional testing? Yea, I think it’s totally possible – you’re more motivated to do things thoughtfully and productively. I’ve found the most bugs because of exploratory excursions in a “what if I play with this for a while” attitude. Why not!?
My Bad Tester confession (Basically take @Kasper’s EXACT list and add the following):
— I can be vastly too literal in my assumptions. I don’t ask enough questions. I don’t peel the onion enough. I get comfortable with a UI and overlook minor defects in my aggressive hunt for the big deep scary ones.
— I lay awake at the end of release day knowing I missed something. Just what!?
— I can disseminate a database comfortably – it feels right. Ask me to do a custom select left query with a join on a table with a calculated column – and I stall. (Google…oh Google where are you!???)
— I can write simple C#, but ask me to do a method peeling apart collections of check-boxes buried in a group control… and I get heartburn. It will be painful. Requires a lot of chocolate. Maybe even pizza.
— My team is working in layers of the product that has a language of its own – leaves me in the dust sometimes. I read the code, I use a lot of google, I ask a lot of questions. I suppose I would be a better tester if I just knew what the bleep they were talking about sometimes.I read a job description last week that asked for demigod skills (I could swear I saw something about a throwing lighting skill set) – were I to apply – I would be torn between a teary sobbing emotional confession like above – or just clamming up hoping I’ve got the chops to fake it till I make it. 😉
NOW – I’m a strong believer in enhancing one strengths – and not focusing on one’s weaknesses, because it’s your strengths that will move you to where you should be. So despite all of the above – you can tack the second half of @Kasper’s list here too!
I will add this:
– I believe in learning. On the day I die, I will be found keeling over a book or computer in the process of learning something (probably with chocolate in one hand, and pizza in the other. Are there any other food groups?)…. After retirement – I’m thinking of geology maybe. It’s a deep subject.
– I believe in the credibility of my own word. I don’t second guess myself – mistakes are a part of life. I DO ask questions, and always always follow my first bullet.
– @Kasper – you said it lovely: Professionals should do their job. PERIOD.
– After that it’s very simple: “How can I help you?”This is a fun topic.
Hi I’m Jesper and I’m a bad Tester..
I’m not very detail oriented, nor do I want to break stuff,
.. while there is value on the traits above, I prefer
to see the big picture and I want my customers to succed.My name is Craig and I am a bad tester.
I can’t code
I don’t have a strong knowledge of the technologies in place
I get dragged into commercial processes too often
I prioritise project demand over personal development
I don’t get the necessary buy in from stakeholders to move the test service forward
I struggle to hide my frustrationOk, here I go too, confession time: I don’t like testing at all
(unless its in a cool way where things get so complicated making me feel like a real hacker, find critical issues, people loving me and get rich at the same time. But, its usually not).All driven by laziness, this is why I automate the sh*t out of testing.. So machines can do it for me, and regressions can be found as close to the source as possible.
I truly believe in Test Driven Development (Behavior Driven, even better), but only with the right people, in the right environment (call it ‘Agile’ , if you like) and I think it’s the only way to go when continuous delivering value to your client plays a key role.In my opinion, there should be no barrier between a tester and a developer. As an activity, testing therefore isn’t much different from developing.
Something I noticed over the years, not all people who ‘develop’ are good testers and not all people who ‘test’ are good at writing code.
But, in my opinion, a good developer, is only a good developer, if he knows how to do both.
Same goes for a good tester, if he can’t automate properly, that means he’s probably either doing a lot of manual work (doesn’t scale very well) or spending a lot of time figuring out his own test scripts. So why even distinguish between those ‘who make (or break)’ and ‘those who test’?I think this attitude makes my job more fun, it costs me a lot of energy sometimes convincing people who aren’t as lazy as I am, but because I tend to do things only once, I’m able to focus on the things that I find interesting, and hopefully, truly hopefully, one day, my computer will think of good tests and execute them for me..
Lennart, if that day ever came we’d not need developers or indeed any human involved in software development. We’ll have automated coders before we have automated testers. I remember the launch of “The Last One” in 1981 which was meant to make programmers obsolete…. still waiting.
Perhaps a different topic, but I think its going to a level where creativity is more important then knowing how a computer works internally (programming).
Seeing how easy it is for people to create their own webpage or app and the huge steps made in programming languages since then, testing tools and methods, I say we’re getting there, although slowly..
I just start by aiming to automate myself as much as I can 🙂Hi I’m Jesper and I’m a bad Tester..
I’m not very detail oriented, nor do I want to break stuff,
.. while there is value on the traits above, I prefer
to see the big picture and I want my customers to succed.tisk tisk 😀 break stuff 😀
I’m great Because i have terrible attention to details (typos n stuff) and i’m terrible at fallowing orders exactly 😀 this is how i finds what’s not nok, what’s not making the bigger picture clear and reasonable.
To me testing is a way to contribute to the team so by the end of the day what we create is better fitting the needs of the users and we can have pride in what we’de done as a team.i feel destroyed and discouraged when major issue hits live (even if there was nothing i could have done to prevent it with the knowledge i had.
I feel bad – when i’m blocked by environment, project, product,people who matters when they want it NOW but haven’t made up their mind up on how exactly it should work and what problem it will be solving.I like testing – there are just bunch of things that make it harder for me to keep at it and feel happy abut it
-^. ^=-
~~ ~~Hi, I’m Jerry and sometimes I do a poor job of testing.
Why? Because I’m impatient (and cowardly).
I often don’t have time to do it right, but I always seem to have time to do it over.
And when I keep seeing the same type of error over and over, I want to scream.
What I should do is take the time to get upstream and see what can be done to prevent another instance of the same error, but I often lack the patience (or courage) to talk to other people about these problems..
Interesting topic.. I am bad at automation. Though I have experience in Performance testing tools, I never made an effort to learn any automation tools for functional testing.
After manually testing the basic functionality i prefer to automate my work as much as i can to catch the unforeseen bugs.
Perhaps this forum might be interested in a webinar on ‘Leveraging Visual Testing with Your Functional Tests’. The main objective of the webinar is to share how visual testing can be utilized to extend your functional test coverage.
It’ll take place on the 20th September and it will be presented by Peter Kim.
- You must be logged in to reply to this topic.