Testing best practice

Testing is a crucial element of software development. It can also be a complex activity to structure

correctly, and in a way that supports maximum efficiency. Because of this complexity, it is always

helpful to review processes and guidelines to ensure you are following best practices, and a great

place to start is with the ISTQB (International Software Testing Qualifications Board), who list seven

fundamental principles of testing.

What are the seven fundamental principles of testing?

These are the principles that have been collated and established by the ISTQB as testing and

software development has evolved over the years, and are recognised as the absolute core of testing.

The seven principles of testing

This article will explore these seven fundamental principles of software testing and the key

considerations surrounding your software testing approach.

1. Testing shows the presence of defects, not their absence

We test software to discover issues so that they can be fixed before they are deployed to live

environments – this enables us to have confidence that our systems are working. However, this

testing process does not confirm that any software is completely correct and completely devoid of

issues. Testing helps greatly reduce the number of undiscovered defects hiding in software, but

finding and resolving these issues is not itself proof that the software or system is 100% issue-free.

This concept should always be accepted by teams, and effort should be made to manage client

expectations.
It is important to remember however that while testing shows the presence of bugs and not their

absence, thorough testing will give everyone confidence that the software will not fail. Having a

comprehensive test strategy that includes thorough test plans, reports and statistics along with testing

release plans can all help with this; reassuring clients as to testing progress and providing confidence

that the right areas are being tested.

Additionally, ongoing monitoring and testing after systems have gone into production is vital. Thinking

forward to potential issues that could arise is another good way to help mitigate against any future

problems, for example considering load testing if a site is launching a new marketing campaign, so

you can be confident the software will withstand any anticipated larger volumes of traffic.

2. Exhaustive testing is impossible

As much as we would like to believe or wish it true(!), it is absolutely impossible to test EVERYTHING

– all combinations of inputs and preconditions – and you could also argue that attempting to do so is

not an efficient use of time and budget. However, one of the skills of testing is assessing risks and

planning your tests around these – you can then cover vast areas, while making sure you are testing

the most important functions. With careful planning and assessment, your test coverage can remain

excellent and enable that necessary confidence in your software, without requiring that you test every

single line of code.

3. Early testing saves time and money

Testing early is fundamentally important in the software lifecycle. This could even mean testing

requirements before coding has started, for example – amending issues at this stage is a lot easier

and cheaper than doing so right at the end of the product’s lifecycle, by which time whole areas of

functionality might need to be re-written, leading to overruns and missed deadlines.

Involving testing early is also a fundamental Agile principle, which sees testing as an activity

throughout, rather than a phase (which in a traditional waterfall approach would be at the end)

because it enables quick and timely continuous feedback loops. When a team encounters hurdles or

impediments, early feedback is one of the best ways to overcome these, and testers are essential for

this. Consider the tester as the ‘information provider’ – a valuable role to play.

Essentially, testing early can even help you prevent defects in the first place!

4. Defects cluster together

This is the idea that certain components or modules of software usually contain the most number of
issues, or are responsible for most operational failures. Testing, therefore, should be focused on
these areas (proportionally to the expected – and later observed – defect density of these areas). The
Pareto principle of 80:20 can be applied – 80 % of defects are due to 20 % of code!

This is particularly the case with large and complex systems, but defect density can vary for a range

of reasons. Issues are not evenly distributed throughout the whole system, and the more complicated

a component, or the more third-party dependencies there are, the more likely it is that there will be

defects. Inheriting legacy code, and developing new features in certain components that are

undergoing frequent changes and are therefore more volatile, can also cause defect clustering.

Knowing this could prove to be very valuable for your testing; if we find one defect in a particular

module/area there is a strong chance of discovering many more there. Identifying the more complex

components, or areas that have more dependencies or are changing the most, for example, can help

you concentrate your testing on these crucial risk areas.

5. Beware of the pesticide paradox

This is based on the theory that when you use pesticide repeatedly on crops, insects will eventually

build up an immunity, rendering it ineffective. Similarly with testing, if the same tests are run
continuously then – while they might confirm the software is working – eventually they will fail to find

new issues. It is important to keep reviewing your tests and modifying or adding to your scenarios to

help prevent the pesticide paradox from occurring – maybe using varying methods of testing

techniques, methods and approaches in parallel.

6. Testing is context dependent

Testing is ALL about the context. The methods and types of testing carried out can completely

depend on the context of the software or systems – for example, an e-commerce website can require

different types of testing and approaches to an API application or a database reporting application.

