Use each of the following payment methods: X, Y, Z, ...
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 ...
What would you do?
I'd most likely hand in my notice working in such an environment.
Is there any reason why this has to be overengineered? Not in my opinion.
I'd simply create one test case and trust my coworkers. They should be able to communicate when it's needed.
Of course getting access to all three systems is a priority (it is really necessary in fact)...
Every person can have unlimited conversations and unlimited messages
in a conversation.
These are two use cases:
Every person can have unlimited conversations
Every conversation can have unlimited messages.
As one of the testing principle is :
Exhaustive testing is not possible .meaning you cannot test all the possibility for a system as the combination ...
unlimited conversations and unlimited messages
something works for an unlimited amount of data, in this case, infinite messages
These two statements may mean different things.
There is no such thing as an infinite number of entities in a computer system because computers have physical limitations, in terms of memory, storage, processing.
What you can do is ...
I see this as a question which should introduce performance / stress tests to determine the number of conversations / messages which still allows user to use the application and number of conversations / messages which the system can actually handle.
"The value of any practice depends on its context"
N-wise testing is a technique, not a silver bullet to solve any problem.
It's your responsibility as a professional to analyze how to best approach a specific problem.
Take the example of a pairwise analysis:
valid name, valid password
valid name, invalid password
invalid name, valid password
What about the three of you sit down and... work together? You can simply plug one computer in a screen and you all test it together.
(No sarcasm, seriously)
Two of the tags you posted are "HP-ALM" and "Jira".
It can be a guess, but I feel that you may be limiting you way of working because of how these tools are setup.
From the Agile ...
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 ...
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.
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 ...
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 ...
Personally I would interpret the top 3 entities as follows:
Epic/Feature > User Story/Use Case > Acceptance Criteria
So for example:
Epic/Feature E1: Permission, the system should allow the restriction of access to data and actions to specific group of people.
Use Story/Use Case UC1: As an salesperson, I want to be able to access the list of clients ...
So I have been using a test management tool (Kualitee) that allows me to somewhat managed the same with the help of test scenarios and test cases group into one.
For example, I choose a module to test and create three different test scenarios to be executed by three different testers, I group the corresponding test cases according to scenarios and then ...
Test automation code is code, it should follow the same princibles as maintaining regular code. One princible that comes to mind is:
The Single Responsibility Principle (SRP) states that there should
never be more than one reason for a class to change.
When you need to change the test-code, challenge yourself does it follow the SRP. Is it a good reason to ...
It is very important to understand the difference between requirement, use case, and scenario if you are working for a software testing solutions provider.
Requirement is the new or updated functionality that is to be introduced in an application which currently is not present.
For example: A feature for customers to submit a checklist via forms and receive ...
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 ...
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 ...