1. How will you receive the project requirements?

A. The finalized SRS will be placed in a project repository; we will access it from
there
2. What will you do with SRS?
A. SRS stands for software requirement specification. SRS is used to understand
the project functionality from business and functional point of view.
3. What is FRS? How it different from SRS?
A.srs describes what client is expecting from the system. For example in case of
Gmail SRS consists details like first page should be login, to access mail box user
should be authenticated. FRS describes how above requirements will be
developed .in FRS, the functionality in SRS will be written down in more
technical terms. For example in case of Gmail FRS consists details like for login
what fields should be present and what are valid inputs. This means FRS will have
screen level details of the application.
Note: In many projects SRS itself will be designed at screen level details of the
application.
4. Is the testing team involved in SRS preparation?
A. Business analyst prepare the SRS document by interacting with the client.
However a senior testing team member can also be involved in requirements
collections along with the development team and the business analyst team.
5. How does your requirements document look like?
A. It contains lots of use cases where each use case explains one or more
functionalities
6. How will you understand the requirements?
A. If it is known domain by going through use cases i can understand the
requirements. if i have some queries, i will discuss them with business analyst(BA)
for clarifications. if it is new domain, first i will get domain training them i go
through the use cases. If the project requirements are very confusing, then (BA)
can also walk through each use case.
7. How do u understand functionality without screens?
A. We get wireframes in the usecases which helps a lot to understand the
functionality
8. What is wireframe?
A. A diagram which stimulates the feel of the actual screen.
9. What is usecase?
A. Usecase explains the step by step procedure of how a particular functionality of
s/w is used by the end user.usecase contains sections such as
. usecase id
. usecase name
. decription
. flow of events
. alternative flow of events
. pre,post conditions
10. Where you involved in writing the usecases?
A. I am aware of how usecases looks like and i can write if required. but i have
never got an opportunity to write the usecases because these are prepared by
requirements gathering team .Any how i have reviewed the usecases of certain
functionalities and have given my inputs for betterment of the same.
11. What are the different sections present in SRS?
A. overview
Scope
Features
User characteristics
Software requirements
Hardware requirements
Performance requirements
 Use cases
Security and reliability requirements
12. How long do u spend on understanding SRS?
A. It depends on the familiarity of the domain and complexity of the project. if it is
a familiar domain, we can understand around 25 pages of the documentation
every day. For a new complex domain, we manage around 15 pages per day.

13. After understanding the SRS what do you do?

A. My lead asks for presentation of the functionalities i am assigned with if i am in
a position to explain the functionalities clearly to the team, then i am considered
as comfortable with functionalities.
14. Should you understand the whole project functionality or only the
functionality assigned to you?
A. I should have a big picture of the whole project. In other words i should have
an overview of the whole project and detailed screen and field level
understanding of the assigned functionalities.
15. What are the different models generally followed in documenting
requirements?
A. Two models are followed in documenting the requirements which are usecase
model and paragraph model. in paragraph model business requirements are
written like a paragraph which is old model. Now a days almost all companies
follow the usecase model where the requirements are written by stating thier
clear objectives and explained with the help of screen shots.
16. How big is your SRS?
A. You can answer anything like approx 250 pages. This question is asked just to
cross check whether u have seen SRS or not
17. What will be the problem without SRS?
A. without srs we will not be able to understand the project features correctly.
Hence we will not able to test the project in depth and deliver the best quality
product.
18. What is SRS?
A. BRS is business requirement specification which is usually prepared before
preparing an srs. This document gives a high-leval view of what is being required
by the customer to meet business needs.
19. What is technical requirements specification?
A. This is also called as high-leval design, which consists of different modules
present in the project.
20. What is user story?
A. user story is the method of documenting requirements in the agile model.

21. What is Review?

A. Review is a meeting in which a work product is verified by set if members
(stake holders)
22. Explain the review process you follow in your organization?
A. The various phases of the review process followed in my organization are:
Planning:
>selecting the personal for review
>allocating roles
>defining entry and exit criteria.
Kick-off:
>Distributing documents
>explaining the objectives
>checking entry criteria, etc.
Individual preparation:
 > in the phase, each of the participants will work before the review