What you are testing will always affect your approach.

7. Absence of errors is a fallacy

If your software or system is unusable (or does not fulfil users’ wishes) then it does not matter how

many defects are found and fixed – it is still unusable. So in this sense, it is irrelevant how issue- or

error-free your system is; if the usability is so poor users are unable to navigate, or/and it does not

match business requirements then it has failed, despite having few bugs.

It is important, therefore, to run tests that are relevant to the system’s requirements. You should also

be testing your software with users – this can be done against early prototypes (at the usability

testing phase), to gather feedback that can be used to ensure and improve usability. Remember, just

because there might be a low number of issues, it does not mean your software is shippable –

meeting client expectations and requirements are just as important as ensuring quality.
Validation strategies in testing refer to the approaches and techniques used to ensure that a product or system
meets its intended requirements and specifications. Here are some common validation strategies used in
software testing:

1. **Requirements Validation**: Ensure that the product or system meets the specified requirements and
fulfils the needs of stakeholders. This may involve reviewing requirements documents, conducting
walkthroughs or inspections, and validating requirements through test cases.

2. **Functional Validation**: Validate that the product or system functions correctly according to its functional
specifications. This involves testing individual features and functionalities to ensure they behave as expected.
Techniques such as unit testing, integration testing, system testing, and user acceptance testing (UAT) are
commonly used for functional validation.

3. **Non-functional Validation**: Validate non-functional aspects of the product or system, such as

performance, reliability, security, usability, and scalability. Non-functional testing techniques include
performance testing, load testing, stress testing, security testing, accessibility testing, and compatibility
testing.

4. **Regression Validation**: Validate that recent changes or updates to the product or system have not
introduced new defects or regression issues. Regression testing involves retesting previously tested
functionalities to ensure they still work as expected after changes are made. Techniques such as automated
regression testing, selective regression testing, and impact analysis are used for regression validation.

5. **Data Validation**: Validate the correctness and integrity of data processed by the product or system. This
involves checking data input, storage, processing, and output to ensure consistency, accuracy, and compliance
with data requirements. Techniques such as boundary value analysis, equivalence partitioning, and data
validation rules are used for data validation.

6. **User Validation**: Validate that the product or system meets the needs and expectations of end-users.
This involves gathering feedback from users through usability testing, user interviews, surveys, and feedback
mechanisms to identify areas for improvement and ensure user satisfaction.

7. **Compliance Validation**: Validate that the product or system complies with relevant standards,
regulations, and industry best practices. This may involve conducting compliance audits, security assessments,
and validation against regulatory requirements and industry standards.

Overall, validation strategies in testing involve a combination of techniques and approaches to ensure that the
product or system meets quality standards, satisfies stakeholder needs, and delivers value to end-users.

Types of testing

https://www.geeksforgeeks.org/types-software-testing/

Integration testing
https://www.geeksforgeeks.org/software-engineering-integration-testing/

https://www.getsoftwareservice.com/integration-test-strategies/

Smoke testing

https://www.geeksforgeeks.org/smoke-testing-software-testing/

Acceptance testing

https://www.geeksforgeeks.org/acceptance-testing-software-testing/

system testing

https://www.geeksforgeeks.org/system-testing/

regression testing

https://www.javatpoint.com/regression-testing

WHAT IS SOFTWARE MAINTENANCE?

Software maintenance is the process of changing, modifying,
and updating software to keep up with customer needs.
Software maintenance is done after the product has launched
for several reasons including improving the software overall,
correcting issues or bugs, to boost performance, and more.
Software maintenance is a natural part of SDLC (software
development life cycle). Software developers don’t have the
luxury of launching a product and letting it run, they
constantly need to be on the lookout to both correct and
improve their software to remain competitive and relevant.

Using the right software maintenance techniques and

strategies is a critical part of keeping any software running for
a long period of time and keeping customers and users
happy.

WHY IS SOFTWARE MAINTENANCE IMPORTANT?

Creating a new piece of software and launching it into the

world is an exciting step for any company. A lot goes into
creating your software and its launch including the actual
building and coding, licensing models, marketing, and more.
However, any great piece of software must be able to adapt
to the times.

This means monitoring and maintaining properly. As

technology is changing at the speed of light, software must
keep up with the market changes and demands.

WHAT ARE THE 4 TYPES OF SOFTWARE MAINTENANCE?

The four different types of software maintenance are each
performed for different reasons and purposes. A given piece
of software may have to undergo one, two, or all types of
maintenance throughout its lifespan.

