Manual Testing
What is Software Testing?
Software testing is a process used to identify the correctness, completeness and quality of developed computer software.
A set of activities conducted with the intent of finding errors in software.
Software testing is an investigation conducted to provide stakeholders with information about the quality of the product or service under test
Manual testing
Manual testing is the oldest and most rigorous type of software testing. Manual testing requires a tester to perform manual test operations on the test software without the help of Test automation. Manual testing is a laborious activity that requires the tester to possess a certain set of qualities; to be patient, observant, speculative, creative, innovative, open-minded, resourceful, unopinionated, and skillful.
Steps for Manual Testing
A manual tester would typically perform the following steps for manual testing:
1. Understand the functionality of program
2. Prepare a test environment
3. Execute test case(s) manually
4. Verify the actual result
5. Record the result as Pass or Fail
6. Make a summary report of the Pass and Fail test cases
7. Publish the report
8. Record any new defects uncovered during the test case execution
Test
• An activity in which a system or component is executed under specified conditions, the result are observed or recorded, and an evaluation is made of some aspect of the system or component.
Test Case
• A set of test inputs, execution conditions, and expected results developed for a particular objective
• The smallest entity that is always executed as unit, from beginning to end
• A test case is a document that describes an input, action, or event and an expected response, to determine if a feature of an application is working correctly
A test case should contain particulars such as test case identifier, test case name, objective, test conditions/setup, input data requirements, steps, and expected results
• Test case may also include prerequisites
Test Case Components
• The structure of test cases is one of the things that stays remarkably the same regardless of the technology being tested. The conditions to be tested may differ greatly from one technology to the next, but you still need to know three basic things about what you plan to test:
• ID #: This is a unique identifier for the test case. The identifier does not imply a sequential order of test execution in most cases. The test case ID can also be intelligent. For example, the test case ID of ORD001 could indicate a test case for the ordering process on the first web page.
• Condition: This is an event that should produce an observable result. For example, in an e-commerce application, if the user selects an overnight shipping option, the correct charge should be added to the total of the transaction. A test designer would want to test all shipping options, with each option giving a different amount added to the transaction total.
• Procedure: This is the process a tester needs to perform to invoke the condition and observe the results. A test case procedure should be limited to the steps needed to perform a single test case.
• Expected Result: This is the observable result from invoking a test condition. If you can’t observe a result, you can’t determine if a test passes or fails. In the previous example of an e-commerce shipping option, the expected results would be specifically defined according to the type of shipping the user selects.
• Pass/Fail: This is where the tester indicates the outcome of the test case. For the purpose of space, I typically use the same column to indicate both “pass” (P) and “fail” (F). In some situations, such as the regulated environment, simply indicating pass or fail is not enough information about the outcome of a test case to provide adequate documentation. For this reason, some people choose to also add a column for “Observed Results.”
• Defect Number Cross-reference: If you identify a defect in the execution of a test case, this component of the test case gives you a way to link the test case to a specific defect report.
a) Write black box test cases for an application using Test Director tool.
Specifying Testing Requirements
You begin the testing process by specifying testing requirements in TestDirector’s Requirements module. Requirements describe in detail what needs to be tested in your application and provide the test team with a foundation on which the entire testing process is based.
You define the requirements in TestDirector by creating a requirements tree. This is a graphical representation of your requirements specification, displaying your requirements hierarchically. You can group and sort requirements in the tree, monitor task allocation and progress of requirements, and generate detailed reports and graphs.
Defining Requirements
In the following exercise, you will define requirements for testing the functionality of reserving cruises in Mercury Tours.
To define a requirement:
1 Open the TestDirector_Demo project.
If the TestDirector_Demo project is not already open, log in to the project. For more information, see “Starting TestDirector,” on page 5.
2 Display the Requirements module.
Click the Requirements tab. The Requirements module displays the requirements tree.
3 Display the requirement tree in Document View.
Select the Document View of the requirement tree.
4 Create a new requirement.
Click the New Requirement button on the Requirements module toolbar. Alternatively, choose Requirements > New Requirement. The New Requirement dialog box opens.
In the Name box, type Cruise Reservation.
In the Product box, select Mercury Tours (HTML Edition).
In the Priority box, select 4-Very High.
In the Type box, select Functional.
Click OK. TestDirector adds the Cruise Reservation requirement to the requirements tree.
5 Add a sub-requirement.
Click the New Child Requirement button to add the next requirement underneath the Cruise Reservation, at a lower hierarchical level. The New Requirement dialog box opens.
In the Name box, type Cruise Search.
In the Product box, select Mercury Tours (HTML Edition).
In the Priority box, select 4-Very High.
In the Type box, select Functional.
Click OK. TestDirector adds the Cruise Search requirement, under the Cruise Reservation requirement.
6 Add an additional sub-requirement.
In the requirements tree, select the Cruise Reservation requirement.
Repeat step 5. This time in the Name box, type Cruise Booking.
TestDirector adds the Cruise Booking requirement, under the Cruise Reservation requirement.
Viewing Requirements
You can change the way TestDirector displays requirements in the requirements tree. In the following exercise, you will learn how to zoom in and out of the tree, display numeration, refresh the tree, and expand and collapse the branches of the tree.
To view requirements:
1 Display the Requirements module.
Click the Requirements tab. The Requirements module displays the requirements tree.
Make sure the requirements tree is displayed in Document view.
2 Zoom in and out of the requirement.
To zoom in, select Cruise Reservation in the requirements tree.
Click the Zoom In button on the toolbar. Alternatively, right-click the requirement and choose Zoom In. The requirements tree only displays the Cruise Reservation requirement, including its two sub-requirements.
To reverse a zoom in action, click the Zoom In arrow, and choose Zoom Out To Root. The entire requirements tree is displayed.
3 Display numeration in the requirements tree.
To assign hierarchical numbers to each requirement in the tree, choose View > Numeration. As you make changes to the tree, TestDirector automatically renumbers the requirements. Note that the numbers are not related to the unique Req ID assigned to each requirement.
4 Refresh the data in the Requirements module.
To refresh a requirement, select the requirement and click the Refresh Selected button. All children of the requirement are also refreshed.
To refresh all requirements, click the Refresh Selected arrow and choose Refresh All.
5 Expand and collapse the requirements.
To expand all the levels in a requirement, right-click a requirement and choose Expand.
To collapse all the levels in a requirement, right-click a requirement and choose Collapse.
19
Modifying Requirements
You can modify the requirements in the requirements tree. In the following exercise, you will learn how to copy, rename, move, or delete requirements.
To modify requirements:
1 Display the Requirements module.
Click the Requirements tab. The Requirements module displays the requirements tree.
2 Copy a requirement.
In the requirements tree, select the Cruise Reservation requirement and click the Copy button.
Click the Paste arrow and choose Paste.
A message box opens. Click OK. The requirement is pasted underneath the selected requirement, at the same hierarchical level. _Copy_ is added to the end of the requirement’s name.
3 Rename the Cruise Reservation_Copy_ requirement.
Right-click the Cruise Reservation_Copy_ requirement and choose Rename.
Edit the requirement name to Hotel Reservation.
Press Enter.
4 Move the Hotel Reservation requirement to a different location in the requirements tree.
Select the Hotel Reservation requirement.
Click the Cut button.
Select the Reservations Management requirement.
To paste the Hotel Reservation requirement underneath the selected requirement, click the Paste arrow and choose Paste as Child.
Click Yes to confirm.
5 Delete the Hotel Reservation requirement.
Select the Hotel Reservation requirement.
Click the Delete button, or choose Requirements > Delete.
Click Yes to confirm.
Converting Requirements
Once you have created the requirements tree, you use the requirements as a basis for defining your test plan tree in the Test Plan module. You can use the Convert to Tests wizard to assist you when designing your test plan tree. The wizard enables you to convert selected requirements or all requirements in the requirements tree to tests or subjects in the test plan tree.
In the following exercise you will convert the Cruise Reservation requirement to a subject in the test plan tree. Its sub-requirements will be converted to tests.
To convert a requirement:
1 Display the Requirements module.
Click the Requirements tab. The Requirements module displays the requirements tree.
2 Select a requirement.
In the requirements tree, select the Cruise Reservation requirement.
3 Open the Convert to Tests wizard.
Choose Tools > Convert to Test > Convert Selected. The Step 1 dialog box opens.
4 Choose an automatic conversion method.
Select Convert all requirements to subjects to convert all selected requirements to subjects.
5 Start the conversion process.
Click Next to begin converting the requirements. When the conversion process is complete, the results are displayed in the Step 2 dialog box.
Select Cruise Booking, and click the Test button.
Click Next. The Step 3 dialog box opens.
7 Choose the destination subject path.
In the Destination Subject Path, click the browse button. The Select Destination Subject dialog box opens.
Select Cruises from your test plan tree.
Click OK to close the Select Destination Subject dialog box. The Destination Subject Path box now indicates the following path:
8 Finalize the conversion process.
Click Finish.
Click OK in the Information dialog box to close the Convert to Tests wizard.
9 View the converted requirements in the test plan tree.
Click the Test Plan tab to display the Test Plan module.
In the test plan tree, select Cruises and click the Refresh Selected button. The test plan tree displays Cruise Reservation under Cruises.
Expand Cruise Reservation. The test plan tree displays Cruise Booking and Cruise Search as manual tests.
Leave a Reply