Home » 10/1/07 - 11/1/07
Subjective Testing !!!

Subjective testing mainly depends on an expert's opinion. An expert is a person who is proficient and experienced in the system under test. Conducting the test involves test runs of the simulation by the expert and then the expert evaluates and validates the results based on some criteria.

 One advantage of this approach over objective testing is that it can test those conditions which cannot be tested objectively. For example, an expert can determine whether the joystick handling of the flight feels "right".

 One disadvantage is that the evaluation of the system is based on the "expert's" opinion, which may differ from expert to expert. Also, if the system is very large then it is bound to have many experts. Each expert may view it differently and can give conflicting opinions. This makes it difficult to determine the validity of the system. Despite all these disadvantages, subjective testing is necessary for testing systems with human interaction.

Under:
Table of Contents !!!

A

Ad hoc Testing
Agile Testing
Process in Agile Testing
Alpha Testing
Analytical and Empirical Testing
Application Binary Interface
Automation Testing

B



C

D

E

F

I

L

M

O



Q

R

S

T

U

V

W

Under: ,
System Test cases !!!

The system test cases meant to test the system as per the requirements; end-to end. This is basically to make sure that the application works as per SRS. In system test cases, (generally in system testing itself), the testers are supposed to act as an end user. So, system test cases normally do concentrate on the functionality of the system, inputs are fed through the system and each and every check is performed using the system itself. Normally, the verifications done by checking the database tables directly or running programs manually are not encouraged in the system test.
The system test must focus on functional groups, rather than identifying the program units. When it comes to system testing, it is assume that the interfaces between the modules are working fine (integration passed).

 Ideally the test cases are nothing but a union of the functionality tested in the unit testing and the integration testing. Instead of testing the system inputs outputs through database or external programs, everything is tested through the system itself. For example, in a online shopping application, the catalog and administration screens (program units) would have been independently unit tested and the test results would be verified through the database. In system testing, the tester will mimic as an end user and hence checks the application through its output.

There are occasions, where some/many of the integration and unit test cases are repeated in system testing also; especially when the units are tested with test stubs before and not actually tested with other real modules, during system testing those cases will be performed again with real modules/data in

Under: ,
Integration Test cases !!!

Before designing the integration test cases the testers should go through the Integration test plan. It will give complete idea of how to write integration test cases. The main aim of integration test cases is that it tests the multiple modules together. By executing these test cases the user can find out the errors in the interfaces between the Modules.

For example, in online shopping, there will be Catalog and Administration module. In catalog section the customer can track the list of products and can buy the products online. In administration module the admin can enter the product name and information related to it.

Integration Test cases

 
The tester has to execute above unit and Integration test cases after coding. And He/She has to fill the actual results and Pass/fail columns. If the test cases fail then defect report should be prepared.

Under: , ,
Unit Test Cases !!!

These are very specific to a particular unit. The basic functionality of the unit is to be understood based on the requirements and the design documents. Generally, Design document will provide a lot of information about the functionality of a unit. The Design document has to be referred before UTC is written, because it provides the actual functionality of how the system must behave, for given inputs.
For example, In the Online shopping application, If the user enters valid Email id and Username values, let us assume that Design document says, that the system must display a product details and should insert the Email id and Username in database table. If user enters invalid values the system will display appropriate error message and will not store it in database.

 Login Screen Test Conditions for the fields in the Login screen

 Email-It should be in this format (For Eg clickme@yahoo.com).
Username – It should accept only alphabets not greater than 6.Numerics and special type of characters are not allowed.

 Test Prerequisite: The user should have access to Customer Login screen form screen

 Negative Test Case:
*********************


Positive Test Case:
********************

Under: , , , , , ,
Test Case Format !!!

The test cases will have a generic format as below.

 Test case ID - The test case id must be unique across the application
Test case description - The test case description must be very brief.
Test prerequisite - The test pre-requisite clearly describes what should be present in the system, before the test can be executes.
Test Inputs - The test input is nothing but the test data that is prepared to be fed to the system.
Test steps - The test steps are the step-by-step instructions on how to carry out the test.

 Expected Results - The expected results are the ones that say what the system must give as output or how the system must react based on the test steps.