meeting and be ready with questions and comments.
Review Meeting:
> Discussion among the review members by going through each line of the
work product.
> Logging comments
> Making decision about the defect.
Rework:
> Fixing defects found during the review, typically done by the author.
Follow-up:
> checking the defects that have been addressed.
>gathering metrics and checking the exit criteria.

23. What are the roles present in the review?

A. Manager:
>decides on execution of reviews.
> allocates time in project schedules.
> determines if the review objectives have met.
Moderator:
>leads the review, including planning and running the meeting
>follows-up after the meeting.
Author:
The author is the person who has created the item to be reviewed. the
author may also be asked questions within the review.
Reviewer:
 The reviewer are the attendees of the review who attempt to find errors in
the item under review. they should come from different perspectives in order to
provide a well balanced review of the item.
scribe:
The scribe or recorder is the person who is responsible for documenting
issues raised during the process of the review meeting.
24. What is peer review?
A. Is a review of a software work product by colleagues?
25. What is the difference between static and dynamic testing?
A. Static testing means testing the project without executing the software and
dynamic testing means testing the project by executing the software . i.e. by
running the application and going through screens. To conduct dynamic testing
you must use application screens and enter valid and invalid inputs and verify
the application behavior. For static testing, we do not use any screens of
application instead we use static techniques like review. During review, experts go
through each line of the work products like requirement document, design
document and identify mistakes in these documents. Any mistakes identified
during this review are nothing but defects in the work product.
26. I want you to choose one among static and dynamic testing for your project.
Which one will you choose and why?
A. static testing reduces the cost of fix and dynamic testing gives the complete
confidence to release the product. According to me both are equally important
and both of them contribute equally for the project success. so i prefer to have
both. however if i have to
choose one, i choose dynamic testing since i cannot let the project to be
released until i see with my eyes that it is working.
27. out of formal and informal review, which one do you prefer?
A. In my view, both are important: informal review is fast and formal review is
effective. we have to use both depending on the data we are reviewing . I prefer
formal and informal review techniques as follows.
 Formal Review:
> Reviewing test case document created
> Reviewing test plan document created
> reviewing test scripts developed
Informal Review:
> reviewing tests used for retesting
> Reviewing minor changes in test case, test plan or test scripts.
28. How do you decide the review outcome?
A. The review outcome is decided by the moderator. i can share my views with
him. for example in test cases review, the outcome decision it as follows Review
observation Review
outcome
A. Most of the critical test cases are missed
B. Documentation standards are poor
Major changes are suggested …....Accept after correction with another round
of review
Minor changes are suggested ….. Accept after correction without another
round of review
No changes suggested …………………………………………………Accepts as it is
29. Explain what do you document during the review process?
A. we document page and line number of defect, origin of defect, severity of
defect. We also document other information like work product ID, reviewers, etc
30. How much information you can review in one day?
A. per hour we review around 20 pages if it is documentation and 200 lines if it is
code.
31. How do you say review was successful?
A. if every reviewer prepares well before the review and provides good comments
for improvement of the work product, we can say that the review was successful.

32. What is code review?

A. code review is the process of reviewing the code written. code reviews are
conducted for the code developed by the developer and also for the automation
scripts developed by the automation engineer.
33. What is desk check?
A. This is an informal review where a colleagues comes to the desk/computer of
the author and quickly goes through the work product along with the author and
also shares comments while going through it.
34. What are the entry criteria for release?
A. > system testing results must show that all requirements are completed and
project is stable.
> Alpha and beta testing must be completed.
> All medium and above severity bugs must be fixed.
>The release package is available.
> The release CD label is ready.
35. What is the release process you follow?
A. In our organization, the release process is coordinated by a person called
release manager. After successful beta testing, the release manger sends an email
to all stake holders ( development manager, test manager, documentation
manager) for their
Approval for final release. The test manager further forwards the same mail to
team members requesting their internal approval. Based on internal approval. The
test manager can send approval to the release manager.
36. What is your involvement in the release process?
A. As a testing team member, i go through the defect tracking tool and check
whether all the defects are fixed. In case any defects are not fixed i communicate
the same to my test lead and test manager, sharing my opinion regarding each
bug whether it must be fixed before release or it can be fixed after release. The
test manager takes the final decision on whether to fix or not after discussion with
the development manager.
I am further involved in preparing release notes, where i document known
issues in my module along with the issues resolved from the previous release.
Exit criteria for release are:
> All stake holders have approved for release.
> The new package is deployed in production and users are happy about the
release.
> The code has been base lined in the configuration management.

