3
Naming specific tools will not age very well as an aswer, also learning tools you might not use could be waste.
I would study concepts and fundamentals, afterwards maybe find a popular tool to practise it. To find concepts to study you could look at topics presented at recent conferences. For example Agile Testing Days or Test Bash.
Some concepts that I ...
2
A full stack QA engineer should be skilled in testing Web apps, APIs, performance, Databases, and Mobile.
The common skills that are in-demand are:
Selenium(Java or C#): For web app
API Testing: Postman
Performance: Jmeter
DBtesting : DBUnit , Database Benchmark
Mobile: Testcomplete, Appium
These are not listed out from blue, but from the job descriptions ...
2
Since you have Session-Based Test Management, you can use your test sessions data to show your team's testing capacity.
For example:
You can plot the number of sessions your team did throughout time. Downtrends may intigate your team is having problems to keep a steady pace or that your testability has improved, demanding less test sessions for the same ...
1
Productivity is to be measured in terms of both a. Quality and b. Efficiency.
a. Quality:
Defect density: (Number of defects found in production or by end customer) / (thousand lines of new code written).
The lower this number, the better the quality of your testing.
Defects found: (Number of defects found in the year, bifurcated by severity).
This is ...
1
How can I measure in detail how successful we have worked?
While there are many useless metrics that could be cited her, IMHO there is only one (semi) useful metric of success... number of bugs that have made it into the wild.
If the answer is none, then the team has done its job. Successfully.
If the answer is lots, then the team has not done its job.
...
1
Friends and Family
Ask your family
Ask your family members to each ask a friend
Ask your personal friends
Ask your personal friends to ask a friend
Ask your work friends for a favor
1
Well, as you understand you cannot solve the problem.
For future reference, and as a way to make something out of a bad situation, you can come up with a solution. Those can range from very simple list of questions your support should ask, to more sophisticated like having information dump from the software or good telemetry that you can match with the ...
1
Accessibility Testing is a crucial testing type within Usability Testing as a whole (according to ISTQB Syllabus)
Target audience for Accessibility Testing:
Users with disabilities (any form of disabilities)
Target audience for Usability Testing:
Common users of those applications
Important Part:
Types of testing items/process conducted or performed part ...
1
I have the same concern as you did. Sometimes when applying these two techniques resulting in the same list of test cases. Sometimes after applying equivalence partitioning, and then decision table, I found some duplicates. So what I usually do is, I applied both of the techniques, then review the result quickly to remove duplicates test cases. I don't think ...
1
Let's consider the difference between the two:
Functional Requirements (FRs) tend to be explicitly requested by the customer/end-user, and are usually expressed in terms of "it must do this" or "it mustn't do that"
Non-Functional Requirements (NFRs) tend to be vague or generic (eg meet the ISO 12345 standard) or things that experience ...
Only top voted, non community-wiki answers of a minimum length are eligible
