In this post, I will attempt to compare Scripted and Exploratory styles of software testing. On the third hand, scripted testing is seemed as a strict and serious process and exploratory one is seemed free and easy. But each test style has own swings and roundabouts. Let’s look at them from different points and try defining appropriate conditions to use first one and second one.
Posts tagged ‘testing’
1. We get a list of files from the installation package builder. We need to get a list of files before, and the file list checking is performed after the installation. We can also hear the phrase: “Make a list after the installation, everything is true there” – this is a provocation! Do not give in!
Another point: the same installation package can install different file sets under different operating systems, i.e., we perform testing for each operating system separately.
Some time ago I published the post “Test plan + templates”. I received many comments reflecting different views, so in this article, I decided to continue the talk about planning.
Firstly, I liked J.Hoffman’s and Hannibal’s comments very much, and at the beginning of the talk, I’d like to mention the main points of their comments.
Screenshots are needed for bug reports, user guides, figures of expected results, etc. Sometimes one screenshot is more useful than long confused description. In this post I gathered methods of screenshot creating which I use in my daily work.
Let our program take a dozen parameters. To test all combinations is very difficult, so you should choose the most common and potentially affecting each other. Bugs that arise by a particular combination of all ten parameters are rare.
The most common are bugs that arise by a particular combination of two parameters. The more information about the mutual influence of the parameters (more precisely – of the mutual non-influence), the more combinations we can not test. In the absence of such information, as well as by complex algorithms of program behavior, you should apply the method of pairwise testing.
Thus, we can simplify our task and test all the possible values for each pair of parameters.
Boundary Value Testing is the most well-known and simple technique of test design, which helps the tester choose the most effective values from the ranges of values. This technique is applicable at all levels of testing – unit, integration, system, and system-integration test levels.
We consider the steps of using of the equivalence classes technique:
1.Determining the range of values (usually, the equivalence class).
2.Determination of the boundary range.
3.Creating three test cases for each boundary – one that checks the border value; second that checks the value below boundary; and the third that checks the value above boundary.