Author: spec-india
A functional test exercises an application with the intent to uncover non-conformance with end-user requirements. This type of testing activity is central to most software test efforts. The primary objective in the functional-testing phase is to assess whether the application does what it is supposed to do in accordance with specified requirements.
A good practice for developing test procedures for the functional testing phase is to base them on the functional requirements. Additionally, some of the test procedures created for this testing phase can be modified for use in testing the nonfunctional aspects of the application, such as performance, security, and usability.
In practice, however, having a perfect set of requirements at the tester’s disposal is a rarity. In order to create effective functional test procedures, the tester must understand the details and intricacies of the application. When, as is often the case, these details and intricacies are inadequately documented in the requirements, the tester must conduct an analysis of them.
Even when detailed requirements are available, the flow and dependency of one requirement to the other is often not immediately apparent. The tester must therefore explore the system in order to gain a sufficient understanding of its behavior to create the most effective test procedures.
In general, the tester must analyze how any change to any part of the application, such as to a variable or a field, affects the rest of the application. It is not good enough to simply verify aspects of the change itself—for example, that the system allows for the required change, using a subset of input combinations and variations, and that the change is saved correctly; rather, an effective test must also cover all other areas affected by this change.
For example, consider the following requirement statement:
“The system must allow the user to edit the customer name on the customer record screen.”
The customer name field and its restrictions are also documented, ideally in the data dictionary. Some testing steps for verifying that the requirement has been met are:
1. Verify that the system allows the user to edit the customer name on the customer-record screen via the user interface, by clicking on the customer record screen and confirming that the customer name can be edited.
2. Try all positive and negative combinations—e.g., all equivalence classes, all boundaries—of customer names allowed. Test a subset of combinations and variations possible within the data dictionary’s restrictions.
3. Run a SQL query verifying that the update is saved correctly in the appropriate table(s).
2. Try all positive and negative combinations—e.g., all equivalence classes, all boundaries—of customer names allowed. Test a subset of combinations and variations possible within the data dictionary’s restrictions.
3. Run a SQL query verifying that the update is saved correctly in the appropriate table(s).
The above steps comprise a good basic test. However, something is missing in order to fully verify this requirement.
Aside from performance and other nonfunctional issues, the question that needs to be answered is, “how the system is otherwise affected when the customer name is changed?” Is there another screen, functionality, or path that uses or is dependent upon the customer name? If so, it will be necessary next to determine how those other parts of the application are affected. Some examples:
• Verify that the “create order” functionality in the order module is now using this changed customer name.
• Add an order record, and verify that the new record has been saved using the new customer name.
• Perform any other possible functions making use of the changed customer name, to verify that it does not adversely affect any other previously working functionality.
• Add an order record, and verify that the new record has been saved using the new customer name.
• Perform any other possible functions making use of the changed customer name, to verify that it does not adversely affect any other previously working functionality.
Analysis and testing must continue until all affected areas have been identified and tested.
When requirements are not documented in detail, this seemingly simple strategy for effective functional software testing is often overlooked. In fact, in most cases the requirements are not documented in sufficient detail to clearly define relationships between requirements and functional paths, which is critical to test-procedure development. Often, therefore, effective test procedures cannot be designed from the requirements statements alone.
Another consideration for effectively creating test procedures is to determine and review critical and high-risk requirements, in order to place a greater priority upon, and provide added depth for, testing the most important functions early in the development schedule. It can be a waste of time to invest efforts in creating test procedures that verify functionality rarely executed by the user, while failing to create test procedures for functions that pose high risk or are executed most often. It is imperative that functional test procedure creation be prioritized based on highest-risk and highest-usage functionality.
Effective test-case design requires understanding of system variations, flows, and scenarios. It is often difficult to wade through page after page of requirements documents in order to understand connections, flows, and interrelationships. Analytical thinking and attention to detail are required to understand the cause-and-effect connections within the system intricacies. It is insufficient to design and develop high-level test cases that execute the system only at a high level; it is important to also design test procedures at the detailed, gray-box level.
Spec India is Software Development Company Based in India that offers Oracle Application Development, Java Application Development, Inventory Management System, Onsite Software Development, Handheld Computer System Development and Mobile Framework Application.
Article Source:
No comments:
Post a Comment