Manual testing continues to be the most popular method for validating the functionality of software applications. Manual testing is simple and straightforward. However, as technologies have progressed and applications become more complex, the process of manual testing has stayed mostly unchanged. “To err is human” and it is quite obvious that manual testing is error prone, time consuming, and monotonous for every tester. We all know that automation testing is more reliable and reduces testing time. But not all the applications can be done by a click of button. Human intuition cannot be replaced by automation. It is best to combine both the automated and manual testing. Manual testing is something that has not changed for almost more than two decades and in some cases it is a better choice than automated testing. With changing requirements and meeting deadlines, it is easier to change the test cases accordingly.
Certain testing techniques can be implemented as a part of manual testing so we can base our test cases better . Although there is no such hard and fast rules, here at LeaseWeb, we utilize the test techniques based on the requirements that best suit the scenario. Some of the techniques that we can use are as follows.
Inputs to the application are divided into groups that are expected to exhibit similar behavior. The key goal is to complete the test coverage and to lessen duplication.
Partition system inputs and outputs into ‘equivalence sets’ . If input is a 5-digit integer between 10,000 and 99,999, equivalence partitions are < 10,000, 10,000 – 99, 999 and > 10, 000
Boundary value analysis
In this technique, the test data chosen lie along the data extremes. Boundary values include maximum, minimum, just inside/outside boundaries, typical values, and error values. The idea is that, if a systems works correctly for these special values then it will work correctly for all values in between.
Choose test cases at the boundary of these sets : 00000, 09999, 10000, 99999, 10001
Decision table testing
Test cases are designed with the combination of inputs that contain logical conditions. In the entry decision table. It consists of four areas called the condition stub, the condition entry (TC1, TC2 etc,.), the action stub, and the action entry. Each column of the table is a rule that specifies the conditions under which the actions named in the action stub will take place. Where 1 is True and 0 is false, and X is a condition that is not applicable or irrelevant.
Use case testing
Test cases are designed based on the use cases designed by the functional designers. In the use case, the description between the actors, users and the systems is given along with the alternate flows which helps the tester to grab all the scenarios clearly and base the test cases on these. All the preconditions required before testing are clearly mentioned . The flow graphs are useful to understand the working of the system. Use case diagrams are also helpful in the acceptance testing since they are designed with the customer and user participation.
Testing is done based on the skills, intuition, and experience. There are no strong test cases for this type of testing.
An example of ad-hoc testing is exploratory testing, which is defined like simultaneous learning, and means that tests are dynamically designed, executed, and modified. When we first look at a new feature or system, we don’t know much about the system. We design experiments (or tests) to help us learn more about it. We then explore the system qualities and risks that we believe the customers, users, or other stakeholders may care about.