Manual Testing Interview Questions

1) Explain system testing.

System testing is performed to verify that a system meets the requirements specifications. It
checks the behavior of the whole system, based on the defined scope. It is very common for
system testing to be the last test that is performed by the development team before it is
released.

2) Explain the difference between regression testing and retesting.

Retesting is the running of tests that failed in the previous round of testing to verify that the
corrective actions taken were successful in fixing the defects that were found. Regression
testing, on the other hand, is checking a program after the modifications have been made to
ensure that no new defects have been introduced into the system.

3) What is a test suite?

A test suite is a set of test cases that is designed for a system or a component of software,
where the result of each test is used as input to the next.

4) Explain the difference between testing and debugging.

Testing can consist of both static and dynamic testing life cycle activities. It is used to
determine that the software satisfies the requirements. Debugging, on the other hand, is the
process of identifying, locating, and fixing a defect in a system or application.

5) Explain boundary analysis.

Boundary value analysis is a software testing technique where tests are designed for checking
the boundary limits of the application. Test cases that are prepared for boundary value
analysis are used to check bugs that may arise at the boundaries or just over the boundaries.
This design strategy typically used as a part of black box testing.

6) Differentiate between QA and QC?

QA:
It is process oriented
It involve in entire process of software development.
Prevention oriented.
QC:
It is product oriented.
Work to examine the quality of product.
Deduction oriented.

7) What is a bug?
A computer bug is an error, flaw, mistake, failure, or fault in a computer program that
prevents it from working correctly or produces an incorrect result

8) What is a test case?

Test case is set of input values, execution preconditions, expected results and execution
Post conditions, developed for a particular objective or test conditions, such as to exercise a
particular program path or to verify compliance with a specific requirement.
9) What is the purpose of test plan in your project?
Test plan document is prepared by the test lead, it contains the contents like introduction,
objectives, test strategy, scope, test items, program modules user
Procedures, features to be tested features not to tested approach, pass or fail criteria, testing
process, test deliverables, testing, tasks, responsibilities, resources, schedule, environmental
requirements, risks & contingencies, change management procedures, plan approvals etc all
these things help a test manager understand the testing he should do & What he should follow
for testing that particular project.

10) When the relationships occur between tester and developer?

Developer is the one who sends the application to the tester by doing all the necessary code in
the application and sends the marshal id to the tester. The tester is the one who gives all the
input/output and checks whether he is getting required output or not. A developer is the one
who works on inside interfacing where as the tester is the one who works on outside
interfacing

11) When testing will starts in a project?

The testing is not getting started after the coding. After release the build the testers perform
the smoke test. Smoke test is the first test which is done by the testing team. This is
according to the testing team. But, before the releasing of a build the developers will perform
the unit testing.

12) If a bug has high severity then usually that is treated as high priority, then why do
priority given by test engineers/project managers and severity given by testers?
High severity bugs affect the end users. Testers tests an application with the users point of
view, hence it is given as high severity. High priority is given to the bugs which affects the
production. Project managers assign a high priority based on production point of view

13) What is the difference between functional testing and regression testing?
Functional testing is a testing process where we test the functionality/behavior of each
functional component of the application i.e. minimize button, transfer button, links etc. i.e. we
check what is each component doing in that application.
Regression testing is the testing the behavior of the application of the unchanged areas when
there is a change in the build. i.e. we check whether the changed requirement has altered the
behavior of the unchanged areas. The impacted area may be the whole of the application or
some part of the application.

14) Do u know about integration testing, how do u integrate diff modules?

Integration testing means testing an application to verify the data flows between the modules.
For example, when you are testing a bank application, in account balance it shows the
as Balance $100. But in database it shows the 120$. Main thing is "integration done by the
developers and integration testing done by the testers"

15) How you test database and explain the procedure?

Database Testing is purely done based on the requirements. You may generalize a few
features but they won't be complete. In general we look at
1. Data Correctness (Defaults)
2. Data Storage/Retrieval
3. Database Connectivity (across multiple platforms)
4. Database Indexing
5. Data Integrity
6. Data Security
16) Suppose if you press a link in yahoo shopping site in leads to some other company
website? How to test if any problem in linking from one site to another site?
1) First I will check whether the mouse cursor is turning into hand icon or not?
2) I will check the link is highlighting when I place the cursor on the link or not?
3) The site is opening or not?
4) If the site is opening then I will check is it opening in another window or the same window
that the link itself exists (to check user-friendliness of the link)
5) How fast that website is opening?
6) Is the correct site is opening according to the link?
7) All the items in the site are opening or not?
8) All other sub links are opening or not?

17) What are the contents of FRS?

F: Function Behaviors
R: Requirements (Outputs) of the System that is defined.
S: Specification (How, What, When, Where, and Way it behavior's.)
FRS: Function Requirement Specification.
This is a Document which contains the Functional behavior of the system or a feature. This
document is also known as EBS External Behavior Specification - Document. Or EFS External
Function Specification

18) What is meant by Priority and severity?

Priority means "Importance of the defect w.r.t customer requirement"
Severity means "Seriousness of the defect w.r.t functionality"

19) What is meant by Priority and severity?

Severity:
1. This is assigned by the Test Engineer
2. This is to say how badly the deviation that is occurring is affecting the other modules of the
build or release.
Priority:
1. This is assigned by the Developer.
2. This is to say how soon the bug as to be fixed in the main code, so that it pass the basic
requirement.

