explanation:
v
Explicit (Explicit): clearly defined and
documented
v
Implicit (implicit): not clearly defined and
documented but indirectly suggested
v
Requirements (Terms): business requirements /
products / software
v
Expectations (Hope): especially the end users
expectations
Two-way approach to software quality are common:
§
Defect Management Approach (Management Approach
defective)
Deficiencies
in the software can be regarded as a disability to address the needs of end
users (end-user requirements). It usually occurs because of misunderstandings
and errors in the design requirements, functional logic, data relationships,
process time, checking the validity, coding, etc.
Defect
management approach based on the calculation and manage shortages (managing
defects). Usually categorized by severity, and the numbers in each category are
used for planning. Organization of software development professionals typically
use tools like defect leakage Metrics (to calculate the number of errors which
pass through the stages of development (development) before it is detected) and
control charts to measure and improve the development process (development).
§
Quality Attributes Approach (Quality of
attribute approach)
This approach to software quality is best exemplified by the
quality of the model remain, such as ISO / IEC 25010: 2011. This standard
describes eight hierarchy of quality characteristics, each consisting of
sub-characteristics:
Ø
Conformity Functional (Functional Suitability)
Ø
Reliability (Reliability)
Ø
Operability
Ø
Performance Efficiency (Performance Efficiency)
Ø
Security
(Security)
Ø
Compatibility (Compatibility)
Ø
perwatan (Maintainability)
Ø
transferability
In addition, the standard defines quality in use model
consisting of five characteristics:
Ø
Effectiveness (Effectiveness)
Ø
Efficiency (Efficiency)
Ø
Satisfaction (Satisfaction)
Ø
Safety (Safety)
Ø
Usability
7 steps to improve
software quality
1. Define the quality balanced to the needs of
Impact on Quality: Meet business requirements, achieve a
satisfying user experience.
Benefits: Your ability to achieve improved quality for
application development teams are not burdened with unrealistic expectations
perfectly. Instead, it was rented to the definition of quality in accordance
with the time, resources, and budgets are given.
Relevant Roles: Business stakeholders, the entire
application development team.
2. Broadcast Quality Metrics It Simple
Impact on Quality: Reduce defects or lack or failure.
Benefits: Highly visible metrics keep quality top of mind
for the whole team and expose when efforts failed.
Relevant Roles: The entire application development team.
3. Fine-Tune Team
Impact on Quality: Meet business requirements, achieve a
satisfying user experience and reduce shortages or failures.
Benefits: team members perform in accordance with their
incentives, making quality improvement part of their goals reinforces desirable
behavior.
Relevant Role: Management.
4. Get the Right Terms
Impact on Quality: Meet business requirements, achieve a
satisfying user experience.
Benefits: Reduces repetition means less retesting and fewer
cycles, which greatly reduces the overall effort.
A relevant role: managers, business analysts, user
experience designers, architects.
5. Testing In Smart to reduce testing.
Impact on Quality: Reduce defects or failures.
Benefits: Focus on testing the most important risk areas and
ensure that they receive the lion's share of resources and the testing that
every bug that passes will likely be limited to the most important features.
Relevant Roles: Quality assurance manager.
6. Design Applications to Reduce Risk Bug
Impact on Quality: Reduce defects or failures.
Benefits: Simple, clean design to produce code that is
simpler, cleaner, and easier to test and re-which means that the code will have
fewer bugs and bugs will be easier to diagnose and fix.
A relevant role: Architects, developers.
7. Optimize Use of
Testing
Impact on Quality: Reduce defects or failures.
Benefits: Automation frees resources from the regular tests
to focus on the highest priority tests and improves the repeatability test
cycle.
Relevant Roles: Quality assurance, developer
What test strategies in software testing?
Test selection test approaches or strategies is one of the
most powerful factor in the success of the test effort and accuracy of test
plans and forecasts. This factor is under the control of the testers and test leaders.
Let us survey the main types of tests are common strategy:
·
Analytical
Ü
Let us take an example to understand this. The
risk-based strategy involves performing risk analysis using project documents
and input from stakeholders, the planning, estimating, designing, and
prioritize tests based on risk. Another strategy is the analytical test
requirements based strategy, in which the specification requirements analysis
form the basis for planning, estimation and design tests. Analytical test
strategies have in common the use of several analytical techniques formal or
informal, usually during the requirements and design phases of the project.
·
Model-based
Ü
Let us take an example to understand this. You
can construct a mathematical model for loading and response to e-commerce
servers, and tests based on that model. If the behavior of the system is tested
in accordance with that predicted by the model, the system is considered to be
working. Test strategies based models have in common the creation or selection
of several models that formal or informal important for system behavior,
usually during the requirements and design phases of the project.
·
Methodist
Ü
Let us take an example to understand this. You
may have a list that you have amassed over the years shows that the main areas
of the test to run, or you may follow an industry standard for software
quality, such as ISO 9126, to outline the area you big test. You then
methodically designing, implementing and running the tests following this
outline. Test strategies methodical have a common adherence to a pre-planned,
systematic approach has been developed in-house, assembled from a variety of
concepts developed in-housedan gathered from outside, or adapted significantly
from the external ideas and may have a start or end point of engagement for
testing.
·
Process - or standard-compliant
Ü
Let us take an example to understand this. You
may take the source of IEEE 829 standards for your test, using books like
[Craig, 2002] or [Drabick 2004] to fill the void methodological. Alternatively,
you may take one source of agile methodologies such as Extreme Programming.
Strategy or standard-compliant processing have a common dependence on external
approach is developed for testing, often with little - if any - customization
(customization) and may have a start or end point of engagement for testing.
·
Dynamic
Ü
Let us take an example to understand this. You
can make a lighter set of testing guidelines that focus on rapid adaptation or
known vulnerabilities in software. Dynamic strategies, such as exploratory
testing, has similarities to concentrate on finding a lot of possible defects
during test execution and adapting to the reality of the system being tested as
shipped, and they usually emphasize the final stage of testing. See, for
example, attacks based approach [Whittaker, 2002] and [Whittaker, 2003] and
exploratory approach [Kaner et al., 2002].
·
Consultative or directed
Ü
Let us take an example to understand this. You
may ask the user or system developers to tell you what to test or even rely on
them to do the testing. Strategy consultation or directed have the same
dependence on the non-testers to guide or conduct the testing effort and
usually emphasize the final stage of testing only because of the lack of recognition
of the value of the initial test.
·
Regression-averse (Regression-averse)
Ü
Let us take an example to understand this. You
may try to automate all test functions of the system, so that if it changes
anything, you can run any tests to make sure nothing was broken.
Regression-averse strategies have in common a set of procedures - usually
automated - that allows them to detect defects regression. Regression-averse
strategy may involve automating functional tests before releasing function, in
this case requires preliminary testing, but sometimes testing focused almost
entirely on the testing function that has been released, which in some cases
some form of engagement after the release test.
Some of
these strategies is more preventive, for others more reactive. For example, the
analytical test strategy involves an upfront analysis of a test basis, and are
likely to identify problems in a test basis prior to the execution of tests.
This allows the start - and cheap - the elimination of defects. That is the
power of a preventive approach.
Dynamic
test strategy to focus on the implementation period of the test. The strategy
allows the location of disabled and disabled groups which may be difficult to
anticipate until you have a system that is actually in front of you. That is
the power of a reactive approach.
There
is no one best way. We suggest choosing any test approach makes the most sense
in certain situations, and feel free to borrow and blend.
How do
you know which strategies to choose or mix (blend) for the best chance of
success?
There
are many factors to be considered, but let us highlight some of the most
important
§
Risk
Risk
management is crucial during the test, so consider the risk and level of risk.
For the application of well-established that develops slowly, regression is an
important risk-averse so regression strategy makes sense. For new applications,
risk analysis can reveal different risk if you choose a risk-based analytical
strategies.
§
Skills
Consider
the skills you have and the lack of testers because the strategy must not only
be selected, they must also be executed. A standards-compliant strategy is a
smart choice when you do not have the time and skills in the team to create
your own approach.
§
Aim
Testing
must meet the needs and requirements of stakeholders, interests to be
successful. If the goal is to find as many defects (errors) as possible with a
minimal amount of time and effort invested - for example, in a typical
independent test lab - then a dynamic strategy that makes sense.
§
Regulation
Sometimes
you have to meet not only the interests of stakeholders, but also the
regulator. In this case, you may need to plan methodically test strategy that
meets the regulator that you have met all their requirements.
§
Products
Some
products, such as weapons systems and software development contracts tend to
have the specified requirements. This leads to synergies with strategies based
requirements analysis.
§
Business
Business
considerations and business continuity are often considered important. If you
can use the legacy system as a model for the new system, you can use a strategy
based model.
You should choose the test strategy to factors previously
mentioned, schedule, budget, and constraints features of the project and
organizational and political reality.
Bibliography :
{ 1 komentar... Views All / Post Comment! }
Nice post, very helpful *thumbsup*
Email: benazir.imam.a.m@ittelkom-sby.ac.id
Web : https://www.ittelkom-sby.ac.id/
Posting Komentar