- This topic has 20 replies, 11 voices, and was last updated 8 years, 4 months ago by
.
-
Posts
-
Everyone is new to testing once and has to start somewhere.
Like all careers, it is a matter of adapting to the role and figuring out how it works. But as testers come from many different backgrounds (not just I.T.), I wonder are the errors that new testers make still the same?
Ones that I have come across before include:
Not checking for changes to the test cycle
Submitting bugs that have already been reported
Not reading all the documentation
Would you have any other to add to the list? Or what were the mistakes you made when starting out as a tester?
Assumptions – it’s very easy for new testers (and even experienced ones) to make assumptions about the product, the environment, the OS, the users, the ultimate goal of the software etc. Only when we’ve been burnt by assumptions, do we start to realise the importance of questioning everything.
Communication – new testers need to build up their communication skills. They need to be able to accurately communicate the severity of bugs to their stakeholders.
Confidence – this follows on from building up communication skills. New testers need to have the confidence to argue their ground if a serious bug they have raised is being disregarded or belittled by stakeholders. Obviously business needs should be factored in, but a new tester shouldn’t be afraid to argue their point when required.
When first starting out, I think I made all of these mistakes, probably on more than one occasion and I think you’re right to point this out, even to seasoned testers, as we can all get a little blasé at times and it would be dangerous to assume that we are incapable of making them again.
Thanks @jenowen for your thoughts. I would guess that Assumptions would probably be one of the biggest errors that new testers make?
A good suggestion for seasoned testers to be aware of these too. Do you still see these mistakes being made by seasoned testers?
Confidence absolutely @Jenny.
A common error is not to stand the ground on the findings. For instance if the finding is rejected (https://huddle.eurostarsoftwaretesting.com/forums/topic/have-you-ever-had-bug-reports-rejected/) Speak up about what you find 🙂Testing everything
Everything is not equally important – so keep an eye on the mission / scope.Factor in personal beliefs:
I sometimes see this when SME’s from the business participate in testing (they often do, and rightfully so). Like writing “This is unacceptable, there is many broken links”. But really they fail to realize that the links will be provided later. Their deep business background makes them experts, but sometimes they fail to see the bigger business picture. So reframe the report into “as a user, given, when then…” and triage the findings with the rest of the lot.….We all do this really, but we can be aware about it.
Common errors I find as a new tester is my self expectation to know everything about the product and how its set up straight away. As a result I added more pressure and tended to be very hard on myself. It has taken me a year to realise its OK not to know everything about the product, this comes along with time. When I look back on what I was asking as a tester when I first started compared to what I am asking and testing now, I can see the growth, I can see how far I have come along, I can see how much more I understand the product. Patience really is a virtue and a good working environment. 🙂
Hi Ronan,
As a new tester there are some things that might conduct to some general errors:
– Prioritization: it might be very hard for a new tester to make a difference between all the items that will be tested. Generally, the testers are trying to test everything but this is not possible in practice because the time is limited. Instead of trying to cover all features, they should focus on some aspects like importance, impact, scope etc. and prioritize the tests. Sometimes it happens that the testers feel the pressure while working just because they want to test everything and they see the allocated time is not enough to do it.
– Communication: testers find bugs but sometimes reporting them is not very easy. The new testers tend not to include in reports all important information or might not describe in an objective / neutral way the issue found. It is important for the new testers to describe the issue in a proper way by presenting all detailed information like workflows, environments, user data etc. and avoid any assumptions and personal feelings.
These mistakes are avoided in time when the testers gain experience and understand how they should do their job in a better way in terms of efficiency and communication.Regards,
AlinAn interesting discussion topic and I would assume that most new testers will experience similar issues for example lack of knowledge/understanding of AUT/SUT and I have to agree with @Jenny and communication being key for a tester. For me a tester has to get closer involved with teams working alongside development to gain that improved understanding, this should hopefully help to reduce issues that @Ronan first mentioned like duplication of bugs being raised.
Also agree with @Alin that learning prioritising is imperative for a tester. Being a keen new tester you’ll no doubtably want to test everything but of course time will always be the restraint. Learning how to prioritise test plans and regular involvement with stakeholders will also help to prioritise test plans.
A tester should never be afraid to make mistakes, so long as they learn from them.Send email to wrong people
Test the wrong build
Report the invalid bugsThere are more but those are common to me 😉
– testing the UI too early in the dev/release cycle
– making invalid assumptions about product behavior
– assumption that you’re testing incorrectly, or doing something wrong if you run across something weird
– ignoring and not reporting weird things because someone told you that it “wasn’t important”, or that “it always happens that way”
– feeling guilty when you find something
– apologizing when you find something
– worrying that you’re not testing good enough when you’re new
– letting someone else tell you how to test (you have to learn this, being bullied into a testing method is not helpful to anybody) and to ignore your instincts
– (as a beginner) not writing down test strategies
– not talking to your developers
– not asking for code demo’s
– losing track of the core goal of your testing (“what” are you testing!?) – and getting lost in the weedsThere are so many – but these are some of the ones that come to mind…
So many great points above.
As a new tester, you might:
– Expect things to work. (That will wear off pretty fast…)
– Do a “Developer’s test” (Does this work?) instead of a “Tester’s test” (How can this fail? Wonder what happens if I do like *this*?)
– Be afraid to ask questions or assume things.Many good points above, especially re trying to test everything and feeling that you’re expected to know everything.
I believe these converge on one problem, which is thinking that you somehow are responsible for quality.
Your job as a testers is to use what you DO know, and your creativity & imagination to think of how the software may fail, and what the immeduiate consequences might be.
You’re not responsible for ensuring quality (though your work contributes to it). You can’t be expected to know all of the downstream consequences of failures.
You have to think clearly, methodically and rationally, but also imaginatively. You have to be very clear on what methods you’ll use and record carefully what you did.
This is so that someone else can determine the impact of the defects you do find, and then someone else can also fix those deemed worth fixing..
Ultimately someone else will decide to release/launch/deploy the software you tested – they need good information to help THEM make that decision. You provide an imprtant part of that information, but not all of it, and you DON’T make that decision.@paulcoyne73 – great points too!!
It’s a bit of a thin line – which is why you should always document what you do (with judgement) – and report what you see, even if people disagree with you. Finger pointing is an unfortunate side effect of those kinds of expectations.
Red,
not sure what kinds of expectations you mean. In my many years of experience finger-pointing very often arises when people aren’t clear about their roles. That’s why it’s so important to be clear on the role of the tester.
Documenting what you do and recording what you see (accurately and dispassionately) are absolutely key – hence my statement “You have to be very clear on what methods you’ll use and record carefully what you did.” I’ve seen some inexperienced testers whose idea of a defect report was “I tested the X function and it didn’t work”.Ah – sorry I wasn’t clear.
In my past I’ve been in companies where anytime some incorrect behavior escaped to production – it was a knee jerk reaction to point at QA and ask “Was this not tested?” That was the (company level) expectation, that can cause a new tester to become discouraged, or actually assume that responsibility.
By creating documentation on your test efforts (even just a simple list of actions, or test strategy employed) you will have some level of justification that you did or did not test it. The second part of that – is to get the teams to buy into your efforts.
By asking for buy-in (of that test document, plan, list or strategy)by the dev team and/or product owner, before it is executed: the ownership of the problem falls back to the product owner, and/or team… not the tester. They cannot – at that time, and in good faith – point at the tester as the source of the defect escape – because the entire team participated in the process.
New testers sometimes don’t know how to do this.
@crt42,
I agree, and I can assure you those organisations still exist!
Isn’t it funny how the question is never “why was it designed & built this way?” I know that’s slightly flippant, but really – that’s the “mental vocabulary” we’re dealing with..
This is why I’m so keen to make clear that the tester doesn’t decide to put the thing live or on sale. That’s some else who decides, and we help provide them the information they need. Naturally we can still screw up, and we do – we are human. Unfortunately the knee-jerk reaction to that sort of comment is “you’re right – let’s automate” which is a facepam of epic proportions!Ah – sorry I wasn’t clear.
By asking for buy-in (of that test document, plan, list or strategy)by the dev team and/or product owner, before it is executed: the ownership of the problem falls back to the product owner, and/or team… not the tester. They cannot – at that time, and in good faith – point at the tester as the source of the defect escape – because the entire team participated in the process.
New testers sometimes don’t know how to do this.
@crt42 Interesting thoughts there. What do you mean that new testers don’t know how to do this? Is it to argue that incorrect behaviour may not be the testers fault for not testing or that they should be keeping test plans and getting dev involved in this?@Ronan – HI!
I believe that new testers don’t know how to get buy-in/acceptance on testing plans. Getting an entire team to buy in on what they intend to do – takes time and a little bit of guts… it might not be the culture where they work – so they’re introducing new ideas. Or they’re afraid to speak up, not confident about their ideas. Or they really don’t know how to put together their ideas in such a way that other team members would understand.
The purpose of getting the team’s buy-in is multi-fold:
– The entire team(scrum or dev team) understands now what acceptance criteria is going to be used for testing and how the product will be tested, this may alter dev approaches to solutions to help harden the software.
– When a Product Owner reviews the test plan, and feels as though the QA interpreted the product fix/enhancement incorrectly – he or she can give the tester that feedback. I’ve also found it valuable to discuss the acceptance criteria with the PO – because they often have a view of the product use that dev teams may overlook.
– When other testers (perhaps with more experience in the front end of the code) review the test strategy – they could suggest improvements to the strategy , which may include toning it down to be more focused, or expanding it to be more inclusive of integration tests.
– Finally when an entire team agrees on the test strategy – there is always less finger pointing.… those are just some of the advantages.
Thinking it’s possible to test everything.
Wondering why and how you missed that bug
Thinking people who have worked in the company longer than you know more/better than you.
Being afraid to fail (this is key to learning!)
I do think that failure plays an important part in improving our chances of future success, and new testers might see failing as a step backwards.
Whenever a project doesn’t go as well as we expected, or we miss a bug, instead of dwelling on the negativity of the situation I try and think of it as a positive learning experience that I can use to improve mine and the teams actions in future projects. Why do we think we missed that bug?
Even though I am still quite new to testing, I can see other new testers around me who can get bogged under by their failures and this can affect their confidence as a tester.
Failing is a big part of learning and I do believe as testers we need to fail every now and then so we can improve.
@hhaken I would agree. Like may careers I think failure if probably the best way to learn anything as you rarely make the same mistakes again.
- You must be logged in to reply to this topic.