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-...
Welcome to the site!
Your situation might be a difficult one for a couple of reasons:
you're new to the testing and you don't know much about the process,
about the technical stuff, and about yourself in such a situation
you're the only one on the team who is supposed to test; I find this the biggest obstacle because you basically have nobody to ask for ...
Start with understanding what works:
What data is valid ?
What data is used ?
What is successful ?
What are the variations ?
What are the users like ?
What are the long term business goals ?
What are the short term business goals ?
Goals can be very different across industry, company stage, location, profit vs non-profit, etc. Learn what quality means to ...
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 ...
I believe it is important to look at test coverage at something that
Needs to be adjusted as features grow and change (proactive)
as opposed to
Ensuring that things that happened in the past are prevented (or at least detected) by adding tests for them (reactive)
The problem with the second approach (particularly common in traditional waterfall and command &...
In addition to what the other answers have said, I would say the interviewer is looking for how you, as a new addition to a team, would deal with a no-win situation. Frankly, I'd suspect that- at minimum - the company has found itself in this kind of situation in the past. At worst (I freely admit that I'm cynical) something similar is going to be facing ...
You have two advantages here,
1) Being new to the project
You will test the product as if you are a customer using the product for the first time.
If being a user with zero knowledge about the product forces you to ask so many questions and dig through documentation to do even the simplest tasks. Then there is a serious problem with the UX design.
Hopefully, although alone, you can talk to the developers, the business owner, scrummaster, etc.
At this stage you should primarily be in question mode
Find out what the system is supposed to do, in detail
Find out what the user is trying to achieve
Ask about different workflows
Determine positive and negative test cases to try
Ask about devices and ...
Your project sounds like where my project was when I started. You need to maintain your discipline. Here are the mistakes I've made, the lessons learnt, and what I've improved:
It's easy to think "I'll remember bug X", or "I'll do it later", but in reality you'll be overwhelmed and forget. Use a bug tracker, and record each bug as soon as it's discovered! ...
Context: So recently I was on a project as a consultant, to help improve reliability and scalability (fix bugs and make it go fast). I turned around their product, with a 800% performance increase and 70% reduction in errors.
These are the biggest takeaways I have from that:
Add a Real User Monitoring (RUM) and Error Monitoring tool.
I used raygun.io I ...
best practices on how to start the improvement strategy?
what processes/tools would be the best?
Nobody will be able to give a precise answer for this, because the value of any practice depends on its context.
some ideas on how to start the improvement strategy?
As said above, you will need to understand your context in order to evaluate the value ...
I think the article you link confuses two different things- bug tracking system is not the same as the bug handling process.
Saying "If it is non-critical, you drop it." doesn't mean you don't track the things you are leaving, tracking can be done in using any system you like and in this case it's the Kanban board. The opposite is also not true, you can ...
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 ...
Magento has its own "testing guide" which seems to cover most if not all of these topics.
Magento also has its own Functional Testing Framework, which you should probably use as it will make live of future developers/testers easier which already know how to write functional tests for their product. See https://devdocs.magento.com/mftf/docs/introduction.html
We had the same issue in our past. For some reasons we managed that somehow. Because beside testing with simulators we also tested with real devices (since real devices have different behaviour than simulators).
First: Made an overview about the devices with the help of statistic webpage
In case of using real devices you have to consider that you are using:...
On the other hand, we want to start the test early
This is the key area to examine. If there is a requirement to start testing 'early' then the definition of done should include this. However I see the problem is that now you'll have two definitions of done :(
So in this case I think you might want to consider a 'definition of ready for testing' that is a ...
I expect that your remote testers see their job the way it is defined for nearly all the organizations that use them: does the software work? and can they sign off on that and get paid?
If you create an arrangement where their pay and employment is dependent on giving much greater feedback it will happen, though you'll need to invest time and training ...
First, I would probably suggest that if one really follows Agile development approach, there should be no Test team. In many companies, there's a belief that Agile is only about boards, Jira, iteration and fancy "ceremonies" instead of old "meetings". It is not the case, Agile approach is inherently different (and, actually, not always required, which is not ...
Yes, I would take previous test cycles and number of defects with this team, product or developer in a account. If it is new team/product make a guesstimate based on your previous experience.
I never had a test run where I didnt find a defect, or struggled with the configuration, infrastructure, and or setup to be able to start testing.
This estimate ...
We got nearly the same situation in our project. We got a couple of systems that we had to test, but just two testers for the different systems which are nearly independent of each other. So I will try to summarize the lessons which we learned at our project:
Exploratory testing We introduced exploratory testing and also used a tool that captured all the ...
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 ...
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 ...
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 ...
As testers we won't set hard boundaries for testing, that's why organisations push for test automation, CI/CD and so on. We expect to get 100% (almost) test or feature coverage for each new build.
But if you are in an organisation that doesn't have test automation then some times test completion deadlines could make you feel challenged. In such cases, few ...
The short answer: you can't prevent regression in third party software.
Third party software, as one of the comments mentioned, is outside your control. Since it's essential to your software, you have a few options in how you handle this.
Regular smoke tests - Have a set of smoke tests that cover the essential functionality of the third party ...
Setting aside opinions people may have about SAFe and how Agile it really is, there is no conflict between SAFe as it is defined and TDD or BDD. In fact, the official safe write-up for teams suggests that software teams should be using those practices (https://www.scaledagileframework.com/agile-teams/).
SAFe also still prescribes cross-functional dedicated ...
Yes browserstack and Sauce Labs are long standing and leading providers of cloud based browsers and emulators.
They include options for connecting to your local environment so you can test your system without needing to upload or create a testing system. This meets the need of "your system but ...