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.
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.
Planning is one of main activities of software testing. Depending on formality of our test process, we have to create detailed test plans with strict template or simple check list on a paper. In any case, we must remember that planning is an endless activity. At least we have to plan for the whole project life cycle. We can’t create a test plan at the begin of the project, print it and have a successful test process. Test plan must be corrected and updated at every turn.
The question is asked by many people so I decided to devote the post to explaining these terms. Let’s look at the standards first:
Quality Assurance (QA) is a part of quality management focused on providing confidence that quality requirements will be fulfilled. [ISO 9000]
Testing is a process consisting of all life cycle activities, both static and dynamic, concerned with planning, preparation and evaluation of software products and related work products to determine that they satisfy specified requirements, to demonstrate that they are fit for purpose and to detect defects. [ISTQB glossary]
The template of the bug report depends on the bug tracking system you use. Usually the bug report should contain the following fields:
- unique identifier
- build version
- step to reproduction
- reproduction (always, sometimes)
As soon as a bug has been found, it must be reported because you can forget about the bug. Do not prepare the report on a paper (you can lose it) and log the report to the bug tracking system. These are simple rules but many testers neglect them and many bugs have been left unfixed.