Sanity Testing:
Sanity testing is used to test in intial check up is made on the build after recieving from developer.
Sanity Testing:When a major bug is filed in a build,developers will fix that particular bug alone and releases a new build ,testing the new build to check the particular issue is fixed and fixture has not caused any impact on other functionality,is known as "Sanity Testing"
Smoke Testing
In this we test that application is able for the further testing or not. We just check the capability of the application for testing.
We can check following things in this:
i)Build is properly installed on the system( because sometimes application crash during installation of the application).
ii)Installed application properly connected with the database and network.
iii)All the module are display and working fine.
Friday, November 16, 2007
Thursday, November 1, 2007
Boundary value testing
is a technique to find whether the application is accepting the expected range of values and rejecting the values which falls out of range.
Ex. A user ID text box has to accept alphabet characters ( a-z ) with length of 4 to 10 characters.
BVA is done like this, max value:10 pass; max-1: 9 pass;
max+1=11 fail ;min=4 pass;min+1=5 pass;min-1=3 fail;
Like wise we check the corner values and come out with a conclusion whether the application is accepting correct range of values.
Ex. A user ID text box has to accept alphabet characters ( a-z ) with length of 4 to 10 characters.
BVA is done like this, max value:10 pass; max-1: 9 pass;
max+1=11 fail ;min=4 pass;min+1=5 pass;min-1=3 fail;
Like wise we check the corner values and come out with a conclusion whether the application is accepting correct range of values.
Thursday, September 20, 2007
Difference between RTM and TRM
RTM (Requirment Tracebility Matrix): means mapping between requirements and testcases to check whether all testcases are covered or not
TRM (Test Responsibility Matrix): meanswhich type oftesting technique has to be chosen to corresponding usecase
TRM (Test Responsibility Matrix): meanswhich type oftesting technique has to be chosen to corresponding usecase
Saturday, September 8, 2007
Difference between use case and test case
USE CASE:is a functional and system requirement of how a user uses the system being designed to perform a task.it provdes a powerful communication between customer,developer and tester...
TEST CASE:test cases r written on the basis of use case documents..that describes an input action or event and expected response to determine if a feature of an application is working correctly
TEST CASE:test cases r written on the basis of use case documents..that describes an input action or event and expected response to determine if a feature of an application is working correctly
Saturday, September 1, 2007
Relationship between SDLC or STLC
Stage 1: When Contract is signed or Organization got a project from the customer, by refering to SOW(Statement of Work) or Requirements the "UAT(User Acceptance Test) Plan is preparedand the same under goes reviews(Verification).
Stage 2. (Requirement Gathering):- Once requirement gathering or study is over the "SRS(Software Requirement Specification)" is prepared and it's reviewed(Verfication) and once SRS is finalised STP(Software Test Plan) is prepared and the same under goes reviews(Verification).
Stage 3. (High Level Design):- Taking SRS as input, HLDD (High Level Design Document) is prepared and same under goes Reviews(Verification) . Once HLDD is ready, refering the same ITP(Integration Test Plan) is prepared and the same under goes reviews(Verification).
Stage 4. (Low Level Design) :- Taking HLDD as input LLDD(Low level Design Document) is preparedand same under goes Reviews(Verification) .Once HLDD is ready, refering the same UTP(Unit Test Plan) is prepared and the same under goes reviews(Verification).
Stage 5. Coding(Impelementation):- Taking LLDD (Low level Design Document) coding will done and coding also under goes reviews(Verification).
This is all about Verification Part , Now on wards the Validation or Actual Testing starts
Stage 6. Unit Test :-Once coding of unit(s) is done , unit testing(Validation)w will be carried out by refering to the test cases (present in UTP).
Stage 7. Integration Test :- once all the units get tested, Integration testing (Validation)will be carried by refering to test cases (present in ITP).
CONTINUED ------------->
Stage 2. (Requirement Gathering):- Once requirement gathering or study is over the "SRS(Software Requirement Specification)" is prepared and it's reviewed(Verfication) and once SRS is finalised STP(Software Test Plan) is prepared and the same under goes reviews(Verification).
Stage 3. (High Level Design):- Taking SRS as input, HLDD (High Level Design Document) is prepared and same under goes Reviews(Verification) . Once HLDD is ready, refering the same ITP(Integration Test Plan) is prepared and the same under goes reviews(Verification).
Stage 4. (Low Level Design) :- Taking HLDD as input LLDD(Low level Design Document) is preparedand same under goes Reviews(Verification) .Once HLDD is ready, refering the same UTP(Unit Test Plan) is prepared and the same under goes reviews(Verification).
Stage 5. Coding(Impelementation):- Taking LLDD (Low level Design Document) coding will done and coding also under goes reviews(Verification).
This is all about Verification Part , Now on wards the Validation or Actual Testing starts
Stage 6. Unit Test :-Once coding of unit(s) is done , unit testing(Validation)w will be carried out by refering to the test cases (present in UTP).
Stage 7. Integration Test :- once all the units get tested, Integration testing (Validation)will be carried by refering to test cases (present in ITP).
CONTINUED ------------->
Monday, August 20, 2007
Difference between defect,error,bug,failure and fault
Error : A discrepancy between a computed, observed, or measured value or condition and the true, specified, or theoretically correct value or condition. See: anomaly, bug, defect, exception, and fault
Failure: The inability of a system or component to perform its required functions within specified performance requirements. See: bug, crash, exception, fault.
Bug: A fault in a program which causes the program to perform in an unintended or unanticipated manner. See: anomaly, defect, error, exception, fault.
Fault: An incorrect step, process, or data definition in a computer program which causes the program to perform in an unintended or unanticipated manner. See: bug, defect, error, exception.
Defect: Mismatch between the requirements.
Failure: The inability of a system or component to perform its required functions within specified performance requirements. See: bug, crash, exception, fault.
Bug: A fault in a program which causes the program to perform in an unintended or unanticipated manner. See: anomaly, defect, error, exception, fault.
Fault: An incorrect step, process, or data definition in a computer program which causes the program to perform in an unintended or unanticipated manner. See: bug, defect, error, exception.
Defect: Mismatch between the requirements.
Monday, July 30, 2007
Difference between Static or Dynamic testing?
Static Testing:
The Verification activities fall into the category of Static Testing. During static testing, you have a checklist to check whether the work you are doing is going as per the set standards of the organization. These standards can be for Coding, Integrating and Deployment. Review's, Inspection's and Walkthrough's are static testing methodologies.
Dynamic Testing:
Dynamic Testing involves working with the software, giving input values and checking if the output is as expected. These are the Validation activities. Unit Tests, Integration Tests, System Tests and Acceptance Tests are few of the Dynamic Testing methodologies.
The Verification activities fall into the category of Static Testing. During static testing, you have a checklist to check whether the work you are doing is going as per the set standards of the organization. These standards can be for Coding, Integrating and Deployment. Review's, Inspection's and Walkthrough's are static testing methodologies.
Dynamic Testing:
Dynamic Testing involves working with the software, giving input values and checking if the output is as expected. These are the Validation activities. Unit Tests, Integration Tests, System Tests and Acceptance Tests are few of the Dynamic Testing methodologies.
Subscribe to:
Posts (Atom)