20) Give me some example for high severity and low priority defect?
If suppose the title of the particular concern is not spelled correctly, it would give a negative
impact.eg ICICC is spelled as a title for the project of the concern ICICI. then it is a high
severity, low priority defect.

21) What is basis for test case review?

The main basis for the test case review is
1. Testing techniques oriented review
2. Requirements oriented review
3. Defects oriented review.

22) What are the contents of SRS documents?

Software requirements specifications and Functional requirements specifications.
23) What is difference between the Web application testing and Client Server testing?
Testing the application in intranet (without browser) is an example for client -server.(The
company firewalls for the server are not open to outside world. Outside people cannot access
the application.)So there will be limited number of people using that application.
Testing an application in internet (using browser) is called web testing. The application which
is accessible by numerous numbers around the world (World Wide Web)
So testing web application, apart from the above said two testing’s there are many other
testing’s to be done depending on the type of web application we are testing.
If it is a secured application (like banking site- we go for security testing etc.)
If it is a ecommerce testing application we go for Usability etc.testing’s.

24) Explain your web application architecture?

Web application is tested in 3 phases
1. Web tier testing --> browser compatibility
2. Middle tier testing --> functionality, security
3. Data base tier testing --> database integrity, contents

25) suppose the product/application has to deliver to client at 5.00PM,At that time you
or your team member caught a high severity defect at 3PM.(Remember defect is
high severity)But the client is cannot wait for long time. You should deliver the
product at 5.00Pm exactly. Then what is the procedure you follow?
The bug is high severity only so we send the application to the client and find out the severity
is priority or not, if its priority then we ask him to wait.
Here we found defects/bugs in the last minute of the delivery or release date
Then we have two options
1. Explain the situation to client and ask some more time to fix the bug.
2. If the client is not ready to give some time then analyze the impact of defect/bug and try to
find workarounds for the defect and mention these issues in the release notes as known
issues or known limitations or known bugs. Here the workaround means remedy process to
be followed to overcome the defect effect.
3. Normally this known issues or known limitations (defects) will be fixed in next version or
next release of the software

26) Give me examples for high priority and low severity defects?
Suppose in one banking application there is one module ATM Facility. In that ATM facility
whenever we are depositing/withdrawing money it is not showing any conformation message
but actually at the back end it is happening properly without any mistake means only missing
of message. In this case as it is happening properly so there is nothing wrong with the
application but as end user is not getting any conformation message so he/she will be
confuse for this. So we can consider this issue as HIGH Priority but LOW Severity defects.

27) Explain about Bug life cycle?

1) Tester->
2) Open defect->
3) Send to developer
4) ->if accepted moves to step5 else sends the bug to tester gain
5) Fixed by developer ->
6) Regression testing->
7) No problem inbuilt and signoff
8) ->if problem in built reopen the issue send to step3
28) How can you report the defect using excel sheet?
To report the defect using excel sheet
Mention : The Feature that been effected.
Mention : Test Case ID (Which fail you can even mention any other which are
dependency on this bug)
Mention : Actual Behavior
Mention : Expected Behavior as mentioned in Test Case or EFS or EBS or SRS document
with section
Mention : Your Test Setup used during Testing
Mention : Steps to Re-Produce the bug
Mention : Additional Info
Mention : Attach a Screen Shot if it is a GUI bug
Mention : Which other features it is blocking because of this bug that you are unable to
execute the test cases.
Mention : How much time you took to execute that test case or follow that specific TC
which leaded to bug

29) If you have executed 100 test cases, every test case passed but apart from these
test cases you found some defect for which test case is not prepared, then how you
can report the bug?
While reporting this bug into bug tracking tool you will generate the test case I mean put the
steps to reproduce the bug.

30) What is the difference between web based application and client server application
The basic difference between web based application & client server application is that the web
application are 3 tiers & client based are 2 tiers. In web based changes are made at one place
& it is reflected on other layers also whereas client based separate changes need be installed
on client machine also.

31) What is test plan? and can you tell the test plan contents?
Test plan is a high level document which explains the test strategy, time lines and available
resources in detail. Typically a test plan contains:
-Objective
-Test strategy
-Resources
-Entry criteria
-Exit criteria
-Use cases/Test cases
-Tasks
-Features to be tested and not tested
-Risks/Assumptions.

32) How many test cases can you write per a day, an average figure?
Complex test cases 4-7 per day
Medium test cases 10-15 per day
Normal test cases 20-30 per day

33) How you can decide the numbers of test cases are enough for testing the given
module?
The developed test cases are covered all the functionality of the application we can say test
cases are enough. If u know the functionality covered or not u can use RTM.
34) Who will prepare FRS (functional requirement documents)? What is the important of
FRS?
The Business Analyst will pre pare the FRS.
Based on this we are going to prepare test cases. It contains
1. Overview of the project
2. Page elements of the Application (Filed Names)
3. Proto type of the of the application
4. Business rules and Error States
5. Data Flow diagrams
6. Use cases contains Actor and Actions and System Responses

35) What is the difference between Retesting and Data Driven Testing?
Retesting: It is manual process in which application will be tested with entire new set of data.
Data Driven Testing(DDT)-It is a Automated testing process in which application is tested
with multiple test data.DDT is very easy procedure than retesting because the tester should sit
and need to give different new inputs manually from front end and it is very tedious and
boring procedure.

36) What is regression testing?

