New answers tagged

0

What does the specification of the Q&A's tab say, regarding behavior/functionality? That will give you the basic functional test cases. Other than that, some subjective user experience analysis based on customer usage will help you to QA it for a start. I'd read over the specs etc and then go from there.


0

Sounds like you have a tough gig there. Unfortunately your situation isn't uncommon and even in mature organizations, you will hear phrases like, 'What you didn't test that!' There is so much good advice already, however I think there is something missed. Your issues do in part sound as if it's a top down issue, with your management needing to take a more ...


0

No. But I can see why management are making the terrible mistake of thinking the answer is yes. There are three cases: A bug is caught by a planned test A bug is caught by QA exploratory testing, or other means A bug is not caught While case 1 might be better than case 2, both are much, much better than case 3. But the attitude that testing should be all ...


0

The easiest definition of the intermittent issues in testing could be unexpected random errors that testers have to deal with. Most of the time, these issues are triggered because of unanticipated reasons. Also, the intermittent issues can also be understood as inconsistent behavior of the application for multiple test efforts made on a build while sticking ...


0

Security testing services in the IT industry ensure that the application is tested for all possible threats and vulnerabilities, followed by implementing all the measures to make the product more secure. Security Test Plan is to: define security goals through understanding security requirements of the applications; identifies a scope of the systems of ...


1

Well, ideally the designed tests should cover all error cases. Exhaustive tests are very costly, and in the end the management must decide what confidence level they want to achieve, and how much money they want to spend on it, aiming at a sweet spot depending on the application. This money should obviously be used most efficiently. Exploratory tests, ...


2

"One can predict the ways in which a software should work but cannot predict the ways in which it will not work." Testing is inherently an exploratory activity. If we deprive or even blame an activity for its core characteristic then basically we are turning it into an empty ritual. Exploratory Testing


1

The "blame QA for bugs" mentality should be stamped out in management circles. The primary point of QA is to find problems which means they should be actively praised and sometimes even rewarded for doing so. Each bug they find is one that customers don't (assuming that it gets fixed). That not only improves sales but also reduces maintenance costs ...


0

I agree with you regarding QA should find as many problems as they can especially with exploratory tests. Assuming your management implements a policy in wich your testers are not allowed to deviate from your predefined behaviour. With this policy in place you just created a very expensive automatic testing suite. My point is: test cases you can anticipate ...


37

I think the first big problem here is the attempt to assign blame. In accident reports, the FAA doesn't start with who to blame, they start with what went wrong and what were the causal factors. Assigning blame causes all types of unintended consequences. In the worst case, if you blame/penalize QA for finding bugs that were not foreseen during the design ...


5

Identifying problems should never count against anyone, as it leads to a culture of defensiveness, cover-ups and people attempting to game the metrics. In theory you could track the ratio of bugs found during planned and unplanned testing, as it could indicate that you are not spending enough time on risk assessment. However, if the developers know what the ...


10

First, the previous answers are good and bring up different view points to consider. I agree that management shouldn't be finding ways to blame QA for missing bugs or finding bugs in unexpected, unplanned ways. That's a huge benefit to the team and a good skill to have when doing testing. My take on this is why is there only "happy path" test cases ...


0

Intermittent Bugs are the kind of bugs which are not having predictable conduct. Means assuming you execute same test twice on any application, each time it will give you some unique outcome. Might be you get it again on executing third time.


7

I think your tittle can also read "should we blame QA for finding bugs?", to which I hope no one replies yes, although I'm not so certain about the management in your organisation. You got it right, not all test ideas or bugs can be expected when reading documentation, requirements, or other documents. You simply have to interact with the system to ...


3

Testing is always partially exploratory, and for any reasonably complex software, testing can never completely exhaust all the possibilities. Meaning, you will always find more issues and think of more scenarios as your knowledge about the application grows. Requiring all the scenarios upfront is just not realistic.


12

There can be a several reasons for test cases for bugs found later during exploratory testing not being identified during the project planning phase. Couple of them may be, Testers are humans. To err is human. Humans make mistakes. IF not wouldn't we be god instead? From what you have written, you do the planning along with the whole team and not in ...


0

What you need to do is to do a boundary analysis: Identify which values of your variables have different meanings/effects in the context of your program (in terms of branch execution - since the paths to states 6 and 7 result in the same code to be executed). In this case, X may mean different things when: It's lower than zero; It's between zero and one (...


1

I just loved the third idea you talked about. It would be really exciting to see how a manually created ‘artificial bug’ could be identified based on the tester’s skills and expertise. If I need to add something to the gamification of the software testing process, I would like to see the use of defect tracking, once the bug is identified and removed from the ...


2

If your definition of "classic software tester" is someone who takes in requirements and software and produces things like "tested software", defect reports, test reports, and so on, perhaps building test plans and test cases along the way, that doesn't have a place in Scrum. I'd say it doesn't have a place in very many methods that fall ...


0

As mentioned from various answers above, there is not right or wrong here. It depends on what you want to achieve, what you want to become. The testing industry has advanced a lot in the last decade and various roles have appeared, test analysts, manual testers, automation testers, etc. I am old fashioned and believe that balance is the key to achieve ...


0

I have a slight difference of opinion here with you. Since I have been associated with Quality Assurance and Software testing services for quite a long time, I believe the best way to test software demands the perfect balance of manual testing and automated testing. It is not possible to completely automate the entire process of software testing due to the ...


Top 50 recent answers are included