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 by ...
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 ...
For starters, Agile is not an actor.
One doesn't "work with Agile", "uses Agile", or things of this sort. Also, Agile doesn't act, it "doesn't do/make things".
Agile is a mindset described in the Agile Manifesto and other documents.
By reading your short description, it seems that before you used to work in a manner closer to the Agile Manifesto than now.
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 ...
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... (...
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 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 ...
It can work both ways, it depends on the situation
In some companies Agile is bunch of buzzwords used to cover the fact that waterfall and command and control are really what's going on.
In other companies Agile is used in an empowering model giving more voice and input to all folks including QA.
My experience is that the former approach is what exists in ...
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 ...
Wonder why you want to present this to management? What is your goal here, what do you hope to achieve. Do you want to show them they have unknown quality issues?
Normaly I would expect the product to have either an issue tracker or a backlog. Just put the issues on the list, discuss it with the business owners and let them prioritize. Together consider the ...
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 ...
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 ...
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 ...
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 ...
My ex-client went through a very similar thing. When I started, QA weren't invited to walkthroughs, project meetings, sprint planning, daily stand-ups, etc., and developers were estimating the time for QA! Genuinely couldn't believe it.
The problem was, QA (being the ultimate gatekeepers of quality) were just seen as obstacles rather than valued members of ...
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 ...
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 ...
There are some major red flags here.
You're only going to any testing after development is completely done? If this is development of a single feature, that's fine. If this is for an entire sprint worth of data, that's dangerous. You do not want to wait two weeks before sending a bug report to a developer. When I was developing I could barely remember what ...