After the Bug fixed, testing the application whether the fixed bug is affecting remaining
functionality of the application or not. Majorly in regression testing Bug fixed module and it's
connected modules are checked for their integrity after bug fixation.

37) How do u test web application?

Web application testing
Web application should have the following features like
1. Attractive User Interface (logos, fonts, alignment)
2. High Usability options
3. Security features (if it has login feature)
4. Database (back end).
5. Performance (appearing speed of the application on client system)
6. Able to work on different Browsers (Browser compatibility), O.S compatibility (technically
called as portability)
7. Broken link testing.........etc
So we need to follow out the following test strategy.
1. Functionality Testing
2. Performance Testing (Load, volume, Stress, Scalability)
3. Usability Testing
4. User Interface Testing (colors, fonts, alignments...)
5. Security Testing
6. Browser compatibility Testing (different versions and different browser)
7. Broken link and Navigation Testing
8. Database (backend) Testing (data integrity)
9. Portability testing (Multi O.s Support)....etc
38) How do u perform regression testing, means what test cases u select for regression
Regression testing will be conducted after any bug fixed or any functionality changed.
During defect fixing procedure some part of coding may be changed or functionality may be
manipulated. In this case the old test cases will be updated or completely re written
according to new features of the application where bug fixed area. Here possible areas are old
test cases will be executed as usual or some new test cases will be added to existing test
cases or some test cases may be deleted.

39) What r the client side scripting languages and server side scripting languages
Client side scripting languages are JavaScript, VB Script, and PHP
Server side Scripting languages are Perl, JSP, ASP, PHP.etc
Client side scripting languages are useful to validate the inputs or user actions from user side
or client side.
Server side Scripting languages are to validate the inputs at server side.
These scripting languages provide security for the application. and also provides dynamic
nature to web or client server application
Client side scripting is good because it won't send the unwanted input's to server for
validation. From front-end itself it validated the user inputs and restricts the user activities
and guides him.

40) If a very low defect (user interface) is detected by u and the developer not
compromising with that defect what will u do?
User interface defect is a high visibility defect and easy to reproduce.
Follow the below procedure
1. Reproduce the defect
2. Capture the defect screen shots
3. Document the proper inputs that you are used to get the defect in the defect report
4. Send the defect report with screen shots and procedure for defect reproduction.
Before going to this you must check your computer hard ware configuration that is same as
developer system configuration and also check the system graphic drivers are properly
installed or not. If the problem in graphic drivers the User interface error will come, so first
check your side if it is correct from your side then report the defect by following the above
method.

41) If u r only person in the office and client asked u for some changes and u didn’t get
what the client asked for what will u do?
One thing here is very important. Nobody will ask test engineer to change software that is
not your duty, even if it is related to testing and anybody is not there try to listen car fully if
you are not understand ask him again and inform to the corresponding people immediately.
Here the client need speedy service, we (our company) should not get any blame from
customer side.

42) How many Test-Cases can be written for the calculator having 0-9 buttons, Add,
Equal to buttons. The test cases should be focused only on add-functionality but not
GUI. What are those test-cases?
Test-Cases for the calculator:
So here we have 12 buttons total i.e. 0,1,2,3,4,5,6,7,8,9,ADD,Equalto -12 buttons.
Here u can press at least 4 buttons at a time minimum for example 0+1= for zero u should
press 'zero' labeled button for plus u should press '+' labeled button for one u should press
'one' labeled button for equal to u should press 'equal to' labeled button 0+1=here + and =
positions will not vary so first number position can be varied from 0 to 9 i.e. From permutation
 and combinations u can fill that space in 10 ways in the same way second number position
can be varied from 0 to 9 i.e. from permutation and combinations u can fill that space in 10
ways. Total number of possibilities are =10x10=100
This is exhaustive testing methodology and this is not possible in all cases.
In mathematics we have one policy that the function satisfies the starting and ending values
of a range then it can satisfy for entire range of values from starting to ending.
then we check the starting conditions i.e. one test case for '0+0=' (expected values you know
that is '0') then another test case for '9+9='(expected values you know that is '18') only two
test cases are enough to test the calculator functionality.

43) What is positive and negative testing explain with example?

Positive Testing - testing the system by giving the valid data.
Negative Testing - testing the system by giving the Invalid data.
For Ex, an application contains a textbox and as per the user's Requirements the textbox
should accept only Strings. By providing only String as input data to the textbox & to check
whether it’s working properly or not means it is Positive Testing. If giving the input other than
String means it is negative Testing.

44) What are the Defect Life Cycle?

Defect life cycle is also called as bug life cycle. It has 6stages namely
1. New: found new bug
2. Assigned: bud assigned to developer
3. Open: developer is fixing the bug
4. Fixed: developer has fixed the bug
5. Retest: tester retests the application
6. Closed/reopened: if it is ok tester gives closed status else he reopens and sends back to
developer.

45) What is performance Testing and Regression Testing?

Performance Testing:-testing the present working condition of the product
Regression Testing:-Regression Testing is checking for the newly added functionality
causing any errors in terms of functionality and the common functionality should be stable
in the latest and the previous versions.

46) How do you review test case?? Type of Review

Types of reviewing test cases depend upon company standards, viz..,
Peer review, team lead review, project manager review.
Sometimes client may also review the test cases regarding what is approach following for
project

