A bug that is only a bug 50% of the time is still a bug.
I would still report/document it as a regular bug, but with an "intermittent" label - letting to know both developers and management about the bug, and that it is not reproduced all the time.
This way the issue would get its priority by the management, and the mentioned people may generate some ideas ...
First I would rephrase your reasons:
Testing being done by developers is good at the unit test level. A dedicated QA is likely to have more skill in finding and exploiting situations the developers didn't realize could be problematic (but customers can and will find).
A skilled QA will quickly gain knowledge of the entire application domain and then apply ...
KPIs can be dangerous - it's very easy to measure the wrong thing or worse, reward the wrong thing. The general rule is that people will do more of the things that get rewarded.
Some of the things you should consider:
If you use the number of bugs raised by the team, you will see bugs raised for things like misplaced pixels. Modifying this to use the ...
The best KPI's for testing are ones that you wouldn't expect.
Can the team ship with a boring level of predictability ?
Are customers happy ?
Is the product selling ?
Are there very few critical issues found in production ?
Are budgets and schedules being met ?
These co-incidenty are 'whole of team' KPI's which testing plays a key part of.
Take a deep breath
and look at the big picture
Talk to folks / your boss about standards. Have a meeting. Agree on standards including items such as special characters. Take short term initiatives this month to reduce long-term repetitive pain next year.
and allow for humans
I've lost track of the number of times I've: typed weird characters ...
Don't be afraid, finding someone more senior than you is fun, your finding a teammate you can learn from. Do understand X+ years does not mean more senior, experience is something that does not necessarily come with time.
What do you expect from a candidate better then you?
At-least same basic level
A Senior should be able to teach, might need very good ...
Try to get a reliably-failing test case, but at the end of the day, it's still a bug. Make sure to state that e.g. "hey, this only fails ~1/2 the time".
(Note that one way to dance around the issue if it's impolitic is to write a new test case that runs the test e.g. 100 times.)
I once reported an HW bug that occurred ~1-in-100k times on ~1/10 devices... (...
This is a simple, if uncomfortable, situation to be in. Unfortunately, it does happen from time to time and you need to be ready for it.
The fact that the defect has been found close to the deadline is, in the short term, irrelevant. Your team has found a high severity defect, so you report it. Given the short timescales, you ensure that everyone who ...
There is also a different mindset that a tester (or a dedicated QA) would bring to the team: developer "builds things", tester "breaks things".
(When speaking of a "break things" mindset: Of course, no one is trying to literally break the software, it is just about approaching it from another perspective.)
A tester is dedicated to finding out new ...
One of the Context-Driven Testing principles is:
The product is a solution. If the problem isn’t solved, the product
Another way to say this is that software should work for its user, not for some generic/arbitrary/commonly-used set of definitions of how things should be.
When he says
Even if someone gives, the error message is ...
There is no standard anything in testing.
In very broad terms, all testers need to be observant and good communicators. Outside that, it depends.
First, there are several broad fields of testing, including:
Expertise in one area is no guarantee of expertise in another.
Second, there ...
Some of this is not that different from what a newly hired software developer would do:
Learn how the company makes money. Understand what problem the product solves, how people pay for it, how it's deployed (do you ship it or do you host it?).
Introduce yourself to everyone. You can generate a lot of goodwill by taking the initiative to introduce ...
Deciding to release with severe bug (and escalate next release with a fix) or postpone release is business decision. It can be done only by someone who understands how customer works.
Maybe it is not a big deal at the end, and you can go on with the release (and inform customers what bug is, and find workaround until bug is fixed.
Maybe system is not safe ...
A bug that cannot be reproduced on demand (but is known to exist) is doubly more important than one that can be easily reproduced. They can occur via several scenarios, all very important: e.g. they might occur under conditions which may not be present in the lab, but very likely when the client is using the software; or they may occur as a result of a race ...
Anything for which you can write a logic piece of code can be automated.
I think usually the things that are very repetitive task that are very cumbersome to do day in and day out can be automated.
Unit level checks can be automated so that the developers can perform their validation checks.
Usually security & performance related tasks are automated.
No matter what else you do, you will need your team lead's approval before you act.
I recommend that you take some proposals to your team lead, after you have done the following:
Measure skill levels - find out just how much skill you and your fellow team members have with coding and designing automated tests. There are plenty of online tutorials and ...
A user story describes a piece of functionality from the perspective of a user. A classic example is:
As a registered customer, I need to see a list of my orders so I can
manage my purchasing.
A test scenario is a description of how a piece of functionality is expected to behave, with no specific perspective. The user story example I gave implies ...
Without being flippant, this sounds like you've got a serious communication problem in the team.
Given the limited timeframe, here's a few things to consider:
everyone in the team needs to know what a good bug report looks like
everyone in the team needs to search for a bug report on the issue they're seeing before they write up a bug report. This means ...
Simply put, no it hasn't. It might be changing some development shops, but not all, and even where it is changing it isn't killing anything. Or at least, it shouldn't be.
First, let's be sure to clarify the difference between QA and testing. I went over this five years ago, but I'll summarize here. Testing is being a professional user that does some crazy ...
Have them learn about:
Unit vs. Integrated vs. User Acceptance vs Performance testing*
Boundary Value Testing - https://en.wikipedia.org/wiki/Boundary_testing
Security Testing - https://en.wikipedia.org/wiki/Security_testing
Usability and Accessibility* - https://www.w3.org/WAI/intro/usable
This site and questions like How do you prepare yourself for a ...
Does it matter? Sounds like impostor syndrome. Your probably less confident about your skills than you should be, it is the Dunning-Kruger effect.
In my book, you are good enough at anything, if you accept your current skill level. Have a plan to improve. Act on your plan weekly.
The proper reaction is not just "fail the test" and be done (or pass it and be done).
You should do some "due diligence" investigation into whether you can trigger the bug consistently. If you can find a consistent trigger, report that.
If you cannot find the root cause and trigger it consistently, report it as an intermittent bug and let management to ...
I'm going to take a slightly different focus on this question; my
answer is: A dedicated QA team member isn't necessary, but a
dedicated QA role is a good idea.
Consider a situation where you have a dedicated QA team member but he
does a poor job (or doesn't do his job at all). In this case, you've
got a particular solution in place, but the problem isn't ...
It reads to me as though your organization is using the SM role in a somewhat different way than classic Scrum, so my suggestions could be way off-target here.
Classically, the SM role is to facilitate progress by finding ways to clear or work around any impediments that arise during a sprint, to lead meetings, to ensure that meetings stay on-topic and stay ...
Push to make everything testable in the integration environment. The location you are testing in should mimic the production environment as closely as possible. Most payment providers should also have a testing interface, even credit-card validation has fake numbers to use.
If the devs can confirm they fixed it, use their environment, maybe even pair test ...
This is not a matter of number of hours only.
To me overtime serves for emergency, only when unexpected situation occurs. Unexpected things can happen and I accept it and I am open to help my employer (company I work for), but I always need to know what the company, the team lead, the boss, my team etc. is going to do to avoid such emergency situations in ...
It depends on what you mean by "through" - obviously, this is not a job board. A quick check of Stack Overflow Jobs shows that companies are hiring people for QA roles though the network, and they'd be quite silly to use Stack Overflow for hiring for a QA role without looking at the candidate's SQA profile.
Outside of that, I have used my Stack Exchange ...
Like many of the other roles (particularly in smaller teams) a dedicated person performing that role probably isn't actually necessary and may even be a point of inefficiency in some situations. That said just like with any other specialization in software development, having expertise, interest, and dedicated time to focus on a particular problem area will ...
Your first bullet assumes that you write the code before you write the tests. That's a common assumption, but note that you have a choice about whether it's true. If you change the assumption, if you write tests before you write code, you can wear your "tester hat" without being (quite so) biased by the code you've written.
You can do this on two scales: On ...
I'm the team leader of a software development team in a software development company. I work together with 5 to 7 other software developers. I regularly interview people that are more experienced than I am. Also, some of my employees are more experienced than I am (in years and in technical knowledge).
This is what helps me in my role as an interviewer: