STQA
STQA
4. Select the tools according to organizational needs: Do not buy the tools just
for their popularity or to compete with other organizations. Focus on the needs of
the organization and know the resources (budget, schedule) before choosing the
automation tool.
STQA 1
6. Automate the regression tests whenever feasible: Regression testing
consumes a lot of time. If tools are used for this testing, the testing time can be
reduced to a greater extent. Therefore, whenever possible, automate the
regression test cases.
Following are some facts pertaining to the cost incurred in testing tools :
1. Automated script development: Automated test tools do not create test scripts.
Therefore, a significant time is needed to program the tests. Scripts are
themselves programming languages. Thus, automating test execution requires
programming exercises.
2. Training is required: It is not necessary that the tester will be aware of all the
tools and can use them directly. He may require training regarding the tool.
Therefore, it becomes necessary that in a new project, cost of training on the
tools should also be included in the project budget and schedule.
4. Learning curve for the tools There is a learning curve in using any new tool.
For example, test scripts generated by the tool during recording must be
modified manually, requiring tool-scripting knowledge in order to make the script
robust, reusable, and maintainable.
5. Testing tools can be intrusive It may be necessary that for automation some
tools require that a special code is inserted in the system to work correctly and to
be integrated with the testing tools. Intrusive tools pose the risk that defects
introduced by the code inserted specifically to facilitate testing could interfere
with the normal functioning of the system.
6. Multiple tools are required: It may be possible that your requirement is not
satisfied with just one tool for automation. In such a case you have to go for
many tools which incur a lot of cost.
STQA 2
Need of Automation in Testing
If an organization needs to choose a testing tool, the following benefits of automation
must be considered.
4. Avoids human mistakes: Manually executing the test cases may incorporate
errors in the process or sometimes, we may be biased towards limited test cases
while checking the software.
5. Reduces overall cost of the software: As we have seen that if testing time
increases, cost of the software also increases. But due to testing tools, time and
therefore cost can be reduced to a greater level as testing tools ease the burden
of the test case production and execution.
7. Test enablers While development is not complete, some modules for testing are
not ready. At that time, stubs or drivers are needed to prepare data, simulate
environment, make calls, and then verify results. Automation reduces the effort
required in this case and becomes essential.
STQA 3
8. Test case design: Automated tools can be used to design test cases also.
Through automation, better coverage can be guaranteed, than if done manually.
The big question is how to select a testing tool. It may depend on several factors.
What are the needs of the organization; what is the project environment;
what is the current testing methodology; all these factors should be considered when
choosing testing tools. Some guidelines to be followed by selecting
a testing tool are given below.
1. Match the tool to its appropriate use Before selecting the tool, it is necessary to
know its use. A tool may not be a general one or may not cover many features.
Rather, most of the tools are meant for specific tasks. Therefore, the tester needs
to be familiar with both the tool and its uses in order to make a proper selection.
2. Select the tool to its appropriate SDLC phase Since the methods of testing
changes according to the SDLC phase, the testing tools also change. Therefore,
it is necessary to choose the tool according to the SDLC phase, in which testing
is to be done.
3. Select the tool to the skill of the tester The individual performing the test must
select a tool that conforms to his skill level. For example, it would be
inappropriate for a user to select a tool that requires programming skills when the
user does not possess those skills.
4. Select a tool which is affordable Tools are always costly and increase the cost of
the project. Therefore, choose the tool which is within the budget of the project.
Increasing the budget of the project for a costlier tool is not desired. If the tool is
under utilization, then added cost will have no benefi ts to the project. Thus, once
you are sure that a particular tool will really help the project, then only go for it
otherwise it can be managed without a tool also.
5. Determine how many tools are required for testing the system A single tool
generally cannot satisfy all test requirements. It may be possible that many test
tools are required for the entire project. Therefore, assess the tool as per the test
requirements and determine the number and type of tools required.
6. Select the tool after examining the schedule of testing First, get an idea of the
entire schedule of testing activities and then decide whether there is enough time
for learning the testing tool and then performing automation with that tool. If there
is not enough time to provide training on the tool, then there is no use of
automation.
STQA 4
Write short note on categorization of testing tools.
A single tool may not cover the whole testing process, therefore, a variety of testing
tools are available according to different needs and users. The different categories of
testing tools are discussed here:
1. STATIC AND DYNAMIC TESTING TOOLS: These tools are based on the type
of execution of test cases, namely static and dynamic:
a. Static Testing Tools: For static testing, there are static program analysers
which
scan the source program and detect possible faults and anomalies. Static
tools perform the following types of static analysis:
i. Control flow analysis: This analysis detects loops with multiple exits and
entry points and unreachable code.
iii. Interface analysis: It detects all interface faults. It also detects functions
which are never declared and never called or function results that are
never used.
iv. Path analysis It identifies all possible paths through the program and
unravels the program’s control.
b. Automated test tools enable the test team to capture the state of events
during the execution of a program by preserving a snapshot of the
conditions. These tools are sometimes called program monitors. The
perform following functions:
STQA 5
These tools are based on the testing activities or tasks in a particular phase of
the SDLC.
1. Tools for review and inspections Since these tools are for static analysis on
many items, some tools are designed to work with specifi cations but there
are
far too many tools available that work exclusively with code.
2. Tools for test planning The types of tools required for test planning are:
4. Test execution and evaluation tools: Coverage analysis, memory testing, test
management, network and performance testing.
Principle 2. Leadership: Leaders set the direction their organization should take, and
they must effectively communicate this to all the people involved in the process.
Leaders must set challenging but realistic goals and objectives. Leaders create a
positive environment and provide support for the employees to collectively realize the
organizational goal. They reevaluate their goals on a continual basis and
communicate the findings to the staff.
STQA 6
Principle 4. Process Approach: There are several advantages to performing major
tasks by using the concept of process. A process is a sequence of activities that
transform inputs to outputs. Organizations can prepare a plan in the form of
allocating resources and scheduling the activities by making the process defined,
repeatable, and measurable. Continuous improvement in processes leads to
improvement in efficiency and effectiveness.
Principle 5. System Approach to Management: A system is an interacting
set of processes. A whole organization can be viewed as a system of interacting
processes. In the context of software development, gathering customer requirements
for a project is a distinct process and designing a functional specification by taking
the requirements as input is another distinct process. There are simultaneous and
sequential processes being executed in an organization. A process is affected by the
outcome of some other processes, and, in turn, it affects some other processes in
the organization. It is important to understand the overall goal of the organization and
the individual sub-goals associated with each process. For an organization as a
whole to succeed in terms of effectiveness and efficiency, the interactions among
processes must be identified and analyzed.
Six Sigma
STQA 7
Six sigma is a quality model originally developed by Motorola for manufacturing
processes. It derives its meaning from the field of statistics. Sigma is the standard
deviation for a statistical population. Six sigma means, if one has six standard
deviations between the mean of a process and the nearest specification limit, there
will be practically no items that fail to meet the specifications. Therefore, the goal of
this model is to have a process quality of that level.
Eventually, six sigma evolved and was applied to other non-manufacturing
processes. Today, you can apply six sigma to many fields like services, medical, and
insurance procedures, call centers including software.
Six sigma is a way to achieve strategic business results emphasizing on lower costs
with less number of defects. Six sigma processes will produce less than 3.4 defects
per million opportunities. To achieve this target, it uses a methodology known as
DMAIC with the following steps:
Define opportunities
Measure performance
Analyse opportunity
Improve performance
Control performance
STQA 8
Software is not similar to any physical product, so the concept of software quality
also differs from physical products. Software has many possible quality
characteristics which mainly revolve around defects.
If a software has functional bugs, then it may be possible that the software is not able
to
perform the functions. Thus, software quality may be defined in the form of delivered
defect density or defect rate, i.e. the number of defects per unit size (e.g. LOC, FP, or
other unit).
Quality needs to be planned on a larger scale and all controlling and assurance
activities are performed according to quality plans.
SQM is simply a ay to assure quality in the sw. It is the set of activities which ensure
processes, procedures as well as standards suitable for the project are implemented
correctly.
If quality at some point is not under control, then it is the responsibility of quality
managers to manage the resources such that the required level of quality is
achieved.
STQA 9
A quality factor represents a behavioral characteristic of a system. Following are the
different Quality factors:
Reliablity: A large software system can have some functions which may not work
in all execution scenarios. However, the software may still be acceptable to
customers because the execution scenarios causing the system to fail may not
frequently occur. Customers may still consider an incorrect system to be reliable
if the failure rate is very small and it does not adversely affect their mission
objectives. Reliability is a customer perception.
Quality Criteria
Access audit: Ease with which software and data can be checked for compliance
with standards or other requirements
Access control: Provisions for control and protection of the software and data
Accuracy: Precision of computations and output
Communication commonality: Degree to which standard protocols and interfaces are
used
STQA 10
Completeness: Degree to which a full implementation of the required functionalities
has been achieved
Consistency: Use of uniform design and implementation techniques and notation
throughout a project
Data commonality: Use of standard data representations
Hardware independence: Degree to which the software is dependent on the
underlying hardware
Modularity: Provision of highly independent modules Operability Ease of operation of
the software
Self-documentation: Provision of in-line documentation that explains implementation
of components
Simplicity: Ease with which the software can be understood.
STQA 11