47) Apart from bug reporting what is ur involvement in project life cycle
As a Test engineer we design test cases, prepare test cases, Execute Test cases, track the
bugs, analyze the results, report the bugs, involved in regression testing, performance of
system, testing system integration, at last preparation of Test summary Report
48) Write high level test cases
Write all the test cases under high level TC, which can be covered the main functionalities like
creation, edition, deletion, etc. as per prescribed in the screen.
Write all the test cases under low level TC, which can be covered the screen, like input fields
are displayed as per the requirements, buttons are enabled or disabled, and test case for low
priority functionalities.
Example a screen contains two edit boxes login and password and a must buttons OK and
Reset and check box for the label "Remember my password". Now let us write high level TC
and low level test cases.

HIGH LEVEL TC
1. Verify that User is able to login with valid login and valid password.
2. Verify that User is not able to login with invalid login and valid password.
3. Verify that Reset button clears the filled screen.
4. Verify that a pop up message is displayed for blank login.etc...

LOW LEVEL TC
1. Verify that after launching the URL of the application below fields are displays in the screen.
a. Login Name b. Password c. OK BUTTON d. RESET button e. check box, provided for the
label "remember my password" is unchecked.
2. Verify that OK button should be disabled before selecting login and password fields.
3. Verify that OK button should ne enabled after selecting login and password.
4. Verify that User is able to check the check box, provided for the label "remember my
password ".etc..
In this way, we can categorize all the test cases under HIGH LEVEL and LOW LEVEL.

49) What is test scenario

Test scenario will be framed on basis of the requirement, which need to be checked .For that,
we will frame set of test cases, in other terms, we can say all the conditions, which can be
determined the testing coverage against business requirement.
Please see the below example, which is exactly matched to my explanation.
As we know all most all the application are having login screen, which contains login name and
password. Here is the test scenario for login screen.
Scenario: USER'S LOGIN
Conditions to be checked to test the above scenario:
----------------------------------------------------
1. Test login field and Password fields individually.
2. Try to login with valid login and valid password.
3. Try to login with invalid login and valid password

50) If a project is long term project, requirements are also changes then test plan will
change or not? why
Yes, definitely. If requirement changes, the design documents, specifications (for that
particular module which implements the requirements) will also change. Hence the test plan
would also need to be updated. This is because "Resource Allocation" is one section in the test
plan. We would need to write new test cases, review, and execute it. Hence resource
allocation would have to be done accordingly. As a result the Test plan would change
51) What is the Difference between Stub Testing and Driver Testing?
Stub testing:
In top down approach, a core module is developed. To test that core module, small dummy
modules r used. So stubs r small dummy modules that test the core module.
Driver testing:
In bottom up approach, small modules r developed. To test them a dummy core module called
driver is developed.

52) What is cookie And Session testing????

A small text file of information that certain Web sites attach to a user's hard drive while the
user is browsing the Web site. A Cookie can contain information such as user ID, user
preferences, archive shopping cart information, etc. Cookies can contain Personally Identifiable
Information. Session is a connection between a server and client.

53) How would u do performance Testing manually for web site

By noting the time to load page or perform any action with stop watch. I know it sounds funny
but this is the way performance is tested manually.

54) When will do the beta test? When will do the alpha test?
Alpha and Beta tests comes under User acceptance test. We will conduct these two, when
system being released. We are giving opportunity to customer to check all functionalities
covered or not. Alpha testing conducting for software application by real customer at
development site. Beta testing conducting for software product by model customer at
customer site

55) How do you select test cases for Regression Testing(The point is when there is
change code how do you come know which part of code or modules it will affect).
Consider an example of a form which has a username, password and Login button.
There is a code change and a new button "Reset" is introduced. Regression testing (for that
build) will include testing only the "Login" button and not the Reset button (testing Reset
button will be a part of conation testing). Hence the Regression tester need not worry about
the change in code functionality. But he has to make sure that the existing functionality is
working as desired. Testing of "Reset" button will be included as a part of Regression, for the
next build

56) Can anyone explain the example of high severity and low priority, low severity and
high priority, high severity and high priority, low severity and low priority
Severity: Severity determines the defect's effect on the application. Severity is given by
Testers
Priority: Determines the defect urgency of repair. Priority is given by Test lead or project
manager
1) High severity and high priority - Database connectivity cannot be established by multiple
users. & if u click on explorer icon or any other icon then system crash & In the above
example if there is a fault while calculating weekly report. This is a high severity and high
priority fault because this fault will block the functionality of the application immediately
within a week. It should be fixed urgently.
2) Low severity and low priority- Small issues like, incorrect number of decimal digits in the
output. & in login window, spell of ok button is "Ko". & there is a spelling mistake on the
pages which has very less hits throughout the month on any website. This fault can be
considered as low severity and low priority.
 3) Low severity and high priority - Images not updated & in login window, there is an
restriction login name should be 8 character if user enter 9 or than 9 in that case system
get crash.& If there is a spelling mistake or content issue on the homepage of a website
which has daily hits of lakhs. In this case, though this fault is not affecting the website or
other functionalities but considering the status and popularity of the website in the
competitive market it is a high priority fault.
4) High severity and low priority- In a module of say 2 interfaces, the link between them is
broken or is not functioning & supposes logo of any brand company is not proper in their
product, so it affect their business. & For example an application which generates some
banking related reports weekly, monthly, quarterly & yearly by doing some calculations. If
there is a fault while calculating yearly report. This is a high severity fault but low priority
because this fault can be fixed in the next release as a change request.