The four types are:

Corrective Software Maintenance
Preventative Software Maintenance
Perfective Software Maintenance
Adaptive Software Maintenance

C ORRECTIVE S OFTWARE M AINTENANCE

Corrective software maintenance is the typical, classic form of

maintenance (for software and anything else for that matter).
Corrective software maintenance is necessary when
something goes wrong in a piece of software including faults
and errors. These can have a widespread impact on the
functionality of the software in general and therefore must be
addressed as quickly as possible.

Many times, software vendors can address issues that

require corrective maintenance due to bug reports that users
send in. If a company can recognize and take care of faults
before users discover them, this is an added advantage that
will make your company seem more reputable and reliable
(no one likes an error message after all).

P REVENTATIVE S OFTWARE M AINTENANCE

Preventative software maintenance is looking into the future
so that your software can keep working as desired for as long
as possible.

This includes making necessary changes, upgrades,

adaptations and more. Preventative software maintenance
may address small issues which at the given time may lack
significance but may turn into larger problems in the future.
These are called latent faults which need to be detected and
corrected to make sure that they won’t turn into effective
faults.

P ERFECTIVE S OFTWARE M AINTENANCE

As with any product on the market, once the software is

released to the public, new issues and ideas come to the
surface. Users may see the need for new features or
requirements that they would like to see in the software to
make it the best tool available for their needs. This is when
perfective software maintenance comes into play.

Perfective software maintenance aims to adjust software by

adding new features as necessary and removing features that
are irrelevant or not effective in the given software. This
process keeps software relevant as the market, and user
needs, change.

A DAPTIVE S OFTWARE M AINTENANCE

Adaptive software maintenance has to do with the changing

technologies as well as policies and rules regarding your
software. These include operating system changes, cloud
storage, hardware, etc. When these changes are performed,
your software must adapt to properly meet new requirements
and continue to run well.

THE SOFTWARE MAINTENANCE PROCESS

The software maintenance process involves various software

maintenance techniques that can change according to the
type of maintenance and the software maintenance plan in
place.

Most software maintenance process models include the

following steps:

1. Identification & Tracing – The process of determining

what part of the software needs to be modified (or
maintained). This can be user-generated or identified by the
software developer itself depending on the situation and
specific fault.
2. Analysis – The process of analyzing the suggested
modification including understanding the potential effects of
such a change. This step typically includes cost analysis to
understand if the change is financially worthwhile.
3. Design – Designing the new changes using requirement
specifications
4. Implementation – The process of implementing the new
modules by programmers.
5. System Testing – Before being launched, the software
and system must be tested. This includes the module itself,
the system and the module, and the whole system at once.
6. Acceptance Testing- Users test the modification for
acceptance. This is an important step as users can identify
ongoing issues and generate recommendations for more
effective implementation and changes.
7. Delivery – Software updates or in some cases new
installation of the software. This is when the changes arrive at
the customers.

Software Maintenance Cost

The cost of software maintenance can be high. However, this
doesn’t negate the importance of software maintenance. In
certain cases, software maintenance can cost up to two-thirds
of the entire software process cycle or more than 50% of the
SDLC processes.

The costs involved in software maintenance are due to

multiple factors and vary depending on the specific situation.
The older the software, the more maintenance will cost, as
technologies (and coding languages) change over time.
Revamping an old piece of software to meet today’s
technology can be an exceptionally expensive process in
certain situations.

In addition, engineers may not always be able to target the

exact issues when looking to upgrade or maintain a specific
piece of software. This causes them to use a trial and error
method, which can result in many hours of work.
There are certain ways to try and bring down software
maintenance costs. These include optimizing the top of
programming used in the software, strong typing, and
functional programming.
When creating new software as well as taking on
maintenance projects for older models, software companies
must consider software maintenance costs. Without
maintenance, any software will be obsolete and essentially
useless over time.

Software maintenance strategies

All software companies should have a specific strategy in

place to tackle software maintenance effectively and
completely.

Documentation is one important strategy in software

development. If software documentation isn’t up to date,
upgrading can be seemingly impossible. The documentation
should include info about how the code works, solutions to
potential problems, etc.

QA is also an important part of a software maintenance plan.

While QA is important before an initial software launch, it can
also be integrated much earlier in the process (as early as the
planning stage) to make sure that the software is developed
correctly and to give insight into making changes when
necessary.
https://radixweb.com/blog/why-software-maintenance-is-necessary