Re: what documents are used to write testcase for integration testing and system

testing?

generally to write test cases we use UCD(use case

document), Business rules and DDD(data design
document).Generally Use cases are derived from SRS(s/w Req
spec)

for writing integration testcases,we use high level design

document(HLD) and for writing system testcases,we use
URD/SRS

Re: Describe components of a typical test plan, such as tools for interactive products
and for database products, as well as cause-and-effect graphs and data-flow
diagrams.

As for IEEE829 standards test plan has following format

1.Project_id
2.Description
3.Test items
4.Features to be tested
5.Features to be not tested
6.Test Environment
7.Entry cryteria
8.Approach
9.Exit cryteria
10.Staff and training
11.Test deliverables
12.Date and time
13.Risk anlysis
14.Approvals

Re: What are cookies and how to test cookies

Cookie is small information stored in text file on user’s
hard drive by web server. This information is later used by
web browser to retrieve information from that machine.
Generally cookie contains personalized user data or
information that is used to communicate between different
web pages.

Test the application by enabling or disabling the cookies

in your browser options. Test if the cookies are encrypted
before writing to user machine. If you are testing the
session cookies (i.e. cookies expire after the sessions
ends) check for login sessions and user stats after session
end. Check effect on application security by deleting the
cookies.

Re: If tester had written test cases for application, then in next build if same features
are modified with some changes. Then Should I have to write test cases for the same
features to verify new expected results.OR What should I do?

In this case you will have to do regression testing.

Regression testing: Testing of previously tested program

following modifiaction to endure that defects have not been
introduced or uncovered in unchanged areas of software as a
result of the changes made. It is performed when the
software or its environment is changed.

You will have to write only new test cases for the new
features added. Will have to run new and old test cases
together.

Re: what are the duties of Quality Assurance engineer and QA Tester?plzzz answer
as soon as possible thanku

Duties of a QA Engg.
Generally a QA Engineer and a QA Tester would mean the same
in real time environments.
However, when it comes to hierarch levels..
QA Manager will have QA Test Lead under him and QA Test
Engineers under the lead..
General Duties of the QA would be:

1. To collect all the docs like: BRD(business req doc),

 technical tp, functional tp from the management or QA
manager.
2. To review the above docs.
3. To moderate the FTR (Formal Technical Reviews)
4. To write RTM
5. Design Test Cases.
6. Once the build release to QA, begin the testing
7. Log the defects in teh Defect tracking tool.
8. Conduct client meetings.., review defects with the dev
team and demo the defects to the developers if required.

The above are in general and can be disscussed in detail

further.

Re: tell about build process???how do u get abuild?? what u l do when u get a
build??

Lead or Feature set lead or Module lead or Project lead

will provide the Build release team (BRT) with the files
to be used for making a build. The BRT makes the build and
gives it back to Development team, the builds goes through
several rounds of alpha testing (which includes unit
testing) based on the Test cases (they are influenced by
the TC's of Quality Testing team). Once the build passes
the alpha testing (n rounds) then the build files are
provided back to BRT with fixes and then the BRT creates a
new Beta build to be forwarded to the Testing team along
with the release build notes (which carries information on
the bug fixes/patches/quick fixes/product components
version numbers etc). Testing team performs the
Smoke/Sanity test on the Beta build and verifies whether
the major functionalities are working or not so that they
can send the build approval mail saying that "the build is
accepted/rejected due to X bugs (with priorit/severity)".
If the build is approved for further testing then the bugs
mentioned in the release build notes are validated and
finally after the testing completion (this includes test
strategy as per test plan, for e.g, Functional, regression,
adhoc testing etc..) the testing completion report of the
Beta build is sent.

Re: how can u map SDLC With STLC

Re: how can u map SDLC With STLC

 Yes SDLC can be maped to STLC with the help of V model.
I have tried to show it
1. Requirement Specifications ----------> Acceptance Test
Acceptance TP Cases

2. Functional design -------------------> System Test Cases

System TP

3. Detailed design ------------------->Integrated Test Cases

Integrated TP

4. Program Specifications--------------->Unit Test Cases

Unit TP

TP refers to Test Plan and not Time Pass :)

So in each of the phases of SDLC , we start planning and

writing Test Cases accordingly,this is how u map SDLC with
STLC.

