619 views, 0 RAMs, and 4 comments
I am about to go into an interview for a computer related job. I have experience with manual testing but want to get some experience answering questions before the interview. So what are some manual testing interview questions I can practice for my interview?
I found the answer to your question on this link...
Hope this helps.
I literally can't stop eating gems.
Here are some great questions! What is End-To-End Testing? Refer System Testing. What is Functional Testing? ... What is Non-Functional Testing? ... What is Acceptance Testing? ... What is Alpha Testing? ... What is Beta Testing? ... What is Gamma Testing? ... What is Smoke Testing?
You can check the below link, there are updates top interview questions with answer list:
The link posted by Adisharma seems to cover a wide array of possible test items however in an interview probably not much of that will come up. In practice, nobody really cares if you posess the ISTQB approved vocabulary. In fact, people who are "into" QA tend to be overly dismissive of anything ISTQB but I digress.
Here are some random tester interview thoughts for testers out there:
1. Make sure you understand what boundary conditions / equivalence classes are. This is the fundamental building block in test design. If there is an input that accepts 1-100, your equivalence classes are less than 1, between 1 and 100, and then more than 1. Your boundary values to test are -1, 0, 1, 100, 101. You should always think in these terms for test inputs and it should be second nature.
2. Make sure you understand how to generate a decision table - a decision table is a very defensible and easy to understand and execute set of input driven test scenarios.
|Scenario 1||Scenario 2||Scenario 3||Scenario 4|
|Keep me logged in?||yes||yes||no||yes|
|Result:||User Login Fails||User Login Fails||User Login Succeeds||User Login Succeeds with keep me logged in cookie.|
3. Learn the power of combinatorial testing. When you think about testing... anything, any given failure is going to come down to, essentially, 2 factors. A factor is another word for input. This is to say, rarely is a defect the result of a combination of 3 or more inputs. Usually just 2. This is backed by NIST but fuck if I am going through all their scientific papers for a citation ( https://scholar.google.com/scholar?q=NIST+combinatorial+testing&hl=en&as_sdt=0&as_vis=1&oi=scholart).
Let's say you are testing a feature that has 5 drop downs and 5 options per drop down. This would result in 3125 test cases if you wanted to test each combination... which is ridiculous. Since we know that statistically most defects are related to only 2 inputs, we only need to make sure that each pair of inputs is tested together. This is called pairwise testing for shorthandthough you could choose to generate combinatorial results to 3, 4 or more factors.
To see this concept in action you can play around here: https://pairwise.teremokgames.com/. When I generate combinatorials for the scenario above, I end up with 25 test cases... QUITE A BIT MORE MANAGEABLE WOULDN'T YOU SAY?
If you are into command line things the guru of my heart James Bach provides a free tool allpairs that will create combinatorial pairs nearly as good as any paid tool: https://www.satisfice.com/download/allpairs
4. There is a wonderful philosophy and art of exploratory testing but if you are just trying to do your job, know this term to mean testing without a plan. If you aren't a total draw on resources, you will do this mindfully. The more automation testing you have in place, the more all functional human testing begins to blend with exploratory testing. If the topic comes up in your interview let them know that exploratory testing has a time and place but you are wary of the slapdash half assery that sometimes accompanies it.
5. WRITE GOOD BUGS. UNDERSTAND WHAT MAKES A GOOD DEFECT REPORT. The answer? Portability. Write your defects so that a tester from another team, or hell a PM from another team could read the defect and understand EXACTLY what the issue is and how to reproduce it. This will help anyone you deal with and forgetting them, it will help yourself when you inevitably need to refer to a defect a year down the road. In the interview, make your love for good defect reports known. Opine on the inefficiency of shitty bug reports. It will be noted and appreciated.
That is enough for now. If anyone actually wants to talk about their career in test I am here for you with nearly 2 decades of experience.
Post a New Comment
Do you like having a good time?
Register an Account
Read Quality Articles
Read some quality articles. If you can manage to not get banned for like five minutes, you can even post your own articles.
Argue with People on the Internet
Use your account to explain why people are wrong on the Internet forum.
Vandalize the Wiki
Or don't. I'm not your dad.
Ask and/or Answer Questions
If someone asks a terrible question, post a LMGTFY link.
Make Some Money
Hire freelancers and/or advertise your goods and/or services. Hire people directly. We're not a middleman or your dad. Manage your own business transactions.
Answers— Read More
Find more related content below!
- What are some Linux interview questions?
- What are some .Net interview questions?
- What are some good Core Java interview questions?
- What are some common Data Structures interview questions?
- What are some good SQL interview questions?
- What are some common Salesforce interview questions?
- How would I find an English-to-Spanish translator for hire?
- What are some common Manual Testing interview questions?
- What are some common Bootstrap interview questions?