Our company always used a test management tool. We work Agile, and without a test management tool we’d get completely lost in finding which cycle the bug belongs to. Now we use Practitest because we could build an organize library of all our test cases and structure them with the smart filters which separate tests per versions, cycles etc.
Recently we have ...
Another approach is to go simple. I don't know if that works for your case.
You can use something like APId. It allows you to define user stories (called transactions) that are series of requests and check those. You can have dynamic variables between them. For example, can do something like authenticate, list all users, get the first user and verify that ...
I think that it is one and the same thing. If you are in a top software testing company, they will emphasize equally on both of the products. It is the quality that all matters. If we are able to get our in-house product tested well than only we can able to satisfy the customer needs.
All it depends on the management of the organization. If they are good ...
1) As a tester, you should go through the requirements for your estimation instead of going through the estimation time given by the development team.
2) From the requirements, you should estimate the time for creating/updating the test case for the given requirements and the time to execute them.
3) Also, you need to consider the scenarios like; if you ...
First you should be proud of yourself that you've found a large no. of bugs. Once all the bugs get fixed, it will help to increase the quality of the product. Don't worry about what others say. It's your job to find bugs and file them. Do your work promptly, you will get appreciated for sure.
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.
As for format, again, it really comes down to what is most helpful for you and your consumers
That is true! For us we had some struggle with our customers. Because the customer was complaining that testing was not "visible" within the department. Hence we decided also to add exporatory testing but with Kanban Board (at the same time it was also our bug ...
First of all, while I support using a Test Case Management tool (even if it's something as basic as a spreadsheet) it's important to recognize that it's a tool that requires both initial investment and maintenance to be useful. You're creating a body of knowledge that must be adjusted or corrected as the application it describes changes. It's a useful tool ...
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 ...
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 ...
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 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
The way the industry is trending, it is a good idea to learn how to code. With all of the different languages, tools, and free resources available, there is no better time than now. You don't need to become a master coder, you just need to learn how to write automated tests, which should lighten your workload.
The ability to adapt to change is a ...
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 ...