Latest Manual Testing Interview Questions and Answers 2015 - H2kinfosys

Job Oriented– Instructor Led – Face2Face – True Live Online I.T. Training for Everyone Worldwide
www.h2kinfosys.com|| Training@H2KInfosys.com
H2kInfosys
H2K Infosysprovidesonline IT training and placementservices worldwide.
www.H2KINFOSYS.com
USA- +1-(770)-777-1269, UK – (020) 3371 7615
Training@H2KINFOSYS.com / H2KInfosys@gmail.com
DISCLAIMER
H2K Infosys, LLC (hereinafter “H2K”) acknowledges the proprietary rights of the trademarks and
products names of other companies mentioned in any of the training material including but not limited
to the handouts, written material, videos, power point presentations, etc. All such training materials are
provided to H2K students for learning purposes only. H2K students shall not use such materials for their
private gain nor can they sell any such materials to a third party. Some of the examples provided in any
such training materials may not be owned by H2K and as such H2K does not claim any proprietary rights
for the same. H2K does not guarantee nor is it responsible for such products and projects. H2K
acknowledges that any such information or product that has been lawfully received from third party
source isfree fromrestrictionandwithoutanybreachorviolationof law whatsoever.
Manual Testing Interview Questions and Answers

Job Oriented– Instructor Led– Face2Face – True Live Online I.T. Training for Everyone Worldwide
USA: +1-770-777-1269 Email: Training@H2kinfosys.com UK: 020-33717615
1. During testing, youfinda bug and assignedit to developer. But developer
rejects the bug saying that it is not a defect. Howyou will handle this situation?
Ans: First of all bugs should be logged with proper reproducible steps, screen shots etc…
If developer rejects the bug, then first thing to look out for is the reason or justification on why
the bug was rejected. If the justification is valid I would agree for the rejection. However, if the
reason is not justified then, I will go back and try to reproduce the bug with the steps I had
provided earlier. If it is still reproducible, I shall reopen the bug with valid comments and will
provide additional information if I found any. Then I would go back to the developer asking for
justification on the rejection. At this point I shall include BA and technical lead also is to take
confirmation on the defects
2. If there is no enough time for test execution, howwill youapproach?
Ans: If there is no enough time for testing, my first focus will be on the priority of the
requirements. The functionality which is the most important for the release would be the first
tested. Next I would focus on the areas where the probability of finding defects is high. I would
also analyze by test cases and execute the high priority test cases first followed by medium and
low if time permits. If I know the application well and have previously worked on it, then
exploratory testing is a good approach when there is no much time. All these should be
approved by the Test Manager and should be documented in the test strategy.
3. What is QA role in each phase of SDLC?
Ans: It is always a good approach to include QA from the first phase of SDLC. In requirement
planning and analysis phase QA gets involved in document review of requirements (SRS). This
will help in understanding the requirement right from the early stages. In Design phase, the
main task is to prepare the Test Plan, Test Strategy. We can also come up with test scenarios in
this phase. During development phase QA will break the test scenarios into test cases. Test
data, test scripts, test environment setup etc… is done in this phase. Various kinds of testing is
performed during the test execution phase and defects are logged. Defects summary reports
and generated and sent to the team. We closely work with the development team in closing the
bug. During the maintenance phase test summary report is sent to all the stakeholders and we
also participate in the lessons learnt sessions

4. What is exit criteriaof testing? /Whento stoptesting?
Ans: It is not possible to ensure that an application is 100% free of defects. At some point the
testing should be stopped and we have to give a sign off so that the application can be released.
The exit criteria of testing will be mentioned in the Test Plan before testing itself. We consider a
lot of criteria to decide when to stop the testing. For example the project timelines (we cannot
test endlessly, testing cycle should be estimated by keeping the project release dates), All the
defects have been addressed and closed, all the test cases have been executed, traceability
metrics is done (which means test cases have been executed for each of the requirements).
These are some of the factors which are considered for stopping the testing.
5. Whendo we start testing?
Ans: It is always better to start the application right from the beginning of SDLC rather than
waiting for the testing phase. Because the cost of defect fix increases based on the time it was
found. Start of testing activities would start from Analysis phase itself. There we will involve
ourselves in understanding the requirements. Once test plan, test cases etc… are written, it is
always better to get involved in the unit testing itself. In addition to in during testing phase
testers will not simply start testing. Testing would began when the testing entry criteria are
met. For example developers should stop the coding and code freeze should be done. We
cannot test if developers are working on the application and have not finished their coding.
Also they need to deploy the code in a separate environment and proper release notes should
be sent.
6. Have you writtenany test plan? What are the contents of test plan?
Ans:Yes I have been involved in writing test plan. Test plan will contain the scope and all the
activities of testing. The main contents of test plan is testing scope, testing approach, resources
and testing schedule. In testing scope we will say the testable and non-testable functionalities.
In testing approach we would mainly mention the testing environments, different kinds of
testing, testing cycles, the test cases which will be executed, testing data and scripts etc…It will
also say the test entry and exit criteria. Which means when testing will be started and stopped.
The roles and responsibilities of each resources would be mentioned and testing schedule and
timelines are also mentioned in the test plan. In addition any risk/assumptions and
dependencies are also mentioned in the test plan.

