25

Yes, while rather crude and possibly not the most graceful of test cases, such 'abusive' test cases are an important tool in stepping off 'happy path' thinking and testing. Effectively a test like this is a crude load/response test. While in theory it shouldn't happen in the real world environment, the fact that a bug was discovered with such abusive ...


6

Data: Use each of the following payment methods: X, Y, Z, ... Procedure: .... .... .... I don't see how any professional tester won't understand that you want to validate with each payment method. If for any reason the tester to whom you are writing this documentation gets confused, a 30-seconds conversation with you probably will solve any ...


5

Yes, API and GUI are different from a hardware product or command line enterprise software and as such requires specialized approach and techniques. But GUIs and APIs are usually a very thin layer above the actual business logic and features, when designing a test you you obviously check that the GUI itself (colors or location of elements for example) or ...


5

Probably not. I like to challenge defects like this with a simple question: Would an actual user execute this behavior? In most situation I would not expect users to refresh a regular page ten times in a row. Some pages might only update the page content on a refresh, forcing the users to refresh often to get the latest data. I think that is more a UX-...


5

Probably, refresh is not a simple operation as it seems so that's a good system test. Having said that I would give it low priority and execute it only once in a while since it would significantly slow down the rest of the tests


4

The user interacts with the GUI The GUI interacts with the API The API interacts with the back end In theory the GUI tests should cover all the API tests, right? Well, what about when the GUI prevents the user from submitting invalid data? You still need to test that the API handles these cases sensibly. Each layer should be tested separately: GUI: ...


4

Selenium IDE has no version control integration, at least for now. All the test info is written in a .side file (unless you are using code export to another language). If you've set up git correctly, you should be OK, provided you are not trying to work at the same file at the same time. Just commit different tests in folders you agreed on. However, I ...


3

Note: I will talk about testing itself since the documentation of certain activity is only but a product of the activity itself. I'm not sure is your question is about "the testing for ... is different" or if the "the testing design for ... is different". The second point talks about the heuristics for exploration, the "meta-hows". E.g., HICCUPPS: ...


3

Blocked test case is a test case that cannot run because the preconditions for its execution are not fulfilled. While, Incomplete test cases are which cannot complete execution for various reasons.


2

Honestly, in this example, I'm confused about why the confirmation dialog should appear at all. Isn't it just a useless step that slows down the user? There might be some reason for that that I can't get from the short description, but I'm a bit suspicious, that's why I'm bringing it up. And I think that's exactly what you should do with the rest of your ...


2

My answer is going to be very opinion-based (as is your question) but, that is the approach we use. We manage our test via Excel (which completely sucks) and, if test steps are shared between tests we basically say "repeat these steps...". We use this same approach for both manual and automated test cases.


2

From personal experience I have found that test cases are much more impactful for rigorous system testing. Ensuring that any flaws in the system are kept to a minimum with the use of edge cases also being tested. I have used checklists, however, these tend to be a more 'happy path' type scenario. I wouldn't expect to be finding any extra bugs following a ...


2

I don't think there's any real benefit from being thorough when writing test cases. For two main reasons: you want other testers to use their imagination as well, which rarely happens when people follow written instructions it would take you so much time that you could spend better, e.g. exploring the system Sure, there might be some exceptions, but I ...


1

Usually for UI testing I'll focus on the major work flows/use cases. You mentioned the CRUD operations. I'll have a test for each of these to make sure it works. Typically you can black box test these imo. "If this UI goes out tonight, and these work flows pass, the UI should be good" For API's i usually have 1 or multiple tests for each endpoint and verify ...


1

Writing good and effective test cases covering all the scenarios depicts how efficient a qa services company is. Below steps can also be followed that can be beneficial to cover test scenarios. If user stories are provided with acceptance criteria mentioned,then direct test cases covering those scenarios can be created. After previous step, more negative ...


1

Your scenarion&description is not a test scenario to me, it is a feature description. One that is hard to read, which makes assumptions and lacks focus to be bluntly honest. I would rewrite it in a As a ..., I want ... , So that ... user story format: User Story 002: Automaticaly match pet owners names from PMS system As Jack (some role) the ...


1

The main difference in designing the GUI and API test-cases is the parameters verified and its expected result GUI test-cases mostly validate the user flow and test-cases will comprise of the Pre-requisite, Steps to perform and the expected results at the user end On the contrary, API test-cases will include endpoint details, the C/R/U/D operation to be ...


1

I guess this might depend.. First of all everything has its own cost. If you have lots of such tests it might take lot of time to raise each such defect. However the defect might get low severity and low priority and will never be handled. Another thing is that the use case itself might be very unlikely, or the area itself is to be reworked as per team ...


1

I'm don't think is related to one of QA, but more one about marketing and how you want your company to be seen. In some ways the choice is between being "Totally transparent" or "Controlling the narrative". Of the companies that I do see that are completely open, they are often based around open source software. In this case, the openness is beneficial ...


1

Users should not have to bear the burden of sending detailed bug reports to software developers. They've paid for working software and its most definitely not their job to produce detailed bug reports. Why not enable direct user ⇄ development communication? Mainly because users are usually not tech savvy enough to provide actionable complaints and ...


Only top voted, non community-wiki answers of a minimum length are eligible