New answers tagged quality-assurance
1
It depends
The longer answer:
There is no general answer to this question. Whether a mechanical solution or a software solution is more likely to fail depends on many factors, including but not limited to:
the nature of the problem - some problems are better solved by mechanical means where others are better solved by software.
the quality of the ...
0
1) "testing" is a subjective term ... video game companies with QA dept's test their games to see if they work within specified parameters. Meanwhile a dedicated gamer with way too much time on their hands will always find some exploit or cheat to use in a speedrun or what-not. This person is just spending way more time to dig into the system, time that ...
3
However exhaustive testing is not possible. we as a team consider following facts which might affect the coverage of Testing:
Effective Communication with Business Analysts: I believe testers should have proper understanding of what to test. Testers should be explained what problem clients are facing and what could be all possible solutions and why this ...
3
All other comments have explained the situation and solutions pretty comprehensively, but i just want to add few thoughts:
and found quite a few defects in the code. Most of them got fixed.
Here you have to ask yourself some questions,
Where these bugs critical in nature ?
Does it require hard effort to identify these bugs?
As discussed in many threads,...
1
A few things can be considered here:
Creating some kind of coverage matrix or document in which you identify what you will and will not be covering in your test cases. This can then be agreed on with you customer ahead of testing. This could also prevent/safeguard you from missing any (big) functionalities as you customer would highlight anything they ...
7
The biggest problem with failure is not learning from it
Management should will be grateful if you
Acknowledge the failures and put together a plan to address them and future occurances
Did they say all those specific words:
You are careless?
You are not worthy of asking?
You are risky?
Or are those words you are using, based on your - very valid ...
4
This might be a tricky situation, especially if you work with people who have never worked with testers, or have not much experience in software developement in general.
I think there are a few important points you and your colleagues need to realise:
You will never cover all the possible test cases. That's not even not job, because then, you'd be ...
10
So I can also give you an example in our situation. We had not exactly the same issue, but at production we also found a lot of issues and we were facing some troubles in the past. There were some scenarios how we improved the quality
1. All bugs found, create test cases for it (at least for the cricital ones): For bugs which we founded we created test ...
16
You will never ever cover all of the possible test cases.
and found quite a few defects in the code. Most of them got fixed.
Were any of the bugs related to these. Did you point out the possible consequences of the ones that were not fixed?
I did my analysis and gave important information to the stakeholders.
Did anyone read it? Did you point out ...
2
I think this is a much better idea than asking questions such as "Where do you see yourself in 5 years?" etc. :)
Let me share a few points I find important:
Regarding the application under test. I'd personally choose one I know and one where at least some bugs could be found. That's because I'd like to see the candidate reporting issues or at least talking ...
2
This is a very interesting topic and I have conducted a few interviews similar to this and here is my feedback based on the interviews:
You can evaluate candidate's ability to find out bugs within the given timeline.
You can evaluate the candidate's ability to focuses on functional or non-functional issues first.
You can judge the testing approach of the ...
3
Quite interesting topic and although this question has been raised two years ago it is still a current topic! Hence I would like to share our experience / thoughts.
Preparation from our side as business department:
We used a web application
Before starting we explained the product
We encouraged the applicant to speak all his steps "loudly" so that we ...
Top 50 recent answers are included