37. What is a code Freeze?

A. code freeze means the code has been locked from further modifications from
developers. After the code freeze the code should be changed by any developer. if
at all any changes are required it should be only for very critical bugs after taking
permission
from the top management of the project. code freezes are often employed in
the final stages of development.
38. What are the entry and exit criteria for test execution?

Entry criteria:
--------------------------------
> coding should be completed
> test cases should be ready and base lined
> RTM should be updated
 > test data should be read and base lined
> test environment/set up should be ready.
>s/w tools should be ready and approved.

Exit criteria:
-----------------------------
> All test cases must be executed and passed
> All defects identified must be fixed, retested and closed
> Test execution summary report must be prepared

39. Explain different test execution strategies?

A. There are 3 test execution strategies.
They are pass1, pass2, pass 3
Pass1 Test execution strategy:
------------------------------
In this execution model one execution cycle will be there. In this one execution
cycle
Itself testers log defects and retest that defect. This is useful in stable, small
with
2nd pass:
----------------------------
Development team releases new build claiming all the defects are fixed.
Testing team retest all defects with adhoc regression. if new defects are found
development team release new build and the life cycle is repeated until no new
defects.
3rd pass:
 ---------------------------
Testing team runs full regression suite and this phase completes only when full
regression is completed. This is good model for large, complex and critical
projects. In case of getting large no of defects in pass -2 strategy, one may have to
move to pass-3 strategy.
40. How do you know you have a build ready for testing?
A. Frequency of build creation would vary from project to project .however
below is the guideline to answer this question. In our project automatic build
creation deployment happens on every x day. we receive a confirmation mail on
every day morning about successful deployment along with URL for
testing .please refer our build process FAQ'S for exactly how build deployment and
release process.
41. How many test cases can you execute per day?
A. it depends on the size and complexity of the test cases. Approximately i execute
around 50 test cases per day which comes to 40 pages approx.
42. How do you run the test cases?
A. I will perform each step in the test case on the application and compare the
application behavior with expected result of the step. if it is same as expected
result then step is passed else step is failed. if the password field shows * or some
other special character while entering the password, it is called password
masking, NOT password encryption. Encryption means converting the user
entered characters into different characters before sending over the network. This
can be checked with the help of
network sniffers.
example s/w for this is WIRESHARK. These s/ was capture every data packet
travelling over the network including the IP address of source and destination
computers. By analyzing these packets we can identify whether the password
string is encrypted
or not.
43. How do you check broken links?
A. Many tools are available for this. we use tools like menu.
44. What is test log?
A. It is a report of what tests have been executed and thier status like pass/ fail. it
is also known as Test execution report.
45. Did you observe any application logs during the test execution?
A. yes. We do observe logs of the application server to check whether the server
has thrown any runtime errors.
46. Do you run all regression tests for every bug fixed?
A. No, I didn’t run regression test cases for every bug fixed. I run regression tests
once for every build.
47. Do you run all regression tests every time ?
A. Depends. if we are sure that the fix might not affect other modules, we run
regression tests specific to the module of the bugs fixed, else we run for the entire
project.
48. In the modules you have worked on, are there any issues identified after
release?
A. projects if i am supposed to write stubs or drivers in the current project i am
confident that i can handle it.
49. When you fill the data in the application form, how do you ensure that the
data is stored in the correct tables and columns?
A. we can write an SQL query to retrieve data from the data base and compare the
query result with the data we have filled in the application forms.
50. What is test case?
A. Test case is a set of inputs, conditions and expected outcomes which a tester
will determine whether an application is working correctly or not.
51. What fields a test case will have?
A. The following are the fields that a test case will usually have.......
 test case id, description, precondition, step name, expected results, actual