Actual Results – The actual results are the ones that say outputs of the action for the given inputs or how the system reacts for the given inputs.
Pass/Fail - If the Expected and Actual results are same then test is Pass otherwise Fail.

 The test cases are classified into positive and negative test cases. Positive test cases are designed to prove that the system accepts the valid inputs and then process them correctly. Suitable techniques to design the positive test cases are Specification derived tests, Equivalence partitioning and State-transition testing. The negative test cases are designed to prove that the system rejects invalid inputs and does not process them. Suitable techniques to design the negative test cases are Error guessing, Boundary value analysis, internal boundary value testing and State-transition testing. The test cases details must be very clearly specified, so that a new person can go through the test cases step and step and is able to execute it. The test cases will be explained with specific examples in the following section.

Under: ,
Test Case !!!

A test case specifies the pretest state of the IUT (Integration Unit Testing) and its environment, the test inputs or conditions, and the expected result. The expected result specifies what the IUT should produce from the test inputs. This specification includes messages generated by the IUT, exceptions, returned values, and resultant state of the IUT and its environment. Test cases may also specify initial and resulting conditions for other objects that constitute the IUT and its environment.”

 In software engineering, the most common definition of a test case is a set of conditions or variables under which a tester will determine if a requirement or use case upon an application is partially or fully satisfied. It may take many test cases to determine that a requirement is fully satisfied. In order to fully test that all the requirements of an application are met, there must be at least one test case for each requirement unless a requirement has sub requirements.

 * Test cases help us discover information. Different types of tests are more effective for different classes of information.
* Test cases can be “good” in a variety of ways. No test case will be good in all of them.
* People tend to create test cases according to certain testing styles, such as domain testing or risk-based testing. Good domain tests are different from good risk-based tests.

Under: ,
Effective Bug Reporting !!!






Keep bug reporting simple:
Don't make bug reporting complicated by requiring entry of more data than is really necessary

Describe how to reproduce bugs:
A bug report should include a step-by-step description on how to reproduce the bug (or replication information)

Record how bugs are detected:
Report all the facts-Allow them to reproduce the bug





Write bug reports immediately :
the longer you wait between finding the problem and reporting it, the more likely it is the description will be incomplete, the problem not reproducible, or simply forgotten.

Writing a one-line report summary :
Writing the Bug's report title is an art. You must master it (the same should be related to bug you are reporting)

Don't use the same summary:
For two different reports, even if they are similar don’t use similar summary

Consult your peer member:
Before writing a bug consult your peer team member (if the same has already been reported).




Under:
Bug Life Cycle - Resolutions !!!

Fixed - The Bug has been fixed
Invalid - The problem described is not a bug
Wont Fix - The bug will never be fixed
Later - The bug will not fixed in this version

 Remind - The bug probably wont be fixed in this version
Duplicate - This is a duplicate of an existing bug
Works for me - the bug could not be reproduced
Moved - The bug has been moved to another database

Under: ,
Bug Life Cycle !!!

Life cycle of a BUG:
*********************
As defects move through the system they are given various states. At each state there are a number of possible transitions to other states
The following figure is the life cycle of a bug

 NEW Recently added
to ASSIGNED by acceptance
to RESOLVED by analysis and maybe fixing
to NEW by reassignment
ASSIGNED The owner, i.e. the person referenced by Assigned-To has accepted this bug as something they need to work on
to NEW by reassignment
to RESOLVED by analysis and maybe fixing

 REOPENED Was once resolved but has been reopened
to NEW by reassignment
to ASSIGNED by acceptance
to RESOLVED by analysis and maybe fixing
RESOLVED Has been resolved (e.g. fixed, deemed unfixable, etc. See "resolution" column)
to REOPENED by reopening
to VERIFIED by verification
to CLOSED by closing
VERIFIED The resolution has been approved by QA
to CLOSED when the product ships
to REOPENED by reopening
CLOSED Over and done with
to REOPENED by reopening

Under: