Below is a list of 100 Objective questions on various software testing Types, methods and techniques. This is an easy and quick test to take. Take the test now to find out how well you know the subject.
Congratulations - you have completed .
You scored %%SCORE%% out of %%TOTAL%%.
Your performance has been rated as %%RATING%%
Your answers are highlighted below.
Question 1
Black box testing is also know as Gray box testing.
True
False
Question 1 Explanation:
Gray box testing is a combination of Black-box testing and white-box testing. Gray box testing is not exactly same as black-box testing.
Question 2
Objective of black box testing is to validate application functionality with requirements.
False
True
Question 3
Black box testing does not require to know internal structure of the progam being tested.
False
True
Question 4
Black box testing validates functional requirements but not non-functional requirements.
False
True
Question 4 Explanation:
Black box testing also covers non-functional requirements like display, text alignment, response of the application etc.,
Question 5
Black box testing can uncover defects that cannot be found by white box testing.
True
False
Question 5 Explanation:
Both Black box and White box testing complement each other, there are classes of errors that can be found by other. e.g. issues with text alignment in a browser window cannot be found with white box testing. There are other such error where in they can be found only by Black box testing but not with white box testing.
Question 6
BVA (Boundary Value Analysis) is a black box testing technique.
False
True
Question 7
All-pairs testing is one of the Black box testing techniques.
True
False
Question 8
Equivalence partitioning is a black box testing technique.
False
True
Question 9
State transition table is a black box testing technique.
True
False
Question 10
Decision table is a black box testing technique.
False
True
Question 11
White box testing is also know as Glass box testing.
False
True
Question 12
White box testing is also known as Gray box testing.
True
False
Question 12 Explanation:
Gray box testing is a combination of white box and black box testing, it's not exactly same as white box testing.
Question 13
White box testing is also known as Clear box testing.
False
True
Question 14
White box testing is also known as Structural testing.
True
False
Question 15
White box testing is also known as open box testing.
False
True
Question 16
White box testing is also known as Transparent box testing.
True
False
Question 17
Statement Coverage is a white box testing technique.
True
False
Question 18
Decision Coverage is a white box testing technique.
False
True
Question 19
State transition table is a white box testing technique.
True
False
Question 20
Branch testing is a white box testing technique.
True
False
Question 21
Data flow testing is a white box testing technique.
True
False
Question 22
Path testing is a white box testing technique.
False
True
Question 23
White box testing involves testing internal structure of programs.
False
True
Question 24
Programming skills are required to perform white box testing.
True
False
Question 25
White box testing is usually done by developers.
False
True
Question 26
White box testing techniques are required to perform Unit testing.
True
False
Question 27
Which type of testing can find dead code ?
Black box testing
White box testing
Both White box and black box testing
Question 28
White box testing can find redundant code.
False
True
Question 29
White box testing can find errors associated with loops.
False
True
Question 30
White box test cases cannot be automated.
False
True
Question 30 Explanation:
White box test cases can be automated, there are tools like Junit for Java, using which Unit test cases for Java programs can be automated. Similary there are other unit testing tools like NUnit for C# etc.,
Question 31
Smoke testing and Sanity Testing are one and the same.
True
False
Question 31 Explanation:
Sanity testing is to check if new functionality and test environment is stable to continue with testing. Smoke testing is to check if all the important functionaltiy is working fine so that detailed testing can be carried out.
Question 32
Sanity test cases are usually not documented.
False
True
Question 33
Sanity testing is a very high level check of the functionality and environment.
True
False
Question 34
Sanity testing is done before running Regression tests.
True
False
Question 35
Smoke testing is performed after regression testing is completed.
True
False
Question 36
Smoke testing is carried out before performing other major tests.
False
True
Question 37
Smoke testing is done to confirm important functionality are working as expected.
False
True
Question 38
Objective of Smoke testing is to catch show stopper defects as early as possible.
True
False
Question 39
Smoke tests are a subset of regression tests.
False
True
Question 40
Smoke test cases are not documented.
False
True
Question 40 Explanation:
Smoke test cases are usually documented.
Question 41
Smoke test cases are not a good candidate for automation.
True
False
Question 41 Explanation:
Smoke test cases are ideal to automate, as they are run more often, almost on every new build provided for testing.
Question 42
Unit testing has to be performed by developers.
True
False
Question 43
Unit testing requires understanding of interal logic and structure.
False
True
Question 44
Unit tests cannot be automated.
True
False
Question 45
Unit testing by developers and functional testing by testers can be done in parallel.
True
False
Question 45 Explanation:
Functional testing is started only after Unit testing is completed.
Question 46
Unit testing does not require any documentation.
True
False
Question 46 Explanation:
Unit tests need to be documented.
Question 47
Integration testing is a Black box testing approach.
True
False
Question 48
Integration testing is also know as end to end testing.
False
True
Question 48 Explanation:
Integration and end-to-end testing are different.
Question 49
Bottom up and Topdown are the 2 common approaches for Integration testing.
False
True
Question 50
Big bang is one of the approaches for Integration testing.
False
True
Question 51
Sandwitch testing is also one of the Integration testing approaches.
False
True
Question 52
Defects can be found more easily in Botton up integration testing compared to Top down testing approach.
False
True
Question 53
Test Cases are not documented for Integration testing.
False
True
Question 54
Integration test cases cannot be automated.
True
False
Question 54 Explanation:
Automating Integration testing is difficult but not impossible.
Question 55
Load Testing is a non-functional test type.
True
False
Question 56
Load Testing and Stress testing are one and the same.
False
True
Question 57
Load Testing is done to check response of application under peak load conditions.
False
True
Question 58
Load Testing allows to determine maximum operating capacity of an application.
True
False
Question 59
Load Testing helps to identify application performance bottlenecks.
True
False
Question 60
Stress Testing is a non-functional type of testing.
True
False
Question 61
Stress Testing helps to determine application behaviour at peak or over peak load conditions.
False
True
Question 62
Stress Testing helps to determine application upper limits capacity.
False
True
Question 63
Stress Testing is similar to Load Testing but objectives of both testing types are different.
False
True
Question 64
Endurance Testing is also known as Soak Testing
True
False
Question 65
Endurance Testing is also known as Longitivity testing.
False
True
Question 66
Objective of Endurance Testing is to find performance degradation due to load over longer duration of time.
False
True
Question 67
Endurance Testing is similar to Load testing but tests done ____________
with max load
for longer duration
Question 68
Endurance Testing, stress testing and Load testing requires different automation tools.
True
False
Question 69
Objective of Installation testing is to find issues related to Installation of software.
False
True
Question 70
Installation/Uninstallation testing is a must for both Off the shelf and web application services.
False
True
Question 70 Explanation:
Installation/Uninstallation testing is requried for off the shelf softwares which requires end users require to install the software. Incase of web application services, installation is done by the product development company and end users only use the services they dont install the application on the server.
Question 71
Installation/uninstallation testing will not include partial installation or upgrades as part of test.
False
True
Question 71 Explanation:
Partial installation and upgrades are also part of installation/uninstallation testing.
Question 72
Installation/Uninstallation testing can involve testing on various OS and hardwares.
False
True
Question 73
Objective of recovery testing is to check how an application recovers in an event of failure.
False
True
Question 74
Recovery Testing is also known as Failover testing.
False
True
Question 75
Recovery Testing scenarios can involve checking ability of software to recover from OS crashes.
False
True
Question 76
Recovery Testing scenarios can involve checking ability of software to recover post Hardware failures.
True
False
Question 77
Recovery Testing scenarios can involve checking ability of software to recover post network outages.
False
True
Question 78
Alpha Testing is done by end users.
False
True
Question 79
Alpha Testing is done before product or software is launched.
True
False
Question 80
Alpha Testing is done at development site.
False
True
Question 81
Alpha Testing is applicable mostly for Off the shelf softwares.
False
True
Question 81 Explanation:
Alpha testing and beta testing is also done for web applications, yahoo and google announced Alpha and beta test phases for their applications in the past.
Question 82
Alpha testing is done after Beta Testing.
True
False
Question 83
Beta Testing is done by end users.
True
False
Question 84
Beta Testing is done before product or application is launched.
False
True
Question 85
Beta Testing is done at development site.
False
True
Question 86
Beta testing is done after Alpha Testing.
True
False
Question 87
Ad hoc testing is an informal type of testing.
False
True
Question 88
Ad hoc testing can find defects that might not have been found by executing test cases.
False
True
Question 89
Ad hoc testing does not have documented test cases.
False
True
Question 90
Objectives of Ad hoc testing and exploratory testing are one and the same.
True
False
Question 91
Objective of Ad hoc testing is to find defects that were not reported so far.
False
True
Question 92
Ad hoc testing is a Black box testing technique.
False
True
Question 93
Regression testing is done to determine whether change in code has resulted in new defects.
True
False
Question 94
Regression test cases are usually not documented.
True
False
Question 94 Explanation:
Regression test cases are always documented.
Question 95
Regression tests are intended to find functional and non-functional defects.
False
True
Question 96
Regression testing is carried out on every build
True
False
Question 97
Regression tests can be broadly categorized as functional tests and unit tests.
True
False
Question 98
Another name of Regression test is Retesting.
False
True
Question 99
Regression tests are a good candidate for automation.
False
True
Question 100
Number of regression tests for a release depends on the extent of code changes.
True
False
Once you are finished, click the button below. Any items you have not completed will be marked incorrect.
Get Results
There are 100 questions to complete.
You have completed
questions
question
Your score is
Correct
Wrong
Partial-Credit
You have not finished your quiz. If you leave this page, your progress will be lost.
Correct Answer
You Selected
Not Attempted
Final Score on Quiz
Attempted Questions Correct
Attempted Questions Wrong
Questions Not Attempted
Total Questions on Quiz
Question Details
Results
Date
Score
Time allowed
minutes
seconds
Time used
Answer Choice(s) Selected
Question Text
All done
Poor! You need to brush up basics
Keep trying! There is lot to learn for you
Not bad! There is lot to learn for you
Good work! You know most of it but still there is scope to learn.
Perfect!
Note:
List of objective questions on types of software testing is contributed by Alok Tiwari (new guest writer)
Want to know how good you are at bug reporting ? Take a quick test and find out!!!
Congratulations - you have completed .
You scored %%SCORE%% out of %%TOTAL%%.
Your performance has been rated as %%RATING%%
Your answers are highlighted below.
Question 1
Do you report bugs in a bug tracking software or do you track bugs in a spread sheet that is stored on sharepoint or shared drive ?
Spread sheet in Shared Drive or SharePoint
Bug tracking tool
Hint:
Like QC, Clear Quest, Bugzilla etc.,
Question 1 Explanation:
Tracking bugs in a spread sheet will work for very small projects and will be very difficult to track changes. There are many open source and free bug tracking tools that can be used, it's time for you to suggest your project manager to use a bug tracking software.
Question 2
Are you allowed to report bugs directly in bug tracking tool, without bug report being reviewed by your peer or Test Lead ?
Submit bug independently
Submit bug after review by Peer or test lead
Question 2 Explanation:
If you are allowed to report bugs directly in bug tracking tool without it being reviewed by your peer or test lead, means your Test lead / Test manager acknowledges you can write good bug reports. If not, then you have to develop skills required for bug reporting.
Question 3
Do you understand Bug life cycle followed in your project and all the different states of a bug ? Can you draw flowchart of the bug life cycle right now (without referring to the bug tracking tool or any other documentation ) ?
Yes
No
Question 3 Explanation:
Understanding bug life cycle, defect states is very important and a must for testers and test leads.
Question 4
Do you write "Steps"/"Steps to reproduce" in all of your bug reports ? even for minor defects ?
Yes
No
Question 4 Explanation:
Steps / Steps to reproduce is a must for every bug report, we cannot presume that a developer will follow exact steps a tester to find the reported bug. Not including steps to reproduce increases changes or developer rejecting bug as not reproducible or reassign bug to tester to provide more details.
Question 5
Do you attach screenshots/snapshots of the screen and highlight/circle the text or error message ?
No, I do not attach screen shots as i provide details in steps
Yes, i attach screen shots but do not highlight/circle before attaching to bug report
Yes, i highlight/circle text or error before attaching screenshot to bug report
Question 5 Explanation:
Always attach screenshots, remembers a picture is worth 1000 words, make life easier for developer. Also screenshots serves as a proof.
Question 6
Before reporting a bug, do you always check in bug tracking tool if the bug you have to report is already reported by somebody ?
No (i dont think its needed, as developer will reject it if its duplicate)
Yes (I always check before reporting a new bug)
Question 6 Explanation:
Yes, during bug scrub, duplicate bugs will be caught and rejected. As a tester, it’s your responsibility to make conscious effort not to report duplicate bugs.
Question 7
Do you monitor for errors in error logs and attach relevant portion of the error log while reporting a bug ?
No (because i dont have access to error logs)
No (i dont as developers them selves can look into error logs)
Yes (i do monitor and attach error logs)
Question 7 Explanation:
Monitoring error log and attaching relevant portion of the error log enables the developer to analyze the issues faster.
Question 8
Do you maintain traceability matrix between Requirements, Test Cases and bugs, for the bug that you reported ?
No, I don't understand what traceability matrix is
No, we don't maintain traceability matrix in our project or company
Yes, I ensure traceability is maintained between Requirements, Test Cases and bugs that i report
Question 8 Explanation:
Traceability matrix is the key for success of a project. By maintaining traceability between Requirements, Test Cases and bugs, we can ensure all the related test cases and requirements are tested once the associated bug(s) are fixed.
Question 9
Do you check for Spelling and grammar before submitting your bug report ?
No (there is no provision in the bug tracking tool)
No (I don't think this is important)
Yes (I do for every bug report that I submit)
Question 9 Explanation:
Spelling and Grammatical errors should be corrected before submitting bug report. Otherwise you as tester pass on wrong message about you, your testing team to developers or anybody reading the bug report.
Question 10
Do you combine more than 1 bug in a single bug report ? e.g. you find cosmetic errors on Login page and Home page of the application, what would you do ?
Report 1 bug (Log 1 bug and mentioning both cosmetic issues in the same report)
Report 2 bugs (Log separate bugs for both cosmetics issues)
Question 10 Explanation:
Always log separate bug reports for bugs found on different functionality or on different pages. As developers responsible to fix issues can be different for each of the bugs reported in a single bug report.
Question 11
Do you mention details of the Test Data used for your testing in your bug report ? e.g. Account id, report start and end dates etc., that you used for testing.
Yes
No
Question 11 Explanation:
It is important to provide details of the test data used for testing, like Account number or Start and end dates for generating report etc., This will enable developer to differentiate between issues related to test data and code.
Question 12
Before submitting your bug report, do you review it thoroughly ?
Yes (Occasionally, when i am not Busy)
Yes (Always)
No (As i am busy)
Question 12 Explanation:
Before submitting bug reports, it is your duty as a tester to review your bug report thoroughly and ensure all the fields are filled correctly. As an example if you select incorrect release# by mistake then the bug may not be noticed by developers or during bug triage meeting.
Question 13
Do you make sometime to go through bugs reported by your peers, get to know about existing bugs and to provide feedback for them ?
No (Barely get time to complete my work)
Yes (I do go through bug reports reported by others and provide feedback when required)
Question 13 Explanation:
You get brownies if you are reviewing others defect, you are doing one of the tasks of a test lead!!! If you are a test lead then its your responsibility!!!
Question 14
Were there instances where you were asked by your project manager or test lead to correctly assess "Severity" of the bugs you reported ?
Yes (for 1 or more bugs in past 6 months)
No (none in past 6 months)
Question 14 Explanation:
Correct Severity should be assigned while reporting bug. You should always double check with your test lead or test manager on the severity when you are not sure on what severity to be assigned for a defect.
Question 15
When you discover a bug, do you repeat the same scenario with different test data or account etc., ?
No (report bug as and when it occurs)
Yes (will repeat test with different test data, but will not report bug if application works fine with different test data)
Yes (will repeat test with different test data, will log bug even if it works fine with different test data)
Question 15 Explanation:
It is always good to log defects even if you suspect test data is incorrect, it's developer's job to confirm if its test data issue. However, it is your job to try with different test of test data whenever test case fails and report your observations in the bug report.
Question 16
How do you get to know about fixed bugs that you need to retest ? By filtering in bug reporting tool or do you refer to Build notes ?
Bug reporting tool
Build notes
Question 16 Explanation:
Testers should always refer to build notes or email notification from project manager for the details on the bugs fixed in the current build. Defects marked as fixed in bug tracking tool might not have been migrated to Test environment.
Question 17
Do you try to minimize size of the attachment before attaching to the bug report ? e.g.: Zipping files reduces size, converting from Bitmap to JPG can reduce file size significantly.
No
Yes
Question 17 Explanation:
As a best practice all attachments should be zipped and attached to bug report. Do not attach screenshot as bitmap instead convert file to JPG and then attach to bug report.
Question 18
Do you participate in bug triage meetings ?
No
Yes
Question 18 Explanation:
Do not wait for somebody to invite you to bug triage meetings, ask your manager or test lead to allow you to participate in these meetings. In case they it’s a strict no, then go through the Minutes of meeting of bug triage meeting and discuss with your lead offline.
Question 19
In case one of the developers asks for a favour and requests you, not to log a bug that you found, what would you do ?
Will not submit bug in bug tracking tool
Will submit bug in bug tracking tool and report incident to project manager and test lead
Will convince developer and submit bug in bug tracking tool
Question 19 Explanation:
Testing team should log all the bugs they find.
Question 20
Do you add detailed comments in bug report when you change status of the bug (reopen, or close) ?
No
Yes
Question 20 Explanation:
Comments are very important in bug report. Looking at the comment history any stakeholder should be able to understand what was done with the defect. Comments should have date and name like [2012-05-12, Lakshmi] bug fix verified on build a.b.c and confirmed as fixed. Hence closing the defect....
Once you are finished, click the button below. Any items you have not completed will be marked incorrect.
Get Results
There are 20 questions to complete.
You have completed
questions
question
Your score is
Correct
Wrong
Partial-Credit
You have not finished your quiz. If you leave this page, your progress will be lost.
Correct Answer
You Selected
Not Attempted
Final Score on Quiz
Attempted Questions Correct
Attempted Questions Wrong
Questions Not Attempted
Total Questions on Quiz
Question Details
Results
Date
Score
Time allowed
minutes
seconds
Time used
Answer Choice(s) Selected
Question Text
All done
Need to learn more!
Keep trying!
Not bad!
Good work!
Perfect!!!
Readers,
Questions on Bug reporting is provided by Lakshmi (our guest author)
Software Testing Contest is a 90 day event conducted by softwaretestingsoftware.com, anybody having minimum of 6 months of experience in Manual Testing, Automated testing, Quality Assurance or Test management can write article(s) and submit to us at contactus@softwaretestingsoftware.com to compete in this 90 day Software Testing Contest. Articles for current contest can be submitted between today (29-Apr-2012) till (31-July-2012), results for the current contest will be announced on 5th Aug 2012.
Reasons for you to participate:
- Take the challenge : Give a try and bring out the writer in you, It’s a contest related to your profession, you need to participate !!!
- Encourages you to learn: To write an article, you have to recollect, prepare, learn more about the topic, before you can ink the article. Writing an article encourages you to make sometime from your regular schedule and learn more or something new related to the topic.
- Get Recognized: A good article demonstrates expertise and mastery of a subject. Get recognized in testing community for your knowledge and writing skills.
- Adds weightage to your CV : You can highlight such participations and contributions in your CV. Leaves a good impression on Interviewers, they will really appreciate your hobby of writing articles related to your profession
- It’s an accomplishment : No reward can be equal to the feeling of accomplishement and self belief. Feel proud to have written an article that will be read and appreciated by thousands of every month.
- Don’t be left out : If you don’t participate then others will, don’t be left behind, by not participating you just lose out on a opportunity to showcase your talent.
Why this contest ?
- We want softwaretestingsoftware.com to be a platform that encourages individuals to enhance their knowledge and reward people with best talent and knowledge on Software Testing, Automated testing, Quality Assurance or Test Management and other topics related to Software quality.
- Articles published on this site will be read by thousands of guests visting our site every month. Thereby enriching knowledge of people who are new to IT, software testing, automated testing or quality assurance.
What is the reward ?
Best writer gets a popular eBook on Software Testing or Quality Assurance or Automated Testing.
Rules for participating in Software Testing Contest:
- All the articles submitted has to be in English, should be related to Software Testing / Automated Testing / Software Testing Tools / Test Management / Test Estimation other any other topic related to Software Testing or Quality Assurance.
- Article should be a minimum of 750 words. Articles less than 750 words still gets published, however will not qualify for the contest. We have a cap on minimum number of words to ensure the articles are detailed and useful for readers.
- Articles can include flowcharts and diagrams, however picutres should not be a Trade Mark or patentented by others.
- Articles should be original and unique and should not be a copied from any websites or books or other sources that are printed or patented. By submitting article to softwaretestingsoftware.com, you acknowledge that the article submitted is your own and you will not submit the same article to other websites or books in future.
- All legitimate articles submitted for the contest will be published on www.softwaretestingsoftware.com along with the name of the Author, Only one article will be awarded as the best article for the Quarter. Decision of the panel in choosing best article is final, cannot be changed or cannot be contested in anyway.
- Each contestant can submit multiple articles for contest anytime within 90 days, every article is evaluated as separate, thereby increasing chances of your article being awarded as the best.
- Each contestant is free to select a topic. However, below is a list of suggested topics that you could choose, it’s not necessary that you have to limit to below topics, they are just suggestions.
* Embedded Testing concepts, tools etc.,
* Security testing concepts, techniques, tools etc.,
* Software Test Estimation Techniques, can explain a particular technique in details
* Game Testing
* Test Maturity Model
* Automated Test Tools, tips and tricks
* Performance Test Tools, identifying bottlenecks
* Overview of all Certifications related to Software Testing, QA and Automation
Below is an exhaustive list of questions asked during Manual Software Testing Interviews. These interview questions are submitted in our Software Testing Forum as well, click on “Answer” link against any of the questions listed below to answer the question to best of your knowledge or read answers submitted by others and provide your inputs.
1. What is Software engineering ? Answer
2. What is Test Case ? Answer
3. What is the difference between error, bug and Defect ? Answer
4. Why is V model called as V Model ? Answer
5. What is DFD (Data flow diagram) ? Answer
6. What is Flow chart ? Answer
7. What is regression testing ? Answer
8. What is retesting ? Answer
9. What is the difference between regression testing and retesting ? Answer
10. What are the different types of software testing ? Explain them briefly. Answer
11. What is SRS (Software requirement specification) document ? How is it useful for software testing team ? Answer
12. What is alpha testing ? Answer
13. What is beta testing ? Answer
14. How is Software Testing different from Software Quality Assurance ? Answer
15. What is Build, Version and Release ? Answer
16. Comeup with Test cases for Pen Answer
17. Comeup with Test cases for Gmail Answer
18. Comeup with Test cases for testing Google.com Answer
19. Comeup with Test Cases for testing Login page Answer
20. Comeup with Test Cases for Stapler Answer
21. What is unit testing ? Who does unit testing ? Answer
22. What is Equivalence Partitioning ? Explain with Example Answer
23. What is Decission table ? Explain with example Answer
24. What is BVA (Boundary Value Analysis) ? Explain with example Answer
25. What is Smoke Testing ? Answer
26. What is Sanity Testing ? Answer
27. What is the difference between Verification and Validation ? Answer
28. What is volume Testing ? Answer
29. What is localisation testing ? Answer
30. What is blackbox testing ? Answer
31. What is grey box testing ? Answer
32. How do you decide on Defect Severity ? Explain with examples Answer
33. What is latent bug ? Answer
34. What is the difference between bug reporting and bug tracking ? Answer
35. What are the contents of a good bug report ? Answer
36. what would you do if one or more requirements in requirements document are not clear for you ? Answer
37. What are the advantages of blackbox testing ? Answer
38. What are the disadvantages of blackbox testing ? Answer
39. What is usability testing ? Answer
40. What is the difference between SDLC and STLC ? Answer
41. What is the difference between Performance Testing and Stress testing ? Answer
42. What is the difference between Stress and Load testing ? Answer
43. What is Software Test Plan ? What are components of Test Plan ? Answer
44. what is pairwise testing ? When to use pair testing ? Answer
45. What is the difference between Test Bed and Test Harness ? Answer
46. What are non-functional requirements ? Answer
47. What is cyclomatic complexity ? Answer
48. What is Fish pond analysis ? Answer
49. What is installation/uninstallation testing ? Answer
50. What is fish bone chart ? Answer
51. What is six sigma ? Answer
52. What is the difference between Top down and Bottom up integration testng ? Answer
53. What is defect leakage ? Answer
54. What are the challenges you faced as Software Test Engineer ? Answer
55. How do you manage test data required for software testing ? Answer
56. What is Software Testing Life Cycle ? Answer
57. What are your responsibilities as Software Test Architect ? Answer
58. What is tracebility matrix ? Explain tracebility matrix that you have used Answer
59. What is the difference between Test Scenarios and Use cases in Software Testing ? Answer
60. Explain V model ? Answer
61. Is V model better than Waterfall model ? How ? Answer
62. What is integration testing ? Answer
63. What is compatibility testing ? Answer
64. Give example of high severity and low priority defect ? Answer
65. Give example of high priority and low severity defect ? Answer
66. What is bug life cycle ? Answer
67. What is a deferred defect ? Who decides to deferr a defect ? Answer
68. What does a defect report contain ? Answer
69. When do we start and stop Software Testing ? Answer
70. What is ACID property ? Answer
71. What is Exploratory Testing ? What are the benefits of Exploratory Testing ? Answer
72. What is monkey testing ? Answer
73. What is masked defect ? Answer
74. What is UAT (User Acceptance testing) ? Answer
75. What is peer review ? Why is it important ? Explain peer review with respect to Software Testing Answer
76. Do you have any certifications related to Software Testing ? Why haven’t you tried for one ? Answer
77. What is the difference between System testing and End-to-End testing ? Answer
78. What is the difference between SRS and BRS ? Answer
79. What is 3-tier architecture ? Answer
80. What is acceptance testing ? Answer
81. What is Ad-hoc testing ? What are the advantages and disadvantages of Ad-hoc testing ? Answer
82. What is security testing ? Answer
83. What is the difference between client server application and web based application ? Answer
84. What is the difference between CMM and TMM ? Answer
85. What is memory leakage ? How to test memory leakage manually ? Answer
86. What are the typical bugs that one would find while testing web based application ? Answer
87. What are cookies ? What would you test in cookies ? Answer
88. What are Test Scenarios ? Answer
89. What is defect life cycle ? Answer
90. What is SDLC ? Answer
91. What is STLC ? Answer
92. What is inspection ? Answer
93. What are the document required by Software Testing team ? Answer
94. What are the deliverables or artifacts created by Software testing team ? Answer
95. What is bi-directional Traceability matrix ? Answer
96. What are the bug tracking tools you have used ? Answer
97. What is Test Bed ? Answer
98. What is risk based testing ? Answer
99. What is SCM (Software Configuration Management) ? Answer
100. what are the qualities of a good Software Test Engineer ? Answer
101. What is stage containment in testing ? Answer
102. What is CMMI ? Answer
103. What is the difference between CMM and CMMI ? Answer
104. What are KPAs ? Answer
105. What is accessibility testing ? Answer
106. What are the minimum requirements for starting testing ? Answer
107. What is Agile development methodology ? Answer
108. If you come across defects that are not reproducible defects ? What do you do ? Would you report them ? Answer
109. What are your responsibilities as Software Test Lead ? Answer
110. How do you review Test Cases ? Answer
111. How do you manage software test environment ? What are the challenges you have faced related to test environment ? How did you resolve it ? Answer
112. What is the difference between 2-tier architecture and 3-tier architecture ? Answer
113. How do you derive Software Test estimates ? Answer
114. When would you update a Software Test Plan ? Answer
115. What is Test Strategy ? Briefly explain sections of a Test Strategy document ? Answer
116. What is Test Approach ? Briefly explain sections of a Test Approach document ? Answer
117. How do you decide on the test cases to be included in regression testing suite ? Answer
118. What is defect density ? Explain the formula Answer
119. How do you define Entry and exit criteria for Software Testing ? Answer
120. What is release notes ? What do you check in release notes ? Answer
121. What is the ideal duration you would suggest between builds for Testing ? Answer
122. Why most of the companies prefer Manual testing over automated testing ? Answer
123. What if a developer denies to fix a bug ? What would you do ? Answer
124. What is the difference between Risk and Issue ? Answer
125. What is Risk ? What is Risk Analysis ? What are the common risks associated with Software Testing ? Answer
126. How are Risks categorized ? Answer
127. What is IV&V ? Answer
128. What is extreme testing ? Answer
129. What are the differences between Reviews and Walkthroughs ? Answer
130. What is the difference between Functional and System Testing ? Answer
131. What is Test Coverage ? How do you meausre Test Coverage ? Answer
132. What is the difference between Smoke and Sanity Testing ? Answer
133. When do you conclude testing is complete ? Answer
134. What are the challenges associated with localisation testing ? Answer
135. What is fuzz testing ? Answer
136. Would you allow released to be deployed without testing ? If yes, in what scenario ? Answer
137. What are the challenges faced by Software Testers at client location ? Answer
138. What is the difference between Testing Techniques and Testing Methodology ? Answer
139. What is metrics ? What is the use of metrics for Software Testing phase ? Answer
140. What are the Software Test Metrics related to Software Testing that you would generate ? Answer
141. What is Test Closure report ? When is it created ? What does it contain ? Answer
142. What would you suggest to do when environment is setup and handedover to Testing team for testing ? Answer
143. What is bug triage ? What is your role in bug triage meeting ? Answer
144. What is Integration test plan ? Explain sections of Integration Test Plan ? Answer
145. What is FURPS ? Explain it with example of Login screen Answer
146. What is test policy document ? Answer
147. What does a Software Test report contain ? Answer
148. What is Cost of Quality ? Answer
149. What are your responsibilities as Software Test Manager ? Answer
150. Do you have any certifications related to Project management ? Why haven’t you tried for one ? Answer
151. What are your responsibilities as Software Test Architect ? Answer
Thank you very much Lakshmi for compiling list of frequently asked Software Testing Interview questions and taking your time in posting them in software testing forum. Readers, if you have more questions which are not already covered in the above list, you can email them to contactus[at]softwaretestingsoftware.com.
This is one of the common questions asked during software testing interview. Interview candidates may wonder for a moment whether I am attending an interview in a Software testing company or in a Pen manufacturing company !!!. This question is asked by interviewers to tickle your grey cells and check your ability to think and come out with different possible test scenarios at the same time trying to access how realistic your test scenarios are. Interviewer is well aware that if you can come up with good set of test scenarios for a testing a Pen then you can come up with good test scenarios for any other given application to be tested. Of course interviewer might not expect that you have read this article and came prepared for this surprising question
So here is how I would start answering this question…
Firstly, we need to understand requirements against which pen was created. Our test scenarios for pen should be based on these factors like Type of Pen (Ball point, Ink or Felt tip), functionality of the pen, Compatibility, Installation and Un-installation, Performance and Usability. Since I don’t have requirements for the Pen to be tested, I presume the pen being tested is used by normal people and it would be used for their day to day writing needs and not somebody like an astronaut in space with 0 gravity or a deep sea diver who wants to write underwater.
Below are the test scenarios for Pen to be tested, I have categorized on the type of the Test.
Test Scenarios for Functionality:
1) Verify “type of Pen” (Ball Point or Ink or Felt tip) etc., Let’s assume it’s Ball Point pen as further scenarios will change based on the Pen type.
2) Test Pen colour is as per specification
3) Test if the ink colour is as per specification.
4) Test ink impression/colour on paper remains consistent from start till ink in the refill gets over.
5) Test Dimensions of the Pen, Size length and Shape of the Pen meets the requirements.
6) Test if pen writes smoothly and continuously without breaks or blots on the paper.
7) Test if ink on paper dries quickly as per requirement (assume less than 1 second as per requirement)
8) Test if the thickness of the line drawn by the pen tip is as per specification. (0.4 mm etc.,)
9) Keep ballpoint of the pen in contact with paper for considerable amount of time and check if the ink blots.
10) Write on different type of paper (smooth, rough, card boards etc.,) and confirm pen writes correctly on all types of papers.
11) Check if the pen cap has a gripper, so that user can plug the pen to shirt pocket firmly.
12) Test if ink is waterproof. Write on paper, dip paper in water and check if writing/ink has faded or smudged.
13) Verify that the ink used does not have bad odor because of the chemicals used in the ink.
14) Check weight of the pen is as per requirements.
15) Test pen can be used for writing with various angles like straight, slant etc.. Different writing angle should not impact the quality of the impression made on the paper nor should the pen tip be damaged.
Performance test scenarios:
1) Test if Pen works in extreme temperatures like less than 0 degrees and at higher temperatures like 60 etc.,
2) Test if pen works in higher and lower altitudes i.e. in different gravity.
3) Test if pen works with lower and higher atmospheric pressures. Ink may not flow evenly in lower or higher atmospheric pressures.
4) Test if the pen functions if it is used for writing continuously for longer duration (say for 10 hours).
5) Keep scribbling on paper vigorously and continuously for several minutes to check friction on the ball does not damage the pen tip.
6) Test how much can be written using 1 complete refill. Measure the distance it can write and compare it with specification.
7) Test if ink dries up if pen is kept open (without cap) for longer duration.
8) Dip pen in water for considerable amount of time, take it out, dry it out in open air and write. Verify pen still writes without any issues.
Load test scenarios:
1) Drop the pen from reasonable height say about 5 to 6 feet multiple times with different angles like Pen tip hitting the floor dead on and pen falling flat on ground etc., Verify pen is not broken and pen still writes without issues.
2) Press the pen hard on to surface while writing, check if pen still writes and Pen tip or pen itself does not break.
3) Drop pen on the ground, stamp it to test if it can bear reasonable external weight (e.g.: up to 100 Kgs). Verify pen is not broken and still writes as expected.
Compatibility Test Scenarios:
1) Write on different types materials like leather, cloth, plastic sheet, and rubber etc., Verify ink dries quickly.
2) Test compatibility of refills of same and other brands.
Installation and Un-installation Test Scenarios:
1) Disassemble and assemble pen. Remove cap, remove refill etc., and put it back. Test if the pen writes as expected.
2) Change Refill and Test if the pen writes as expected.
Usability Test Scenarios:
1) Test if Pen is usable across age (Children to aged) and by different Professionals like Lawyers, Doctors, and Businessmen etc. can write comfortably with the pen.
2) Check with different audience if the colour and dimension of the Pen is acceptable for their usage or profession.
3) Test if ink leaks from refill when pen is kept upside down for longer duration.
4) Test materials used in pen is recyclable.
5) Test to see if there are smaller parts in the pen that people can accidentally swallow, especially children have tendency to stick rear end of the pen in their mouth while thinking and some people have the habit of chewing pen as they think.
6) Test external material of the pen is made of non-toxic material.
This article is written by our guest author Sunil Reddy. Sunil is a Test engineer at an MNC in Hyderabad.
23/03/2012 (Hurry apply today, share this with your friends as well)
Job Location
:
Bangalore, India
Position
:
ASE (Associate Software Engineer) ( for Freshers)
Job Description
:
Company : Tesco Hindustan Service Centre (HSC)Tesco is the world’s third largest retailer. Tesco Hindustan Service Centre provides IT, business, finance and commercial services that drive Tesco’s global operations.The Tesco Hindustan Service Centre (HSC) is the Global Services Arm for Tesco. The centre sits at the heart of the Tesco group, and provides IT and Business services to Tesco operations across Europe and Asia. Tesco was the first major international retailer to have a fully-owned support centre in India. Our core purpose at Tesco is to create value for our customers to earn their lifetime loyalty and Tesco HSC is dedicated to supporting those values by providing great service to our internal customers.
Benefits at Tesco HSC
NO PROBATION PERIOD – Every employee who joins us is confirmed from day one
30-DAY LEAVE POLICY – As opposed to the market standard of 22 days
PROGRESSIVE PEOPLE POLICIES – We provide our employees with higher education assistance, adoption leave and paternity leave; Crèche within our facility; Gym facility; Counseling service and more
GRATUITY AFTER 3 years – Unlike the market standard of 5 years.
There are many Software Methodologies available and each one describes a set of guidelines to give good results. Fig 1 (below) shows list of main drivers involved in any SDLC model.
A common observation in any SDLC process is that the output (Final Product) varies despite well defined resources, references and Guidelines. The output varies because of intangible factors – Tester and Developer. In any Software, one tester can find crucial issues while other cannot. One developer can resolve an issue without impacting other areas while other cannot. This defeats the Final Aim – get a Green Signal from the Client (affecting the client’s impression and Business returns)
Fig 1
Tester’s approach
I have tested software in different domains and used various testing techniques. When software is released or testing, the tester has intent of breaking the software. The mind-set of a tester can be defined as “Testing is the process to prove that the software doesn’t work”. Once the software testing cycle is completed, the final step is acceptance by client. That’s the only time a tester does not want any defect to be found in Software. Tester and client (another tester) will not test the same scenarios and find the same bugs.
Developer’s Approach
Developers mostly work in groups on any software. They work on existing code base without knowing all the impact areas of entire software. A Developers mind-set is “Delivering the optimal solution with the time and options available”. Unit Testing only allows to cover the good working flow (A developer wants the test to work as they have already done the best that could be done). A developer cannot know all the tests to be run and all impact areas of code.
Problem
SDLC Techniques cannot guarantee 100% results. Despite the best efforts, tester cannot find all issues and Developer cannot know all issues. This result to 1 conclusion – Issues are reported by client during acceptance tests or later in the field. This is bad if we talk about client’s impression and impact on Business, we have to consider a fail-safe mechanism.
Solution
Predictive Testing focuses on the intangible factors involved in SDLC – Testers (Clients/Third Party/In-House) and Developers. It delivers a fail-safe assurance to get a fast acceptance
For a developer and tester, it involves analysis of types of issues found by client (another tester) and test scenarios identified. Based on this information, a testing pattern can be created which will predict the tests to be run by Clients/Third Party
Benefits
1. There is no way to give assurance of software but we can use concept of Predictive testing to ensure that software is fail-safe in Acceptance tests.
2. It is time-effective where testing coverage can be limited to Predictive tests and ensure the Software is given a Green signal by Clients.
3. It reduces the number of iterations of software to clients before final acceptance
4. It improves the perception of Product Quality and impression of client.
Case Study
Being in testing team, we were responsible for testing and clearing the software when we believe its good enough. Next step was sending the software to clients for acceptance where another set of tests were run. Clients don’t share the test scenarios they would be running to validate the software (else it would be so easy). After Client testing, they would share the defects with us. The defects are fixed and tested before giving the next version of software to the client.
The Defects reported by client were analyzed to give the below conclusions –
1. Few areas of software were tested more than others
2. Testing was done in an iterative manner (the depth of test scenarios was higher with each iteration)
3. Same tests were run again after a set of iterations
4. The environment used in client lab was not same as testing environment.
Based on above observations and defects, an acceptance test plan was created. This Test plan would focus only on relevant features (as understood from defects). The coverage was limited in terms of depth of tests.
The number of iterations were reduced by 80% and resulted in better client relations and more business.
To conclude, this technique is not a solution to delivering good software but adds values to make better software by extending the test coverage.
This Article on Predictive Testing is contributed by our guest author Manendra.
Softwaretestingsoftware.com was started during April 2010 and we have received a huge response from readers as well as people who write articles for this site. Several readers have provided feedback stating that the articles are good to read but they also need a provision where they can questions and discuss on a topic. In response to this demand, we created Forum for our website visitors.
This is a site that has been built by people like you for testing community. I thank all the visitors and authors who have contributed for this site.