How to do Testing Without a Formal Test Plan?

Testing always requires a formal plan. But there are circumstances where testers need to skip plans to achieve their targets assigned and the tips below will help testers to work without a formal plan.

1) Finding High Level Functions
As always high level functions are of central purpose to the site or an application, modify those functions based on the priority frequently according to their significance to a user's ability. Determine the test direction as soon as possible to see changes happening rapid.

2) Test Before Display
Before the product is being displayed test it using different browsers and platforms also use designers and developers to review the tests. This is an instant where testers run out of time and they need to test without a formal plan.

3) Concentrate on Ideal Path Actions
Testers should assume themselves as users, focus on the ideal path and identify those factors most likely to be used in a majority of user interactions. Get to know about the sections where the user makes a frequent visit, because most of the user doesn't think the same way hence make a set of guess based on user's interest when he visits your website.

4) Focus on Intrinsic Factors
Intrinsic factors are internal and it can be fixed only by the tester also the user can do nothing with it. Hence these factors require an immediate attention before the error reflects in the user's end. These errors are time sensitive hence it needs to be fixed without a formal plan.

5) Boundary Test from Reasonable to Extreme
The systematic testing of error handling is called boundary testing. Unknown values may choke the system therefore start with all you know when you perform a boundary test. Finding reasonable and predictable mistakes is a better way to perform a progressive boundary test.

6) Good Values
Always use valid and current information. Enter in data formatted as the interface requires. Include all required fields all these good values will help testers to make less errors.

7) Reasonable and Predictable Mistakes
It is easier for testers to predict errors done based on design especially with interface interpretation. These errors are very common and occur frequently due to complex design in fact it is easy to fix without a formal plan.

8) Extreme Errors and Crazy Inputs
Testing for maximum size of inputs, long strings of garbage, numbers in the text fields and text in numeric fields will reduce extreme errors, proceed from most likely to less likely to save time.

9) Compatibility Testing from good to bad
It is always good to start a test with the configurations which is more familiar. Therefore when you test a cross platform application begin your testing process with the most used browser and then with least used browser.

10) Expected Bad Values
A tester should make sure that an error message pops out each time when some invalid entries are entered in places like online forms. Such test cases don't require a formal plan. A tester can easily give random values to test the application.

Ten Commandments of Software Testing

"Software Testing is a systematic activity but it also involves economics and human psychology."

Economics of software testing is to determine and predict the faults of the system early by using foreseeable models and applying structured test strategies and test methodologies to discover those at early phases of the software development life cycle.

Psychology of testing is to destructively test the application by identifying as many exceptional or out of the box scenarios or sometimes called as the third vision.

A set of good test scenarios evaluates every possible permutations and combinations of a program during ideal conditions. In addition, Software Test Engineer needs the proper vision to successfully test a piece/whole application to comply with the Standards and the Quality.

Whenever Software Test Engineer tests a program, they should add some value in it rather than performing only the requirements conformance and validation. A systematic and well planned test process adds the value of quality and reliability of the software program.

The most important considerations in the software testing are the issues of psychology, leading to the set of principles and guidelines to evaluate software quality:

1. Testing is the process of experimenting a software component by using a selected set of test cases, with the intent of revealing defects and evaluate quality Software Test Engineer executes the software using test cases to evaluate properties such as reliability, usability, maintainability, and level of performance. Test results are used to compare the actual properties of the software to those specified in the requirements document as quality goals.

Deviations or failure to achieve quality goals must be addressed. Software Testing has a broader scope rather being only limited to the execution of program or detecting errors more rigorously as described in the test process improvement models such as TMMi framework models.

2. When the test objective is to detect defects, then a good test case is one that has a high probability of revealing a yet undetected defect(s).

Principle 2 supports a strong and robust designing of test cases. This means that each test case should have a goal to identify or detect a specific type of defect. Software Test Engineer approaches the scientific method of designing the tests to prove or disapprove the hypothesis by the means of test procedures.

3. A test case must contain the expected output or result. Principle 3 supports the fact that a test case without expected result is of zero value. Expected output or result determines whether a defect has been revealed or the conditions have been passed during the execution cycle.

4. Test cases should be developed for both valid and invalid input conditions. Use of test cases that are based on invalid inputs is very useful for revealing defects since they may exercise the code in unexpected ways and identify unexpected software behaviour. Invalid inputs also help developers and Software Test Engineers to evaluate the robustness of the software, that is, its ability to recover when unexpected events occur (in this case an erroneous input).