7. ExplainSTLC?
Ans: Software Testing Life Cycle is a testing process which is executed in a sequential manner
to meet the testing goals. There are different phases of the STLC. Each phase will have different
activities and deliverables. Different phases of STLC are
Test Planning Phase: Here testing objectives are defined and we come up with the test plan. In
this phase we will check on automation feasibility, we will prepare the test plan and test effort
estimation.
Test Analysis and Design Phase: In this phase we will do the test case designing, write test
scripts, prepare the test data. We will make the test environment ready
Test implementation Phase: Actual testing is done in this phase. Different types are testing is
executed, test results are shared and bugs are logged. Re-testing and bug closure is also done in
this phase. We will come up with test results and bug report in this phase
Test Exit Phase: In this phase we will verify if more testing is required. Testing closure activities
are carried out in this phase. Test summary reports and testing metrics are created and shared
to the stakeholders in this phase.
Test Closure Phase: Once the test exit criteria is reached, in this phase we will archive all the
documents that we have prepared from the beginning. So that it can be used later. Lessons
learnt sessions are done in this phase so that we can know what went well and what can be
improved so that upcoming releases are smoother.
8. Have you done any reviews for QA deliverables?
Ans: Yes, I have reviewed QA deliverables mainly test plan and test cases. QA checklist is
maintained for each of the deliverables and the reviews will happen against the checklist. First
of all for all the deliverables that I prepare, I do a self-review. Then I would give it to my team
member who does the peer review. Similarly I have also done peer reviews of my team mates
documents. Before the review walkthrough of the document is done so that it becomes easier
to read the document. My team maintains a checklist which needs to be given important during
the reviews. For example if I am reviewing the test plan, I ensure that areas to be tested and
non-testable requirements are properly documented. All the test cases and test data is
inserted, risk and dependencies are described etc… During reviewing test cases my focus will

be first to check the requirement traceability, which means for each requirements if the test
cases are available. Next my focus will be on test coverage. I will check of all the scenarios have
been covered etc…
9. What is the difference betweenverificationandvalidation?
Ans: Verification means “Are we building the product right?” and validation means “Are we
building the right product?”
Which means in verification the focus will be are we building the product based on the
requirements and design. Where as in validation the focus is on is the product behaving
properly (in terms of customer expectation).
Verification examples: reviews, meetings
Validation example: testing (different types of testing)
10. What is difference betweenregressionandretesting?
Ans: Regression testing: Once the application is changed (for example after fixing a defect or
some enhancement is done), we need to test and ensure the existing functionalities are
working fine. This is called regression testing. For example if a new text box is added to a web
page. Then we have to ensure the look and feel is not disturbed after introducing the text box
also other fields which were already there in the page is working as expected. This is regression
testing
Re-testing: after a defect is found by testers and then fixed by developers, it is again tested to
confirm that the original defect is actually fixed. Retesting is done to make sure that the test
cases which were failed earlier due to some defect is now passing after the defect is fixed.
11. Give me examples for high severity, highpriority andlowseverity, low
priority defects inyour current project?
Ans: Severity: How the bug impacts the application. How critical defect is and what is the
impact of the defect on the whole system’s functionality. The severity is a parameter set by the
tester while he opens a defect and is mainly in control of the tester.
Priority: It defines the priority in which the defects should be resolved. if there are multiple
defects, the priority decides which defect has to be fixed and verified immediately versus which
defect can be fixed a bit later. It is usually set by the lead

