Good question. Here I am going to explain some steps from my experience.
1) We need good teamwork for that.
2) Here I just want to clarify that "Execute All Test Case/Suite" term. We need to prioritize test cases in four quadrants like below.
3) Do a good amount of Exploratory Testing instead of totally scripted approach.
4) Try to cover all business-...
Basically you never have enough time and resources to test everything, your test cases are already a subset of this infinite "everything".
What should you do then ? prioritize. A common heuristic is RCRCRC:
Recent: new features
Core: essential functionality of your product
Risk: risk is defined as the Probability of occurrence (how likely is it to ...
Feedback also from my side what I learned from projects.
1. Prioritize the test cases
In my past projects we prioritized the test cases. We used HP ALM and there we had also couple of test cases and it was impossible to execute the all. So what we did is just to prioritize the test cases e.g. Critical, Very High, High, Medium, Low - same as you would do it ...
In such situations, the most important thing is to prioritize your tests. Risk-Based Testing is a good way to prioritize your tests. Look at the risks you foresee and base your tests based on the mitigation plan for the tests. For every risk analyze the impact and the likelihood of occurrence and assign a priority to the corresponding tests. Run the high ...
Start by analyzing what would be the impact regarding change. So you know the scope to be covered.
Out of the large set of Test Cases, you must be able to prioritize test cases as not all of them will have same priority. You may end up with High Priority, Medium Priority, and Low Priority set of Test Cases.
You might want to execute all the Test Cases but ...
Find some measure then rank.
Lets say your measure is, say, line coverage; or exprssion coverage, or ...
Run each test collecting coverage measure for that individual test.
Rank the tests. (I'll expand on ranking after).
Next time around only run the ranked tests + tests that previousely found a bug + randomly selected other tests to fill out the resources ...
Domain testing is an umbrella term for Equivalent partition and boundary value analysis. Here, we try to cover all the available behaviours of a system by using the least number of inputs. Here domain means each partition that is created.
Equivalent partition means we divide the inputs into different partitions, here each partition means input value range ...
Please have a look at the simple definition of Black Box Testing and Gray Box Testing
You can also call behavioral testing as a Black Box Testing, In such testing, testers should test the application without knowing the internal structure or code of the applications that things are hidden from the testers
Gray Box Testing:
It is ...
Large number of test cases generally means some of them are ignorable or plenty of them depends on your test case making and extent of the effect of feature on the system you are testing.
Firstly, you will look for the major cases in regression if they pass or not, you will try to check things are not exploding when running major things. That may compile to ...
The answer depends on whether you are doing manual or automated testing
For all testing make sure you follow the guidelines in:
The agile testing pyramid
The agile testing quadrants
Most of all you make sure you
Have a conversation with the product owner and follow their advice
If you are doing manual testing my advice is:
Use risk based assessment
Use an ...
How do I execute/test a large set of test cases with limited time and resources?
For example you have 500 test scenario or testcases for each module, As a tester first we have to decide which feature is important in this module than you have to go for that particular feature test scenario.( For Manual Testing )
When you have large number of scenario that ...
For 20 years now, there's been a huge gap between QA and DEV teams. Most QA people are not programmers and many don't want to become programmers. This gap has never really closed, rather it's being masked a bit; that on Agile teams today, the developers are expected to write Unit Tests on each Sprint.
Unfortunately due dates make it impossible to spend ...
Prioritize the critical test cases and time consuming test cases. Share those test cases to the testing persons who executes fast and correct.
Then give the medium test cases to other persons who have good knowledge of the project/ product.
Then aggregate the low priority test cases and give to the remaining testing persons to execute.
For most test cases depend upon your choice to which one you have to execute first and later on. For large test cases, mostly it needs to be prioritized.
First: prioritize the test cases.
Second: Check which cases/issue affects most of the module.
Third: Go for newly fixed issues for modules.