57) Tell me about your daily activities as a test engineer

Role:
1. Understanding the BRS and Use cases Document
2. Giving system demo to PM, System analyst, designer, Dev lead.
3. Preparing the Test Actions in xls sheet.
4. Updating the Test Actions based on review comments by System analyst/Business Analyst.
5. Preparing the Test cases and Datasets (System level and global level datasets) in word
document
6. Updating the Test Cases based on review comments by System analyst.
7. Installing the application-Testing environment set up.
8. Performing Functional, GUI, System, Compatibility testing(If necessary), Regression testing
based on Test cases
9. Preparing the defect report, Bug tracking list and sending daily status report to PM, leads.

58) In SDLC process what is the role of PM, TL, DEVELOPER, tester in each and every
phase? Please explain me in detail?
In the SDLC we have these phases
1. Initial phase
2. Analysis phase
3. Designing phase
4. Coding phase
5. Testing
6. Delivery and maintenance
In the initial phase project manager can prepare a document for the requirements, team
leader will prepare a team which is having test engineers, developer will provided by the
project manager, tester will prepare test cases for that particular project
Analysis phase all the members have a meeting to finalize the technology to develop that
project, the employee, time.
Designing phase the project manager like senior level management will give the directions
and source code to the team members to develop the actual code that is guidelines will be
given in this phase
Coding phase developer will develop the actual code using the source code and they release
the application to the tester
Testing phase they deploy their test cases to that application and prepare a bug profile
document if there is any defect/bug in that application and send it back to developer,
developer may rectify and releases that application as next build and if the bug not
 understand it will send to the project lead in the delivery phase the Sr. test eng can deploy the
application in the client environment
Maintenance phase if the client get any problem with the application it may solved by the
project lead with the help of testers and developers

59) How do You Test Application without having any requirement and Document?
If it is an existing system or if a build is available then we explore the system while testing.
This helps knowing the functional use of the system, and its usability.
By asking questions to end users and how they use it will be more beneficial. Also, you may
work with BA to know more about the system.
Black box test is nothing but the same where you explore the system without having any prior
knowledge to the system.

60) What is backend testing using SQL?

Executing SQL statements to check if the data submitted by a GUI program is updated in the
database or not. Executing the statement the data base is connecting to that particular
changes, updating or not it will test. Backend testing is the testing the integration between the
application and the database. It is checking the changes made in the database are getting
reflected in the application.
Example: A new column is added in the table. Here we test by giving values in the application
and value has to be stored in the table.

61) Draw Backs of automated testing?

Expensive, lack of expertization, all the areas we cannot automate

62) When will u make update and modify the test object properties in the repository?
Whenever the developer may change any one of the object properties definitely we have to
change the same in the OR object repository. If new version net build released from the
development department we the test engineers must to modify or update the same is
compulsory, otherwise that test will show the bug

63) What are the documents needed to create a test case? How u tell it is test case?
System requirements specification, Use case document, Test Plan

64) At the time of testing web based applications and client server applications, what
you observed as a tester?
We generally check for the links, data retrieving and posting.
We perform load and stress testing especially for Web based and Client-Server applications.

65) What is the general testing process?

Testing Process:
1. Test requirements analysis
2. Creation of Test Strategy (Which includes creation of Test Cases)
3. Creation of Test Plans (Which includes Test Cases and Test Procedures)
4. Execution of test cases
5. Analyze the test results
6. Report the defects if any
66) What is the difference between low and high level test cases?
High level Test cases are those which covers major functionality in the application (i.e.
retrieve, update display, cancel (functionality related test cases) ,database test cases ).
Low level test cases are those which are related to UI related test cases.

67) Is it mandatory to use USECASES or directly one can write test cases from
requirements?
It’s not mandatory to write Use Cases, if the requirements are clear you can go ahead with
Test Cases. Use Cases are written to know the business flow of the module/application

68) Tester with development knowledge will be more effective .justify?

If tester has experience in Development, it will be useful when testing for logical thinking
where the error occurs, what is the cause, He can guess the functionality of component, he
can easily understand the application environment, those are plus points which people have
development experience.
Precisely he can justify that either functionality is wrong or right and can analyze the defects

69) How GUI testing will be done in manual testing for a website?
For any testing there should be some set of standards to be followed. Particularly in GUI
testing, look and feel should be good. We should follow the requirements specification
documents for GUI testing.
There should be some screen shots (given by client) which we should follow as it is.
And for button sizes, font, font size , colors used, placing of links, objects and the placing of
the objects in the page should be followed some standards. If we take a button in the page
that should be some standard size. If the size of that button is more or less the client feel bad
about that. So we should have minimum common sense while testing GUI testing. Some time
there may be some mistakes in the screen shots provided by the client also, but that is our
responsibility to raise those issues.

70) What thing should be tested in regression testing?

While doing Regression Testing a tester must check that any new updation or Modification or
Change in Functionality of a Particular Component or Module does not create any disorder and
any negative effects on the functionality of the Application

71) How do you decide when you have 'tested enough?'

When the 90% of requirements are covered, Maximum defects are rectified except (some) low
level defects are not covered, customer satisfy that project and time is less, then we are
closing the testing.

72) What is a broken link in web testing and how to test it.
When we clicked on Hyperlink if it opens Page can't be displayed then that Hyperlink is called
as Broken link

73) What makes a good test engineer?