Examples
High Priority, Low Severity bug :- If the company name is misspelled in the home page of the
website, then the priority is high and severity is low to fix it.
High Severity, Low Priority :- Web page not found when user clicks on a link (user's does not
visit that page generally)
Low Priority, Low Severity :- Any cosmetic or spelling issues which is within a paragraph or in
the report
High Priority, High Severity :- An error which occurs on the basic functionality of the application
and will not allow the user to use the system(E.g. user is not able to login to the application)
12. What are all the testing types youperformedonthe current application?
Ans: I have been performing functional, non-functional, confirmation and regression testing
Functional Testing: - is the testing of the functionality of the software against the requirements
(E.g. black box testing)
Non Functional Testing:- is the testing of behavioral characteristics of the software like
reliability, usability, efficiency etc…(E.g. performance testing)
Confirmation testing:- also known as retesting is done on the new build to verify that the
reported defect is fixed in the new build. (E.g. retesting)
Regression testing :- is execution of steps that were previously executed. The difference is that
the tests that were passed previously are again executed so as to ensure that no new defect is
introduced in the process of fixing new defects.
13. What are all the possible test cases for the requirement:username will
allow 4-12 alphanumeric characters?
Ans:
 Testcase with4-12 alphanumericcharacters
 Testcase withonly4-12 alphabets
 Testcase withonly4-12 numeric
 Testcase with4 alphanumericcharacter
 Testcase with12 alphanumericcharacter

 Testcase withlessthan4 alphanumericcharacters
 Testcase withmore than 12 alphanumericcharacters
14. What do you mean by release notes?
Ans: Release notes is document which is released to test team at the time of test execution
phase or during UAT. Release notes document new features, enhancements to functionality,
and bug fixes. It is written by the tech lead. It will contain :-
 Information on what functionalities are released for testing
 Specific test data if any
 Any enhancement
 User guide
 Defect fixed
 Defect which is deferred
 Deferred opened
15. Explain the different bug status available inthe defect life cycle?
Ans:
NEW: When the bug is found by the test and logged, its status will be NEW.
ASSIGN: Once the tester logs the bug, the lead validates the bug and assigns it to the
development team. Then the status of the bug is set to ASSIGN

OPEN: When the bug is assigned to the development, while he is analyze the bug that time he
will put the status to OPEN.
TEST/READY to RETEST: Once the developer fixes the bug, he changes the status to READY TO
RETEST. This means developer has fix the issue and is ready for the test team to retest the
defect.
VERIFIED: Once the tester retest the bug and is found to be fixed, he changes the bug status to
VERIFIED.
REOPENED: While retesting if he find the bug still exists, then he changes the bug status to
REOPENED.
CLOSED: Once the bug is fixed and the status is VERIFIED. Then lead changes the status to
CLOSED.
REJECTED: When the bug is in OPEN status, and if developer feels the bug is not genuine or
found to be DUPLICATE, he can reject the bug and the status of the bug is REJECTED.
DEFERRED: Sometimes the developers will accept the bug, but may be due to the priority,
severity or due to time he may push the fix to other releases rather than the current release.
Then the bug status will be DEFERRED.
16. What do you mean by deferredstatus of abug?
Ans: Deferred status of bug means, it is a valid bug and accepted by the development team.
However the fix will not be available in the current release. The fix will be made available in the
upcoming release. The reason to make the bug to deferred status is due to few factors. Some if
the reason is because the priority of the bug may be low, lack of time to fix the bug in this
release, or the bug not have a big impact in the application.
17. Which model you are using for the testing?
Ans: I have been exposed to both SDLC and Iterative model projects. One of my projects
follows waterfall model. In waterfall model each of the SDLC phases (Analysis, design,
development, testing and maintenance) is executed sequentially. Which means each phase
starts only when the previous phase is completed. No two phases used to run in parallel.

But there are also projects which do not fit SDLC, wherein we work on iterative model. In one of
the project I work with Agile model. Here we will have small incremental releases and many
different iterations. Testing is integrated throughout the cycle.