For example, software users may have misunderstandings, or lack information about the nature of the inputs. They often make typographical errors even when complete/correct information is available. Devices or software program may also provide invalid inputs due to erroneous conditions and malfunctions.

5. The probability of the existence of additional defects in a software component is proportional to the number of defects already detected in that component. Principle 5 supports to the fact that the higher the number of defects already detected in a component, the more likely it is to have additional defects when it undergoes further testing.

For example, if there are two components A and B, and Software Test Engineers have found 20 defects in A and 3 defects in B, then the probability of the existence of additional defects in A is higher than B. This empirical observation may be due to several causes and degree of influence of the software factors. Defects often occur in clusters and often in code that has a high degree of complexity and is poorly designed.

6. Test Cases must be repeatable and reusable. Principle 6 is utmost important and plays a vital role supporting the fact that it is also useful for tests that need to be repeated after defect repair. The repetition and reuse of tests is also necessary during regression test (the retesting of software that has been modified) in the case of a new release of the software.

7. Testing should be carried out by a group that is independent of the development group. This principle holds true for psychological as well as practical reasons and does not say that it is impossible for a programming organization to find some of its errors, because organizations do accomplish this with some degree of success. Rather, it implies that it is more economical for testing to be performed by an objective, independent party which gives a direction of the third vision by the means of test cases. Finally, independence of the testing group does not call for an adversarial relationship between developers and Software Test Engineers.

8. Test Activities should be well planned. Test plans should be developed for each level of testing, and objectives for each level should be described in the associated plan. The objectives should be stated as quantitatively as possible. Plans, with their precisely specified objectives, are necessary to ensure that adequate time and resources are allocated for testing tasks, and that testing can be monitored and managed.

Test planning must be coordinated with project planning. A test plan is a roadmap for the testing which should be mapped to organizational goals and policies pertaining to the software program.

Test risks must be evaluated at each levels of testing. Careful test planning avoids wasteful "throwaway" tests and unproductive and unplanned "test-patch-retest" cycles that often lead to poor-quality software and the inability to deliver software on time and within budget.

9. Avoid throwaway test cases unless the program is truly a throwaway program. Whenever the program has to be tested, the test cases must be reinvented. More often than not, since this reinvention requires a considerable amount of work, Software Test Engineer tends to avoid it. Therefore, the retest of the program is rarely as rigorous as the original test, meaning that if the modification causes a previously functional part of the program to fail, this error often goes undetected.

10. Test results should be inspected meticulously. This is probably the most obvious principle, but again it is something that is often overlooked.

Weve seen numerous tests that show many subjects failed to detect certain errors, even when symptoms of those errors were clearly observable on the output listings. Put another way, errors that are found on later tests are often missed in the results from earlier tests.

For example:

I. A failure may be overlooked, and the test may be granted a "PASS" status when in reality the software has failed the test. Testing may continue based on erroneous test results. The defect may be revealed at some later stage of testing, but in that case it may be more costly and difficult to locate and repair.

II. A failure may be suspected when in reality none exists. In this case the test may be granted a "FAIL" status. Much time and effort may be spent on trying to find the defect that does not exist. A careful re-examination of the test results could finally indicate that no failure has occurred.

Summarizing all the above principles, Testing is an extremely creative and intellectually challenging task. Creativity required in testing a large program exceeds the creativity required in designing or developing that program. We already have seen that it is impossible to test a program sufficiently to guarantee the absence of all errors. This requires a systematic test process and methodologies to design the robust test cases.

This principle supports that:

A Software Test Engineer needs to have comprehensive knowledge of the software engineering discipline.

A Software Test Engineer needs to have knowledge from both experience and education as to how software is specified, designed, and developed.

A Software Test Engineer needs to have knowledge of fault types and where faults of a certain type might occur in code constructs.

A Software Test Engineer needs to reason like a scientist and propose hypotheses that relate to presence of specific types of defects.

A Software Test Engineer needs to have a good grasp of the problem domain of the software that he/she is testing.

A Software Test Engineer needs to create and document test cases. To design the test cases the Software Test Engineer must select inputs often from a very wide domain.

A Software Test Engineer needs to design and record test procedures for running the tests.

A Software Test Engineer needs to execute the tests and is responsible for recording results.

A Software Test Engineer needs to analyze test results and decide on success or failure for a test. This involves understanding and keeping track of an enormous amount of detailed information.

A Software Test Engineer needs to know the method for collecting and analyzing test related measurements.