Hope my answer was fruitful to you

TEST PLAN

Test plan: a software project test plan is a document that describes the objectives, scope, approach,
and focus of a software testing effort. Objective product overview relevant document, standards, legal
requirements traceability requirement overall project organization and personnel contact-
info/responsibility assumption and dependencies risk analysis testing priorities and focus scope and
limitation test outline: decomposition of test approach by test type, feature, functionalities, modules
etc. Test environment configuration management process test tools to be used including version,
patches etc problem tracking and resolution project test metrics entry and exit criteria test suspension
and restart criteria. Personnel allocation and pertaining needs outside test organizations to be utilized
with purpose, responsibilities, deliverables etc. Etc. Open issues
a software project test plan is a document that describes the objectives, scope, approach, and focus of
a software testing effort. The process of preparing a test plan is a useful way to think through the
efforts needed to validate the acceptability of a software product. The completed document will help
people outside the test group understand the 'why' and 'how' of product validation. It should be
thorough enough to be useful but not so thorough that no one outside the test group will read it. A test
plan states what the items to be tested are, at what level they will be tested, what sequence they are to
be tested in, how the test strategy will be applied to the testing of each item, and describes the test
environment. A test plan should ideally be organisation wide, being applicable to all of an
organisations software developments. The objective of each test plan is to provide a plan for
verification, by testing the software, the software produced fulfils the functional or design statements
of the appropriate software specification. In the case of acceptance testing and system testing, this
generally means the functional specification. The first consideration when preparing the test plan is
who the intended audience is – i.e. The audience for a unit test plan would be different, and thus the
content would have to be adjusted accordingly. You should begin the test plan as soon as possible.
Generally it is desirable to begin the master test plan as the same time the requirements documents
and the project plan are being developed. Test planning can (and should) have an impact on the
project plan. Even though plans that are written early will have to be changed during the course of the
development and testing, but that is important, because it records the progress of the testing and helps
planners become more proficient.
Test Plan Format:
Test Plan ID: Unique number of name for future reference.
Introduction: About Project & Testing
Test Items: Names of all modules in that project
Features to be Tested: Names of modules to prepare test cases for testing.
Features not to be Tested: Names of modules to copy test cases from test case data base.
3, 4, 5 specifies "what to test?"
Approach: Selected list of test factors by Project Manager and select list of testing techniques to be
applied.
Entry Criteria:
Testing environment establised
Test cases prepared
Received build from developers
Suspension Criteria:
Testing environment is not working due to repair
sudden changes in customer requirements
pending defects are more
Exit Criteria:
all modules tested
all types of tests applied
all major bugs resolved
Test Environment: Required software and hardware to conduct testing on this project including
testing tools.
Test Deliverables: List of documents to be prepared by testing engineers.
6 to 11 specifies "how to test?"
Staff & Training Needs: Names of selected test engineers and required number of training sessions.
Responsibilities: Work allotments to above selected test engineers
12 & 13 specifies "who to test?"
Schedule: Dates and time
14 specifies "when to test?"
Risks & Mitigation: The list of risks and solutions to overcome.
Approvals: Signatures of test lead and project manager.
AGILE TESTING USES

Testing from the beginning of the project and continually testing throughout the project lifecycle is
thebasis of agile testing. If we can work with the customer to help him specify his requirements in
terms oftests it makes them completely unambiguous, the tests either pass or they don’t.

If our coders only writecode to pass tests, we can be sure of one hundred percent test coverage. Most
of all, if we keep ourtesters, developers and customers (or customer representatives) in constant face-
to-face communicationwith each other, we can eradicate most of the errors caused by us climbing the
ladder of inference.

Breaking our projects into smaller chunks of work and iterating them will give us frequent feedback
on the current state of the project.There are many teams now using agile testing techniques to
improve the quality of their products andhaving great success.

There is some investment in training required and changes to the workspace are necessary to allow
customers, testers, and developers to work side-by-side but these are a small price to pay for the
advantages gained.The most difficult thing for most teams is shifting the perception of the test team
competing with thedevelopers where their focus is detecting faults and preventing poor quality
products from being released.The new, agile testing, paradigm is the test team collaborating with the
developers to build quality in from the start and release robust products that deliver the best possible
business value for the customer.