Now days we are fully aware of the cost associated with the lack of quality of software to companies who buy a software product as well as also to the companies who generates the same software part. The job of improving quality on a restricted cost base is a hard one.
A client will never like a costly and hectic problem with software that doesn’t work, isn’t completed on time, does not encounter specifications, effects customers adversely, has bugs or is too difficult to use! The importance of testing as well as related activities began at the start of a project.
The STE plays a part in the SDLC as testing is not just finding bugs but it is the systematic valuation of an application’s fitness for the purpose it has been designed for.
Properly perform STE is not just so much verification of functionality of your product, though verification that your software expansion process produces high quality at each and every step. Testing implies throughout the lifecycle for maximum project benefit
• Requirement here test cases works on gathering requirements so no ambiguity left regarding requirements.
• Design test component addresses the desire to define the number of tests to be performed, the conducts that testing will follow and the test conditions that need to be work out.
• Implementation at this phase testing done to check the functionality basically.
• Verification it makes sure that the product is designed to deliver all functionality to the customer.
• Maintenance to ensure the quality of the product after handing it over to the customer.
The responsibility of STE, afterward, is not merely to make sure your product works. It is to make sure that the business you are building around your product works the method you planned, by make sure that your product’s satisfies the target audience well.
While there are a number of STE processes and tools that one can use, there is no silver bullet for ensuring that all STE requirements are completely managed. However as with development, there is a very rich pool of practices, skills and training to draw on. The basic problem I faced while testing projects was dealing with the time management and this was due to missing requirement. Test plans are related to the requirements that lead to effective testing. Often, the requirements are missing, incomplete, incorrect, ambiguous, or uneven. Low level requirements are mostly derived from high level sources. Likely verification methods may be vague and the tracing between requirements and tests may be missing.
• In 2012, a leap year bug cause a leading multinational corporation’s cloud computing service outage, this affected Governments and also consumers. The same leap year date bug also affected an Australian payment system resulting in 150,000 customers being prohibited from utilizing private health care cards for two days.
• In 2011, two commuter trains hit following a landslip north of Wellington, while luckily no one was hurt. The investigation originate that a computer glitch meant KiwiRail did not warn on heavy rain condition, this could have minimized the damage.
• In 2010, a bug in the software system at Gisborne Hospital affected in one patient’s data being showed as however it were another patient.