Basics of Software Testing - 3

Friends, starting the first post of may about a basic document in testing “TEST CASE”.

Test case – A test case is one of the major document prepared while testing any software. Generally defined test case is document containing some precondition , steps to be followed, test data to be given (Optional as some tests may not contain any test data) , Expected results after performing the steps to be executed for testing a particular requirement. Thus a test case must contain following essential components –
- Test case ID / #
- Precondition.
- Objective of the test.
- Steps to be followed.
- Test data.
- Expected Result.

Apart from the above, some organizations include other heads in test case document such as –
- Defect ID
- Priority
- Type
- Requirement ID/#

Now coming on to details of above heads -

Test case ID is the unique identifier for identifying a particular test case. It can be number/alphanumeric as agreed upon.
Precondition is a state/condition which is essential to execute the given test case. A very-2 common Example if I am executing test case(s) for testing a login web page then the preconditions can be as follows –
- Browser should be installed and running on the PC.
- URL for login should be present.
Objective of the test case is the scenario what we are testing. Continuing the above example my objective is to test the functionality of the login screen. There can be another test case with the objective of testing the user interface of the login screen.
Steps to be followed are the detail sequence of steps to be followed while executing a particular test case
Test data is the data to be keyed in while executing the test case. Continuing the login screen example, test data can be User Name, Password.
Expected Result is the output/results expected after performing the steps as mentioned in “Steps to be followed” and with the test data keyed in.
Actual Result is the actual output observed after executing steps given in the test case. It may/may not differ from the Expected Result and it determines the status of the test case.
Status of the test case can be PASS/FAIL based on the actual result. It can also be NOT RUN/TESTED based on the execution status.
Defect ID is the unique identifier of the defect logged against the failed test case.
Priority of the test case is how important the test case is . It can be HIGH/MEDIUM/LOW or P1/P2/P3 depending on how critical that test case is OR how important the test case is. It is determined by the functionality/scenarios that the test case is covering.
Type of the test case can be functional, UI, database depending on the requirement the test case is covering.
Requirement ID is the unique identifier of the requirement which the test case is covering. The purpose of including the requirement is in the test case document is just to make out the each and every requirement is covered and also to determine that which test case is covering which requirement.

Based on the above, we can now design a generic template to write test case(s) which can be as follows –

Precondition :

Test Case ID
Priority
Type
Requirement ID
Objective
Steps to be followed
Test Data
Expected Result
Actual Result
Status
Defect ID

Some basic points while preparing/reviewing/executing test cases –
- Read the requirement document fully and get the full understanding of the requirements.
- First prepare high level test cases OR test scenarios describing the what we are going to test and possible different states of what is to be tested.
- After this move on to detail test case writing with the steps, test data, expected results.
- Have a checklist ready before preparing test cases this will help at the time of reviewing the test cases. This checklist should not contain details but should point out generic points applicable to all the test cases. While submitting the test cases for further review validate the test cases against this checklist and submit it along with the test case document.
- While reviewing the test cases, reviewer should also validate the test cases against the checklist.
- All the review points should be documented in a proper format. Avoid sending review points in the email instead document in a proper document and send it. A separate copy can be kept at a central repository. Apart from this, another advantage is that document can be amended further. As with email, the trail gets long and its very tedious to keep a track of it.
- While executing the test cases try to indentify the important test cases and prioritize them. This will help to identify test cases which are to be executed in ‘Sanity level’ testing on the forthcoming releases.
- Also try to execute tests with combinations of test data other than the documented test data.


END OF POST. As always, suggestions/comments are most welcome.

Thanks & Regards,
Amit

Basics of Software testing- 1

Basics of Software testing –

What is “Software Testing” - There are many definitions available on the internet given by various scholars in this field and everybody’s definition is different. Ask this question to a 1 year experienced person he will give you a bookish answer and If you ask this question to a person having 4 OR more years of experience in this field he might not able to give you a perfect answer . I would like to define it in my terms which may be similar with any scholars definition. As per my experience Software testing is an activity/phase/process in SDLC where in we test whether the software is working as per the its requirement specification and in turn we measure the quality of the software developed. It is a process of executing a program or system with the intent of finding errors and evaluating it for conformance with the requirements specification.

Now on the basis of approach followed testing can be divided into –
- White Box
- Black Box

When we say that we are following/doing “White Box testing”, we mean that a testing activity in which we have access to the code of the system/module/ function we are testing and we are aware of the logic implemented in it. This knowledge may help us finding out the right place where the bug/defect has occurred and wrongly implemented logic.

Coming on to “Black Box testing”, In this type of testing we do not have access to the actual code of the system neither we have knowledge of the logic implemented. In this type of testing , tester is more concerned about the output which he/she gets from the system on the basis of the input given.

On the basis of types, there are four types of testing –
- Unit testing
- Functional testing
- Integration testing
- System testing

Unit testing is the primary testing activity carried out at the code level. It intend to find out the fault/bug in smallest unit of a project – A Program / Function. It follows “WHITE BOX” approach and is different from debugging in the sense that debugging is executing the program step by step to diagnose a problem where as Unit testing is broader activity which covers not only executing a program but also checking the placement of elements on the screen, performing nominal operations with them and related activities. For eg. If my program accepts input in a text field ‘T’ and it is not accepting that then debugging comes into picture. By executing the program step by step we will find out where the problem is. While in the same example Unit testing refers to testing whether the user is able to input the characters, fields are getting displayed at proper place and so on. Developers are responsible for UNIT TESTING.

Functional Testing is a step further to unit testing. This refers to testing functionality of the application/modules of the application as per the requirement specification. Test Engineers are responsible for it and they write test cases / scripts for performing functional testing.

Integration Testing is another steps further in testing of an application and it refers to testing the combined parts of the application , interaction of different parts of applications with each other. Under this different application parts (modules) are combined together and the application behavior, data flow between these parts, interaction between them is tested .

Systems Testing is the last testing activity conducted on any software system / application. It refers to testing the system as whole and confirm that whether it meets the requirements OR not. Apart from functional requirements systems testing also covers non functional requirements like performance, usability, security, reliability maintainability and other related factors.


As always, suggestions / comments welcome. Also I would like to have inputs on what more topics can be written


-Amit