18. What is the difference betweentest case anduse case?
Ans:
19. Which documents are requiredtostart writing the test cases?
Ans: Most important documents needed to write the test cases are the SRS, BRD and user
cases. SRS contains all the software requirements for the release and BRD contains the business
requirements. These two is very helpful in writing test cases and ensures that test cases related
to system and business is met. User cases gives the requirement flow based on which we can
write various scenarios for a particular requirement.
Test Scenarios are also very helpful in ensuring all the scenarios are covered in writing the test
cases. It is also best practice to visit the test Plan to understand the test data, test scripts,
functionalities in scope and out of scope in writing the test cases.
20. What is configurationmanagement and whichtool you usedfor this?
Ans: Configuration Management is detailed updating of information. It usually has version
control and also base lining is done. It helps in identifying what has changed and who had done
the change, I have had the opportunity to use configuration management of test cases, test
results and defects through Quality Center, TFS and WinCVS
Test Case Use Case
Test case is a detailed step by step instruction
on how to test a particular functionality of an
application.
Use case is the flow of the application based on
business perspective.
Test cases are usually prepared by using the
use cases.
It is usually embedded in SRS or comes as a
separate document.
Test cases are prepared by software tester. Use case is prepared by the business analyst.
Test cases are derived from use cases and is
executed later.
Use cases cannot be executed, which means
using use cases we arrive at test cases.
Test cases are not represented pictorially. It is a
step by step instructions.
Use cases are pictorial representation of the
business flow.

21. If one Project is giventoyou for testing andIf you have to performManual
testing andAutomationtesting onfewof the modules as per givenSRS. Can we
do automation purely on that application!?
Ans: If for a project both manual and automation testing is to be given. Then it is not possible
to do only automation testing for the application. Automation cannot be performed on the new
features or enhancements or changes. In these areas manual testing would be performed.
Whereas automation will be used to execute repetitive test cases for e.g. existing
functionalities which is regression testing, automation would be in scope.
22. How you will take decisionthat whichtool will fit for your existing project;
which factors we needto consider for tool support?
Ans: The selection of the automation tool depends on various factors like
 Application and its technology on what needs to be tested.
 Detailed testing requirements
 Skill sets available
 License cost of the tool
 Tools usage :- We need to determine if the tool satisfies the testing needs. Which
means if the tool can be used for web based and desktop application as well as mobile
testing
 Does the tool support easy interface to create and maintain scripts?
For example, QTP can be selected if the application supports many platforms and seleniumcan
be considered for web based testing.
23. Explain Equivalence partitioning withexample.
Ans: Equivalence partitioning is a black box testing technique. In this technique we will test
only one condition for each partition. If the condition is pass, then we consider all conditions
within that partition/class to be pass. Similarly if the condition failsthen we assume that none of
the conditions in that partition will work
For example: Consider a text box which will accept numeric data of 4-10 characters. In this case
there will be 4 equivalence partition.

 Valid partition of numeric data 4-10
 Invalid partition of less than 4 digits
 Invalid partition of more than 10 digits
 Invalid partition of alphanumeric characters
We can take just value from each partition and then do the testing rather than doing all the
combinations.
24.Write down the guidelines todevelopgoodGUI test cases:
Ans: GUI testing is very important to test application user interface. Following points should
be kept in mind while coming up with GUI test cases
 How the application handles keyboard and mouse events
 How menu bar, buttons, text boxes, list box, combo box, images etc. reacts to
user inputs and if it performs its action in the desired manner.
 Importance should be given to check the font type, size, colors, spell checks etc…
 Focus should be given in created test cases that the user control look and feel is
proper.
 Test cases should be developed to check the shortcut keys are working
25. Write down the guidelines toderive positiveandnegative test cases
Ans: Test cases should be developed for each use case scenarios. Guidelines to arrive at
positive and negative test cases are:-
Positive Test Case
 Main intension of writing positive test cases is to check the application meets the
requirement specifications.
 When writing positive test cases, we need to validate it against valid input data.
 While arriving at positive test cases, focus should be on if the application behaves as
expected with its valid inputs.
 E.g. of positive test case. If the requirement says a text box can take only numeric value.
Then to test the text box with numeric data becomes your positive test case
Negative test case
 Main intension of writing negative test cases is to check if the how the application
behaves with negative inputs.

 When writing negative test cases, we need to validate it against invalid data.
 Negative test cases should be written keeping negative point of view & only execute the
test cases for only invalid set of input data.
 E.g. of negative test case. If the requirement says a text box can take only numeric
value. Then to test the text box with alphabets becomes your negative test case
26. How risk is relating totesting ;explaintypes of risks.
Ans: To save time and money you should be able to prioritize your testing work. Prioritization
of testing is done based on the risks. prioritizing the test cases, test techniques like boundary
value analysis is part of risk based testing. Some of the different types of risks are
 Schedule risk: -Schedule can slip due to wrong estimation, failure in identifying complex