A good test engineer has a 'test to break' attitude, an ability to take the point of view of the
customer, a strong desire for quality, and an attention to detail. Tact and diplomacy are useful
in maintaining a cooperative relationship with developers, and an ability to communicate with
both technical (developers) and non-technical (customers, management) people is useful.
Previous software development experience can be helpful as it provides a deeper
understanding of the software development process, gives the tester an appreciation for the
developers' point of view, and reduce the learning curve in automated test tool programming.
 Judgment skills are needed to assess high-risk areas of an application on which to focus
testing efforts when time is limited.

74) What makes a good QA or Test manager?

A good QA, test, or QA/Test(combined) manager should:
• be familiar with the software development process
• be able to maintain enthusiasm of their team and promote a positive atmosphere, despite
• what is a somewhat 'negative' process (e.g., looking for or preventing problems)
• be able to promote teamwork to increase productivity
• be able to promote cooperation between software, test, and QA engineers
• have the diplomatic skills needed to promote improvements in QA processes
• have the ability to withstand pressures and say 'no' to other managers when quality is
insufficient or QA processes are not being adhered to
• have people judgment skills for hiring and keeping skilled personnel
• be able to communicate with technical and non-technical people, engineers, managers, and
customers.
• be able to run meetings and keep them focused
75) What's the role of documentation in QA?
Critical. (Note that documentation can be electronic, not necessarily paper.) QA practices
should be documented such that they are repeatable. Specifications, designs, business rules,
inspection reports, configurations, code changes, test plans, test cases, bug reports, user
manuals, etc. should all be documented. There should ideally be a system for easily finding
and obtaining documents and determining what documentation will have a particular piece of
information. Change management for documentation should be used if possible.
76) What steps are needed to develop and run software tests?
The following are some of the steps to consider:
• Obtain requirements, functional design, and internal design specifications and other
necessary documents
• Obtain budget and schedule requirements
• Determine project-related personnel and their responsibilities, reporting requirements,
required standards and processes (such as release processes, change processes, etc.)
• Identify application's higher-risk aspects, set priorities, and determine scope and limitations
of tests
• Determine test approaches and methods - unit, integration, functional, system, load,
usability tests, etc.
• Determine test environment requirements (hardware, software, communications, etc.)
• Determine test ware requirements (record/playback tools, coverage analyzers, test tracking,
problem/bug tracking, etc.)
• Determine test input data requirements
• Identify tasks, those responsible for tasks, and labor requirements
• Set schedule estimates, timelines, milestones
• Determine input equivalence classes, boundary value analyses, error classes
• Prepare test plan document and have needed reviews/approvals
• Write test cases
• Have needed reviews/inspections/approvals of test cases
• Prepare test environment and test ware, obtain needed user manuals/reference
documents/configuration guides/installation guides, set up test tracking processes, set up
logging and archiving processes, set up or obtain test input data
• Obtain and install software releases
• Perform tests
• Evaluate and report results
• Track problems/bugs and fixes
• Retest as needed
• Maintain and update test plans, test cases, test environment, and test ware through life
cycle
77) What if the software is so buggy it can't really be tested at all?
The best bet in this situation is for the testers to go through the process of reporting whatever
bugs or blocking-type problems initially show up, with the focus being on critical bugs. Since
this type of problem can severely affect schedules, and indicates deeper problems in the
software development process (such as insufficient unit testing or insufficient integration
testing, poor design, improper build or release procedures, etc.) managers should be notified,
and provided with some documentation as evidence of the problem

78) How can it be known when to stop testing?

This can be difficult to determine. Many modern software applications are so complex, and run
in such an interdependent environment, that complete testing can never be done. Common
factors in deciding when to stop are:
• Deadlines (release deadlines, testing deadlines, etc.)
• Test cases completed with certain percentage passed
• Test budget depleted
• Coverage of code/functionality/requirements reaches a specified point
• Bug rate falls below a certain level
• Beta or alpha testing period ends

79) What if there isn't enough time for thorough testing?

Use risk analysis to determine where testing should be focused.
Since it's rarely possible to test every possible aspect of an application, every
possible combination of events, every dependency, or everything that could go
wrong, risk analysis is appropriate to most software development projects. This
requires judgment skills, common sense, and experience. (If warranted, formal
methods are also available.) Considerations can include:
• which functionality is most important to the project's intended purpose?
• Which functionality is most visible to the user?
• Which functionality has the largest safety impact?
• Which functionality has the largest financial impact on users?
• Which aspects of the application are most important to the customer?
• Which aspects of the application can be tested early in the development cycle?
• Which parts of the code are most complex, and thus most subject to errors?
• Which parts of the application were developed in rush or panic mode?
• Which aspects of similar/related previous projects caused problems?
• Which aspects of similar/related previous projects had large maintenance
expenses?
• Which parts of the requirements and design are unclear or poorly thought out?
• What do the developers think are the highest-risk aspects of the application?
• What kinds of problems would cause the worst publicity?
• What kinds of problems would cause the most customer service complaints?
• What kinds of tests could easily cover multiple functionalities?
• Which tests will have the best high-risk-coverage to time-required ratio?
80) What can be done if requirements are changing continuously?
A common problem and a major headache:
• Work with the project's stakeholders early on to understand how requirements might change
so that alternate test plans and strategies can be worked out in advance, if possible.
• It's helpful if the application's initial design allows for some adaptability so that later changes
do not require redoing the application from scratch.
• If the code is well-commented and well-documented this makes changes easier for the
developers.
• Use rapid prototyping whenever possible to help customers feel sure of their requirements
and minimize changes.
• The project's initial schedule should allow for some extra time commensurate with the
possibility of changes.
• Try to move new requirements to a 'Phase 2' version of an application, while using the
original requirements for the 'Phase 1' version.
• Negotiate to allow only easily-implemented new requirements into the project, while moving
more difficult new requirements into future versions of the application.
• Be sure that customers and management understand the scheduling impacts, inherent risks,
and costs of significant requirements changes. Then let management or the customers (not
the developers or testers) decide if the changes are warranted - after all, that's their job.
• Balance the effort put into setting up automated testing with the expected effort required to
re-do them to deal with changes.
• Try to design some flexibility into automated test scripts.
• Focus initial automated testing on application aspects that are most likely to remain
unchanged.
• Devote appropriate effort to risk analysis of changes to minimize regression testing needs.
• Design some flexibility into test cases (this is not easily done; the best bet might be to
minimize the detail in the test cases, or set up only higher-level generic-type test plans)
• Focus less on detailed test plans and test cases and more on ad hoc testing (with an
understanding of the added risk that this entails).