results and status.
52. Where do you write test case?
A. Depending on the project we can write test cases in an excel or in QC.
53. How do you know for which functionalities you should write test case?
A. My lead writes top level requirements in QC and assigns to each team member.
we divide test requirements further into sub requirements. Then we identify test
conditions for each sub requirement and create test cases. test cases are reviewed
after that. Reviewed and approved test cases will go to ready state.
54. What is test scenario?
A. Test scenario is nothing but a functional scenario for which testing is to be
conducted. It is also called as a test condition.
55. What is the difference between test scenario and test case?
A. Test scenario is a high level description of business requirements, which is latter
decomposed in to a set of test cases. These test cases will be reviewed and
approved by peers. we follow formal review process for approving test cases
written for each functionality.
56. How do you know your test cases are completed?
A. We follow two step approaches to ensure that test cases are completed.
a. reviews-- it ensures that quality of the test cases is good.
b. Requirement traceability matrix ---it ensures that all requirements have been
covered through test cases.
57. How do you find whether a test case is a good test case or bad test case?
A. A good test case is one which finds the bug or one which has a high probability
of finding the bug. A good test case should be documented clearly, so that it can
be executed by anyone without any difficulties and confusion.
58. What is the percentage of positive and negative test cases that you write?
A. Approx 30% positive and 70% negative
59. Do you update the test cases after receiving build based on the application
screen?
A. During execution, if we feel any test case requires an update, we will do it with
the approval of the team lead. but this work is very limited.
60. Explain one scenario where you were not able to write test cases for a given
requirement?
A. Effort for a new domain by putting extra effort for through understanding of the
domain.
61. What is the difference between a positive and negative test case?
A. A positive test caes checks whether the system does what it is suppose to do.
I.e. to check that we got the desired result with a valid set of inputs.
ex: the user should login in to the system with a valid user name and password.
Negative test case: A negative test case checks whether the system will do what it
is not supposed to do .i.e to check the system generates the correct error or
warning messages with an invalid set of inputs.
ex: if the user entered the wrong user name or password, then the user should
not login in to the system and appropriate error message should be shown.

62. What are the documents required for test analysis?

A. 1. SRS/FRS
2. Use case
3. Architecture document
63. What is an entry criterion for test closure?
A. Decision to stop testing
64. Who takes this decision?
A. The Test Manager
65. What parameters do the test manager considers to take the decision to stop
testing ?
A. The important parameters a test manager looks into are
> Whether all requirements have been developed or not.
> Whether all requirements have been covered through testing.
> Whether all requirements have been handled through fixed or differed
status.
66. What are the exit criteria for test closure?
A. > checking whether planned deliverables have been delivered.
> Finalizing and archiving test ware.
> Hand over of test ware for maintenance.
> analyzing lessons learned for improvement of test maturity.
> Testing sign off.
67. What is testware?
A. Test ware is Artifacts produced during the testing process. Test ware include
test cases, test plan, automation scripts, test data, test environment set-up and
clear up procedures and any additional software or utilities used in testing.
68. What is lessons learnt document?
A. > no of test cases/scenarios blocked
> No of defects verified and their respective status.
> Weekly status reporting:
> Test case summary
> Issues found
> Issues resolved
> Critical issues which are still open and which requires immediate attention
from the client side
 > The report should also contain high plan for the next week.
69. What is the status can give to a test case?
A. Status are pass, fail, blocked, no run.
70. What is web server log?
A. Every time a web page is requested, the webserver automatically logs the
following information.
> The IP address of the visitor
> Date and time of the request
>The url of the requested file
> The url, the visitor came from immediately before
> The visitors web browser type and os