requirements, resources not allocated properly.
 Budget risk: - This happens due to incorrect budget estimation, incorrect project scope
etc...
 Operational risk: - Risk due to improper process implementation. This can happen due
to not setting the priority of requirements, not distributing the roles and responsibilities
propely, no resource planning, no training, miss-communication in the team.
 Technical risk: - This can lead to failure in the functionality and performance. This
usually happens due to continues changing requirements, complex requirements etc...
27. Explain Performance Testing VS Stress Testing :
Ans:
Performance Testing Stress Testing
Testing to evaluate the performance of the
system in a specific situation
Testing to evaluate application behavior during
peak load conditions.
It is basically done to set the benchmark &
standard of the application
It is basically testing the functionality of the
application under high loads
E.g. To check the time taken to load the webpage
on different internet speed
E.g. To check the login page with 100 login
attempt at the same time

28. ExplainAlpha testing VS BetaTesting
Ans:
Alpha Testing Beta Testing
Alpha testing takes place at developers site It takes place at customer’s site before the
release of the application
Sometimes it is also performed by
Independent Testing Team
It is not performed by Independent Testing
Team
It is always performed in Virtual
Environment
It is performed in Real Time Environment
Minor design changes can still be made as
a result of alpha testing
The goal of beta testing is to place the
application in the hands of real users and
check for flaws or issues from user point
of view
It is always performed within the
organization.
t is always performed outside the
organization.
29. Explain merits anddemerits of Agile methodology
Ans: Agile model is a type of incremental model. Unlike the waterfall model in agile model
very limited planning is required to get started with the project.
Advantage Disadvantage
Customer satisfaction The project can easily get taken off track if the
customer is not satisfied
People and interactions are emphasized rather
than process and tools
It is difficult to assess the effort required at the
beginning of the software development life
cycle.
Customers, developers and testers constantly
interact with each other
More management effort is required to monitor
and control everyone’s activities.
Working software is delivered frequently There is lack of emphasis on necessary
designing and documentation
Even late changes in requirements are
welcomed
The final product can be different than what was
initially intended.

30. Explain Exhaustive Testing inbrief.
Ans: It is a type of testing where we try to check the output of the software by entering all the
possible inputs. Exhaustive testing is usually done when the programs and the scope of project
is small. Exhaustive testing is time consuming and costly
******************************************************************************
*****************************************************************************
1) If you don't have enough time totest, what you will do?
2) Who wrote test plan? Who we? Testers > team lead? Why lead prepare, can u able to
prepare?
3) Can you give examples of SQL queries you wrote?
4) Did you face any issues with any of your team members? Developers?
5) Explain more details about your recent project and related functionality you tested?
6) What kind of issues is found while testing the recent project?
7) How the data is pulled from savings account? How you know the data is correct for the
savings account?
8) Give example of query how you pulled the data?
9) Are you familiar with ETL Testing process and data ware house? What you know?
10) Where the requirements are written for ETL? Are you familiar with mapping documents? I
am asking about mapping documents? I want to know you are familiar with this? Where the
requirements are written?
11) What tools are used for ETL process? Any other tools?
12) Are you familiar with BI reports OR crystal reports?
13) How do you validate the reports?

14) How many test cases you wrote on the recent project?
15) How to confirm that you covered all the requirements?
16) Do you know when to end the testing?
17) Did you worked on agile development environment? Can you talk about what is agile?
18) What development methodology you worked? Like waterfall? V-Model? Agile?
19) If not necessary to do all testing what you do?
20) What are your strengths and weaknesses?
21) Why you choose QA as your career?
22) Mobile application testing?
23) Are you familiar with Selenium automation?
24) Do you have any experience with JMeter?
25) Do you have any experience with Web Services and Soap UI Tool?
26) How do you identify the regression test cases?
27) Are you familiar with UNIX and Linux commands?
28) Where are you currently located?
29) How is the weather there? Do you like cold?

Latest Manual Testing Interview Questions and Answers 2015 - H2kinfosys

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (8)

Similar to Latest Manual Testing Interview Questions and Answers 2015 - H2kinfosys

Similar to Latest Manual Testing Interview Questions and Answers 2015 - H2kinfosys (20)

Recently uploaded

Recently uploaded (20)

Latest Manual Testing Interview Questions and Answers 2015 - H2kinfosys