81) What if the application has functionality that wasn't in the requirements?
It may take serious effort to determine if an application has significant unexpected or hidden
functionality, and it would indicate deeper problems in the software development process. If
the functionality isn't necessary to the purpose of the application, it should be removed, as it
may have unknown impacts or dependencies that were not taken into account by the designer
or the customer. If not removed, design information will be needed to determine added testing
needs or regression testing needs. Management should be made aware of any significant
added risks as a result of the unexpected functionality. If the functionality only effects areas
such as minor improvements in the user interface, for example, it may not be a significant
risk.
82) How does a client/server environment affect testing?

Client/server applications can be quite complex due to the multiple dependencies among
clients, data communications, hardware, and servers. Thus testing requirements can be
extensive. When time is limited (as it usually is) the focus should be on integration and
system testing. Additionally, load/stress/performance testing may be useful in determining
client/server application limitations and capabilities. There are commercial tools to assist with
such testing. (See the 'Tools' section for web resources with listings that include these kinds of
test tools.)
83) When will the testing starts? a) Once the requirements are Complete b) In
requirement phase?
Once the requirements are complete. This is Static testing. Here, u r supposed to read the
documents (requirements) and it is quite a common issue in S/w industry that many
requirements contradict with other requirements. These are also can be reported as bugs.
However, they will be reviewed before reporting them as bugs (defects).

84) What are the bugs we cannot find in black box?

If there r any bugs in security settings of the pages or any other internal mistake made in
coding cannot be found in black box testing

85) What are Microsoft 6 rules?

As far as my knowledge these rules are used at user Interface test.

These are also called Microsoft windows standards. They are

• GUI objects are aligned in windows

• All defined text is visible on a GUI object
• Labels on GUI objects are capitalized
• Each label includes an underlined letter (mnemonics)
• Each window includes an OK button, a Cancel button, and a System menu

86) What is Defect removable efficiency?

The DRE is the percentage of defects that have been removed

during an activity, computed with the equation below. The DRE can also be computed for each
software development activity and plotted on a bar graph to show the relative defect removal
efficiencies for each activity. Or, the DRE may be computed for a specific task or technique
(e.g. design inspection, code walkthrough, unit test, 6 month operation, etc.) Number Defects
Removed
DRE = –—————————————————— * 100
Number Defects at Start of Process

DRE=A/A+B = 0.8
A = Testing Team (Defects by testing team)
B = customer ( ” ” customer )
If dre <=0.8 then good product otherwise not.

87) Difference between adhoc testing and error guessing?

Adhoc testing: without test data r any documents performing testing.
Error Guessing: This is a Test data selection technique. The selection criterion is to pick values
that seem likely to cause errors.

88) What is “V-n-V” Model? Why is it called as “V”& why not “U”? Also tell at what
Stage Testing should be best to stared?
It is called V coz it looks like V. the detailed V model is shown below.
There is no such stage for which you wait to start testing.
Testing starts as soon as SRS document is ready. You can raise defects that are present in the
document. It’s called verification.

89) In an application currently in production, one module of code is being modified. Is it

necessary to re-test the whole application or is it enough to just test functionality
associated with that module?
Well, the answer is both. You will have to test the functionality of that module as well as the
other modules. But you can differentiate on the stress to be given on the module to be tested.
If Module A is modified, Module B is depending on module A, and Module C is a general
module independent of module A.
 So in this case you will test the module A in depth to all test cases. Then your next stress will
be on module B. Wait now what about module C? You will have to test this module as well but
may be with less stress because module C is not depend on module A but may be depend on
module B.
Again if you are a white box tester you probably know which modules will get affected and
which modules should be tested. But as a black box tester you will need to do regression
testing as well.

90) .What are you going to do if there is no Functional Spec or any documents related to
the system and developer who wrote the code does not work in the company
anymore, but you have system and need to test?
In this case fist you will need to do the exploratory testing of the product. In this testing you
will come to know the system and its basic workflow. In exploratory testing you can also find
some ‘blocker’ bugs that cause system to be crash. If you are a white box tester then next
step you can do is to see the different module code. By this you will know the test cases for
different modules and relation of modules.

91) What is verification? Validation?

