Software Testing Tools used by ISTQB certified Experts like Test Analysts and Technical Test Analysts
Many tools for the support of software development are available, and the selection is growing every day.
It is therefore extremely difficult to list down specific tools. Here we are discussing the classification of Nine different types of tools according to the primary users of the tools specifically ISTQB certified software testing experts like Test analysts and technical test analysts.
These nine types of tools being described are as under:
1) Test design tools
2) Test data generation tools
3) Test oracles
4) Simulation and emulation tools
5) Test execution tools
6) Keyword-driven automation tools
7) Comparison tools
8) Fault-seeding and fault-injection tools
9) Web tools
1) Test Design Tools:
Test design tools support the creation of test specifications. They can analyze a specification of the product, often expressed as a model in a formal way, and generate high-level test cases and possibly test procedures
or scripts based on this analysis.
This type of software testing tool can, for example:
# Derive high-level test cases from formally specified requirements, often managed by the same tool
# Generate test cases based on the specification of a model, for example, UML or state machines
# Generate input for test cases based on input models, for example, input distribution specifications
# Derive high-level test cases from actual source code
The test design tools require very formally formatted basis documentation, and that can be regarded as both an advantage and a disadvantage.
2) Test Data Preparation Tools:
Test input data preparation tools support:
# Selection (e.g., from an existing database)
# Creation
# Generation
# Manipulation
# Editing
of test data for use in setting up preconditions for test procedures and individual test cases.
Some of these tools are data tool-dependent, while some of the sophisticated tools have ability to handle a wide range of the file & database formats.
Test data can be selected and extracted from live data and scrambled to hide person-sensitive information. This enables tests to be performed on real data, something that can be essential for systems in, for example, the public sector.
For example – A test data preparation tool is able to extract live data from the tax authority�s database according to specific selection criteria for test runs of the implementation of a new tax law. The criteria may be 100 families with one income and at least three children, 100 people over 80 years of age with an income over a certain amount, and the 40 people with the highest income in a specific city. The tool scrambles the information that can identify the people in the test data (e.g., Social Security number, before the data may be used).
3) Test Oracles:
A test oracle is a special concept in test automation; it is used to determine expected results from inputs. Some say that the best test oracle is the tester, studying the test basis documentation and deriving the expected result from this. This is, however, sometimes not possible for time and/or cost reasons. Automated test oracles are tools that can generate the expected result for specific input and hence facilitate the creation of test cases. Such “oracles” are hard to find. In principle they must do exactly the same as the object under testing and may therefore seem redundant.
One of the situations where an oracle can be found and can be very useful is when an old system is being replaced by a new one providing the same functionality. This is seen more and more often when old legacy systems are replaced with systems using new technology, for example, Web access. In such a case test input may be given to the old system and the result be regarded as the expected result for the new system.
Oracles can also be created in situations where nonfunctional requirements can be disregarded and a system simulating the functionality only can be developed at a much lower cost. This is especially the case where the real system has very strict performance requirements.
4) Simulation Tools and Emulation Tools:
Simulation tools are generally deployed for supporting the tests when the desired code or some other systems are not possible or not available or even harmful for use.
Test harnesses and drivers fall into this category of tools. They are used where components or other test objects cannot be executed directly. It can be for testing of a component in isolation, embedded software without a user interface, or execution of many unrelated automated test scripts.
Some testing tools on the market provide harness and driver facilities, especially component testing tools. Very often, however, these tools are homemade and tailored precisely to needs. The principle in stubs and drivers has been explained in the following figure.
A special type of simulators is called emulators because they are used to mimic hardware to which the software under testing interfaces.
Simulation tools are almost always bespoke systems made for a specific assignment.
5) Test Execution Tools:
This type of software testing tool have many popular names like: test execution tools, or test running tools, or capture and replay tools, and is probably the most widespread category of testing tool.
The test execution tools are primarily used for automation of regression testing. They can execute test scripts much faster and more reliably than human beings, and they can therefore reduce test execution time when tests are repeated and/or allow more tests to be executed.
All the tools of this category work according to the same basic principles, namely:
# Capture: A recording of all the tester�s manual actions and the system�s responses into a test script
# Control points: A number of checkpoints added to the script by the tester during the capture
# Playback: Automatic re-execution of the test script
Test execution tools exist for graphical user interface, GUI, and for character-based interfaces. For GUI applications the tools can simulate mouse movement and button clicks and can recognize GUI objects such as windows, fields, buttons, and other controls.
When a script has been captured once, it may be executed at any given time again. If the software under testing reacts differently from what was expected at the inserted checkpoints, the execution will report a failure. It is usually also possible to log information during execution.
Test scripts are captured in a specific scripting language. In newer versions of these tools it has become possible to get access to the scripts that have been captured. These are often in a C or Visual Basic like code, and this offers the possibility for editing the scripts, so that, for example, forgotten operations, further control points, or changed values, may be added.
Experience shows that if the scripts are written from scratch, rather than captured, and good and systematic development principles are used, the scripts will be more maintainable. More and more of these tools are therefore used as test execution tools of coded scripts, rather than capture/playback.
6) Keyword-Driven Automation Tools:
Keyword-driven test is a way to execute test scripts at a higher level of abstraction. The idea is similar to that of a service or subroutine in programming where the same code may be executed with different values.
Keywords are defined to represent a script, and a tool can then act as a link between the keywords and the tool executing the corresponding test script. Values may be assigned for parameters associated with the keywords.
The tools make it possible to use parameter-driven test scripts without having to change the scripts in the execution tool. Keywords are usually related to higher level functionality or business procedures. They may also reflect use cases.
The tools for keyword-driven software testing are also known as script wrappers, because they wrap the technical part of the test (the actual test scripts and the test execution tool) so that the testers only need to know about the high-level keywords.
Keywords may be held in spreadsheets or tables, and longer sequences executions of test scripts can be specified by sequences of keywords. Example of a test sequence defined by keywords in a table is as under.
Keyword | P1 | P2 | P3 |
Create customer | Mr. | Sunith | Shakun |
Create customer | Ms. | Amman | Bhavna |
Find customer | Ms. | Amman | Ritu |
Edit customer | , , Gupta | ||
Find customer | Mr. | Raja | Sumit |
Find customer | Mr. | Rajender | Dev |
Delete customer | Yes |
Keyword-driven test is getting more and more sophisticated, introducing several levels of abstraction between the software testing engineer and the technical test scripts. Test wrapping tools are available commercially and as open-source, but they are also very often homemade and usually quite simple, yet very effective.
Keyword-driven software testing requires a good overview of the test assignment and a high level of abstraction as all parameterization does. This is demanding but can be rewarding for the test in the long run.
7) Comparison Tools:
Comparison tools are used to find differences between the expected and the actual results.
These tools range from very simple comparison facilities, like in Word, for example, to very advanced, dedicated tools. Test execution tools normally have some comparison facility included.
The tools may be able to compare, for example, values in files or on screens, bitmaps, and positions.
8) Fault-Seeding and Fault-Injection Tools:
These types of software testing tools are used to support the defect-based test technique fault-injection or fault seeding.
The tools create or inject faults or defects into the software component under testing. The tools can work either on the source code, changing the code in pre-specified ways, or on the compiled code, changing the structure of the code.
In both cases new versions of the component under test are created with the specified defects.
9) Web Tools:
These days testing never stops. With more and more Web-based products around, we need to constantly monitor that the products are doing well. Products being Web-based means that some issues are out of our hands (for example, hyperlinks and server and network availability). Hyperlink testing tools are used to check that no broken hyperlinks are present on a Web site.
These tools often have additional functionality such as HTML validation, spelling, and availability check. The facility is often built into other tools e.g., HTML development tools.
Monitoring tools are used for Web-based products, most typically e-commerce and e-business applications. The tools monitor the product�s availability to customers and the service level i.e. performance and resource usage. The tools will issue warnings if the monitoring shows that something is not as expected.
Many free Web tools are available for this type of tool. Many web tools are proprietary, and are quite sophisticated as well.
Full Study Material for ISTQB Test Analyst & Technical Test Analyst Exam
An expert on R&D, Online Training and Publishing. He is M.Tech. (Honours) and is a part of the STG team since inception.
Thanks in favor of sharing such a nice thinking, post is nice, thats why
i have read it completely