DEVTOME.COM HOSTING COSTS HAVE BEGUN TO EXCEED 115$ MONTHLY. THE ADMINISTRATION IS NO LONGER ABLE TO HANDLE THE COST WITHOUT ASSISTANCE DUE TO THE RISING COST. THIS HAS BEEN OCCURRING FOR ALMOST A YEAR, BUT WE HAVE BEEN HANDLING IT FROM OUR OWN POCKETS. HOWEVER, WITH LITERALLY NO DONATIONS FOR THE PAST 2+ YEARS IT HAS DEPLETED THE BUDGET IN SHORT ORDER WITH THE INCREASE IN ACTIVITY ON THE SITE IN THE PAST 6 MONTHS. OUR CPU USAGE HAS BECOME TOO HIGH TO REMAIN ON A REASONABLE COSTING PLAN THAT WE COULD MAINTAIN. IF YOU WOULD LIKE TO SUPPORT THE DEVTOME PROJECT AND KEEP THE SITE UP/ALIVE PLEASE DONATE (EVEN IF ITS A SATOSHI) TO OUR DEVCOIN 1M4PCuMXvpWX6LHPkBEf3LJ2z1boZv4EQa OR OUR BTC WALLET 16eqEcqfw4zHUh2znvMcmRzGVwCn7CJLxR TO ALLOW US TO AFFORD THE HOSTING.

THE DEVCOIN AND DEVTOME PROJECTS ARE BOTH VERY IMPORTANT TO THE COMMUNITY. PLEASE CONTRIBUTE TO ITS FURTHER SUCCESS FOR ANOTHER 5 OR MORE YEARS!

software_testing_principles_and_theories

This is a general overview of many different principles and theories that accompany software testing as a whole. These principles and theories are generally observed as the correct method or ideology behind a specific context.

Testing Shows the Presence of Bugs

This is a half truth; it does show the presence of bugs, but only bugs that are being tested for! After the testing process is done for a system or module there may still be bug present but hidden within the system or module. As this is the case a test should be developed to cover as much ‘ground’ as possible, by testing as many different possibilities the amount of bugs that can be found will be increased.

Exhaustive testing is not possible

As the different variations of each function, process and module are huge in numbers it is illogical (not impossible) to test each different possibility, if a tester was to do this it would take them many years to complete and therefore cannot happen, a software tester has a timeframe that they must meet for each test. The tests must be designed to take into account as many different possibilities but not all of them.

Early testing

Early testing is good because it allows the developers to ensure they stay on track while developing the system or module. The tests should be created before the module is made so once the module is finished it can be tested to prove it does what it is meant to do.

Defect Clustering

Problems within a system or module have a common probability that there will be many bugs associated with a single problem, so taking care of one issue may not fix the other issues. When a cluster is detected it should be focussed on to ensure that all or most problems are fixed before moving on.

Pesticide Paradox

A good tester will use a huge range of different methods and software to detect many different bugs within the system, as using one specific method or software tends to lead to the ‘pesticide paradox’, that is, a system or modules bugs become ‘immune’ to the methods and tests due to the fact that all bugs that were detected and removed are no longer an issue, this ties into the ‘testing shows the presence of bugs’ principle.

Testing is context dependent

Each test should be developed individually, without borrowing too much from one test to apply to another, as each section is could be considered as a separate entity within the system each entity needs a different test to pass.

Absence of errors fallacy

Even though a software test provides no detectable bugs does not mean there are none! This normally proves that the software test is inadequate and should be rewritten to cover more areas of the system or module

Advantages and Disadvantages of Testing with Independence

Tests by the person who wrote the item under test

This should be avoided as the person that wrote the system knows what the system is supposed to perform and how it will do it. They will show bias as to the variations of what will be tested; this is not a good method. There are no real advantages to using this method.

Tests by another person within the same team, such as another programmer

This can be a better method of testing than using the same developer, since this programmer didn’t make the system or module there is no bias as to what variations of possibilities are used. A downside is that a programmer would be able to divulge into the code and understand what is meant to happen, thus creating bias.

Tests designed by a person from a different organisation or company, such as outsourced testing or certification by an external body

An external source of testing can be good as it allows for a more user based testing experience, since the external tester doesn’t understand the internal structure they can only rely on what they have for the interface. A disadvantage would be the external tester may not fully understand the needs of the business, and therefore test the wrong areas.

Experience based testing (including error guessing and exploratory testing)

This utilises the testers’ previous expertise in testing, it allows for greater coverage of tests as the tester is able to use their wisdom to test areas that may have not been covered otherwise, it also allows them to use error guessing, which is, to anticipate any errors or defects within the system from the testers previous experience.

Customer/ contractual and regulatory requirements (in relation to choosing a test technique)

When choosing a test technique it is good to develop definitions for the following objectives: What is in and out of the scope for the test? What are the objectives for the test? What are the high value risks that should be addressed? What are the constraints that hold back the testing? What parts of the project are most critical to complete?

Software_Testing


QR Code
QR Code software_testing_principles_and_theories (generated for current page)
 

Advertise with Anonymous Ads