Verification typically involves reviews and meetings to evaluate documents, plans, code,
requirements, and specifications. This can be done with checklists, issues lists, walkthroughs,
and inspection meetings. Validation typically involves actual testing and takes place after
verifications are completed. The term 'IV & V' refers to Independent Verification and
Validation.
92) What is a 'walkthrough'?
A 'walkthrough' is an informal meeting for evaluation or informational purposes. Little or no
preparation is usually required.

93) What's an 'inspection'?

An inspection is more formalized than a 'walkthrough', typically with 3-8 people including a
moderator, reader, and a recorder to take notes. The subject of the inspection is typically a
document such as a requirements spec or a test plan, and the purpose is to find problems and
see what's missing, not to fix anything. Attendees should prepare for this type of meeting by
reading thru the document; most problems will be found during this preparation. The result of
the inspection meeting should be a written report. Thorough preparation for inspections is
difficult, painstaking work, but is one of the most cost effective methods of ensuring quality.
Employees who are most skilled at inspections are like the 'eldest brother' in the parable in
'Why is it often hard for management to get serious about quality assurance?'. Their skill may
have low visibility but they are extremely valuable to any software development organization,
since bug prevention is far more cost-effective than bug detection.

94) STLC(Software Testing Life Cycle)

Order of STLC:

Test Strategy: Test Strategy is a Document, developed by the Project manager,

which contains what type of technique to follow and which module to test
Test Plan: Test plan is a Document, developed by the Test Lead, which contains
"What to Test", "How to Test", "When to Test", "Who to Test"
Test Scenario: A name given to Test Cases is called Test Scenario. This Test
Scenario was deal by the Test Engineer.
Test Cases: It is also document and it specifies a Testable condition to validate
functionality. These Test Cases are deal by the Test Engineer
 95) Difference between verification and validation

Verification:
Verification ensures the product is designed to deliver all functionality to the
customer; it typically involves reviews and meetings to evaluate documents, plans,
code, requirements and specifications; this can be done with checklists, issues lists,
and walkthroughs and inspection meetings.
Validation:
Validation ensures that functionality, as defined in requirements, is the intended
behaviour of the product; validation typically involves actual testing and takes place
after verifications are completed

Important definitions

Black box testing – Internal system design is not considered in this type of testing. Tests
are based on requirements and functionality.

White box testing – This testing is based on knowledge of the internal logic of an
application’s code. Also known as Glass box Testing. Internal software and code working
should be known for this type of testing. Tests are based on coverage of code statements,
branches, paths, conditions.

Unit testing – Testing of individual software components or modules. Typically done by the
programmer and not by testers, as it requires detailed knowledge of the internal program
design and code. may require developing test driver modules or test harnesses.

Incremental integration testing – Bottom up approach for testing i.e continuous testing
of an application as new functionality is added; Application functionality and modules should
be independent enough to test separately. done by programmers or by testers.

Integration testing – Testing of integrated modules to verify combined functionality after

integration. Modules are typically code modules, individual applications, client and server
applications on a network, etc. This type of testing is especially relevant to client/server and
distributed systems.

Functional testing – This type of testing ignores the internal parts and focus on the output
is as per requirement or not. Black-box type testing geared to functional requirements of an
application.

System testing - Entire system is tested as per the requirements. Black-box type testing
that is based on overall requirements specifications, covers all combined parts of a system.

End-to-end testing – Similar to system testing, involves testing of a complete application

environment in a situation that mimics real-world use, such as interacting with a database,
using network communications, or interacting with other hardware, applications, or systems
if appropriate.
Sanity testing – Testing to determine if a new software version is performing well enough
to accept it for a major testing effort. If application is crashing for initial use then system is
not stable enough for further testing and build or application is assigned to fix.

Regression testing - Testing the application as a whole for the modification in any module
or functionality. Difficult to cover all the system in regression testing so typically automation
tools are used for these testing types.

Acceptance testing -Normally this type of testing is done to verify if system meets the
customer specified requirements. User or customer do this testing to determine whether to
accept application.

Load testing – Its a performance testing to check system behavior under load. Testing an
application under heavy loads, such as testing of a web site under a range of loads to
determine at what point the system’s response time degrades or fails.

Stress testing – System is stressed beyond its specifications to check how and when it
fails. Performed under heavy load like putting large number beyond storage capacity,
complex database queries, continuous input to system or database load.

Performance testing - Term often used interchangeably with ’stress’ and ‘load’ testing. To
check whether system meets performance requirements. Used different performance and
load tools to do this.

Usability testing – User-friendliness check. Application flow is tested, Can new user
understand the application easily, Proper help documented whenever user stuck at any
point. Basically system navigation is checked in this testing.

Install/uninstall testing - Tested for full, partial, or upgrade install/uninstall processes on

different operating systems under different hardware, software environment.

Recovery testing - Testing how well a system recovers from crashes, hardware failures, or
other catastrophic problems.

Security testing – Can system be penetrated by any hacking way. Testing how well the
system protects against unauthorized internal or external access. Checked if system,
database is safe from external attacks.

Compatibility testing - Testing how well software performs in a particular

hardware/software/operating system/network environment and different combination s of
above.

Comparison testing – Comparison of product strengths and weaknesses with previous

versions or other similar products.

Alpha testing – In house virtual user environment can be created for this type of testing.
Testing is done at the end of development. Still minor design changes may be made as a
result of such testing.

Beta testing – Testing typically done by end-users or others. Final testing before releasing
application for commercial purpose