System Testing and Implementation

Chapter: 7

System Testing and Implementation

7. SYSTEM TESTING AND IMPLEMENTATION System testing and implementation is the last step in software development. So this last chapter discusses the system testing and implementation.

7.1 System Testing System testing is an essential step for the development of a reliable and error-free system. Once source code has been generated, software must be tested to uncover and correct as many errors as possible before delivery to your customer. Your goal is to design a series of test cases that have a high likelihood finding errors but how, there are different methods that provides a systematic guidance for designing tests that, Exercise the internal logic of software components, and Exercis Exercisee the input input and output output domain domainss of the progra program m to uncove uncoverr errors errors in the program function, behaviour, and performance. Software testing is a crucial element of software quality assurance and represents the ultimate review of specification, design, and code generation. The work product is a set of test cases designed to exercise both internal logic and external requirements is designed and documented, expected results are defined, and actual results are recorded. The primary objectives of testing software are to execute a program with the intent of finding an error; a good test case will find an as-yet-undercover error, and a successful that uncover an as-yet-undercover error.

7.2 Testing Strategies The basic strategies that were used for testing were following •

Specification Testing

•

Black Box Testing

•

White Box Testing

•

Regression Testing

•

Acceptance Testing

•

Assertion Testing

•

Unit Testing

Sales Tracking system 48

Chapter: 7

•


System Testing

Unit testing

Module testing

Subsys testing

System testing

Acceptance testing

Component testing

Integration testing

User testing

Fig 7.1 Testing Strategies Diagram

7.2. 7.2.1 1 Sp Spec ecif ific icat atio ion n Te Test stin ing g Even if the code testing is performed exclusively, it doesn’t ensure against against program program failure. failure. Code testing testing doesn’t doesn’t answer whether whether the code meets the agreed agreed specif specificat ication ionss docume document. nt. It doesn’ doesn’tt also also determ determine ine whethe whetherr all aspects aspects of the design design are implemented implemented.. Therefore, Therefore, examining examining specification specificationss statin stating g what what progra program m should should do and how it shoul should d behave behave under under variou variouss conditions performs specification testing. Test cases are developed to test the


Chapter: 7


range of values expected including both valid and invalid data. It helps in finding discrepancies between the system and its original objective. During this testing phase, all efforts were made to remove programming bugs and minor design faults.

7.2. 7.2.2 2 Blac Black k Box Box Te Testi sting ng Black-box testing is conducted at the software interface. In Black Box testing only the functionality was tested without any regard to the code written. If the functionality, which was expected from a component, is provided then black box testing is completed.

7.2.3 White Box Testing White-box testing, sometimes called glass-box testing is a test case design method hat uses the control structure of the procedural design to derive test cases. In White Box testing internal code written in every component was tested and it was checked that the code written is efficient in utilizing various resources of the system like memory or the utilizing of input output

7.2.4 Regression Testing In Regression testing the software was tested against the boundary conditions. Various input fields were tested against abnormal values and it was tested that the software does not behave abnormally at any time.

7.2.5 Acceptance Testing In acceptance testing the software was checked for completeness that it is ready. Normally Normally the quality assurance department department performs performs the acceptance acceptance testing that the software is ready and can be exported.

7.2.6 Assertion Testing


Chapter: 7

System Testing and Implementation In asse assert rtio ion n test testin ing g the the soft softwar waree is teste tested d again against st the the poss possib ible le

assertions. Assertions are used to check the program and various locations that whether the state of the program at a particular point is the same as expected or not.

7.2.7 Unit Testing In unit testing we checked that all the individual components were working working properly. properly. Before integration integration of the entire components components unit testing is essential because it gives a confidence that all the components individually are working fine and ready to be integrated with the other ones.

7.2.8 System Testing When When all all the the unit unitss were were work workin ing g prop proper erly ly and and unit unit test testin ing g was was performed then comes the time for system testing where we checked all the integr integrated ated compon component entss as a whole whole and looked looked for possib possible le discrep discrepanc ancies ies,, which could have arisen after the integration.

7.3 System Evaluation The objectives of the system evaluation are to determine whether the desired objective has been accomplished or not. Determining the merits or demerits of the proposed system over the existing is also covered in the system evaluation. This is concerned with the detailed study of the developed system, from implementation point view. At the end, some suggestions for the improvement of the system are coded.

7.4 Implementation This phase consists of bringing the new system into operation and turning it over the users. Briefly it involves following steps.

7.4.1 Training It involves


Chapter: 7


•

User Groups.

•

Administrators.

7.4.2 7.4.2 Instal Installat lation ion of Comput Computer er Equ Equipm ipments ents It involves •

Location.

•

Power Supply.

•

Space Requirement.

7.4.3Testing the New System System testing of the developed system was performed in these three steps.

7.4.2.1

Unit Te Testing

In unit unit test testin ing g the the diff differ eren entt modu module less of soft softwa ware re are are test tested ed independently errors. This helps in locating errors, in coding and logic that were contained within a particular module. For example testing of each tab canvas individually for validates entries.

7.4. 7.4.2. 2.2 2

Inte Integr grat ated ed Te Test stin ing g

After unit testing, combined testing of all modules was carried out. The purpose was to determine that all the modules are correctly interacting with each other.

7.4.2.3

System tem Testing

Final testing was done on the entire system to check that whether the desired specification and requirements are met or not. The main aim here was to determine the inconsistencies in the developed system. Hence the whole system was tested.

7.5

Put the New System into Operation At this point, a final dress rehearsal re hearsal sometimes runs. It is done in the following f ollowing

ways.


Chapter: 7


7.5.1 7.5.1 Direct/ Direct/Cra Crash sh Conver Conversio sion n In this approach, an entire new system is installed. The old system is completely dismantled, leaving the organization suddenly to rely on the new system alone. The advantage of the crash conversion is that when the old system is seriously inadequate or radically different from the new system and when when the the conv conver ersi sion on will will be so rapid rapid that that it will will not not seve severe rely ly disr disrup uptt opera operati tion ons. s. The The cras crash h conv conver ersi sion on also also has has disa disadv dvan anta tage gess i.e. i.e. the the cras crash h conversion is risky, and even for minor problem can seriously delay the impl impleme ement ntati ation on sche schedu dule le.. Caref Careful ul plan planni ning ng and and atte attent ntio ion n to detai detaill are are necessary for a successful crash conversion.

7.5. 7.5.2 2 Pilo Pilott Con Conve vers rsio ion n In this approach, the old manual system is replaced by the newly computerized system stepwise. That is one subsystem is chosen as the lead or pro proto toty type pe syst system em and and impl impleme ement nted ed befo before re all all othe others rs.. Only Only when when that that subsystem is completely operational can conversion of the next system can be consid considere ered. d. This This approa approach, ch, reduce reduce the chance chancess of sudden sudden ad total total system system failure. But it may take along time and money than other approaches.

7.5. 7.5.3 3 Para Parall llel el Conve Convers rsio ion n In this this appr approa oach ch the the prop propos osed ed syst system em run run conc concur urren rentl tly y with with the the existing system, processing exactly the same data. If the new system has been properly implemented, its results should be identical to the results of the existing existing system. The parallel parallel conversion conversion should should be conducted conducted for a complete complete processing cycle. The old system is available as a backup in the case of failure of the new one. Result Result obtain from the new system system can be compared compared to that old system.

7.6

Proposed Change Over Peeing in view the sensitivity of matter/data. matter /data. It is suggested that system should

be run parallel to manual system.


Chapter: 7



System Testing and Implementation

Recommend Documents