1 / 17

Early Fault Finding in Mobile Media Gateway

Early Fault Finding in Mobile Media Gateway. Thesis Presentation 19.5.2009 Tanja Kolm. Supervisor: Doc. Timo Korhonen Instructors: M.Sc. Teemu Arvonen, Ericsson M.Sc. Kirsi Mikkonen, Ericsson. What is this thesis about?. The purpose of this thesis is to compare software

pules
Download Presentation

Early Fault Finding in Mobile Media Gateway

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Early Fault Finding in Mobile Media Gateway Thesis Presentation 19.5.2009 Tanja Kolm Supervisor: Doc. Timo Korhonen Instructors: M.Sc. Teemu Arvonen, Ericsson M.Sc. Kirsi Mikkonen, Ericsson

  2. What is this thesis about? The purpose of this thesis is to compare software testing between two network elements, M-MGw and SGSN.

  3. Contents • M-MGw and SGSN • Software Testing • Finding Faults Early • Background • Goals • Benchmarking • Results and Analysis • Conclusions

  4. M-MGw and SGSN (1/2) • The Mobile Media Gateway (M-MGw) acts like a bridge between different networks, connecting various transmission technologies and protocols together. • The M-MGw is responsible for speech and circuit switched data processing, user traffic handling, routing and switching. • The Serving GPRS Support Node is responsible for enabling packet switching in network systems using the GPRS technology. • The SGSN forwards incoming and outgoing data packets, manages session and mobility of mobile terminals, and maintains IP connectivity.

  5. M-MGw and SGSN (2/2)

  6. Software Testing • Testing is a significant part of software development. • The scope of software testing is to find faults in the software implementation and to ensure the quality of software products. • Software testing can be divided into different test phases and integration levels:

  7. Finding Faults Early • When faults are detected and corrected as early as possible, costs can be reduced and development times can be shortened.

  8. Background: Fault Finding Distribution • On the SGSN side a larger percentage of all found faults are detected earlier than on the M-MGw side.

  9. Goals • What are the reasons for differences found in fault finding distribution? • This goal is planned to be achieved by comparing different testing activities of the M-MGw and SGSN organizations, and analyzing the results. • How the M-MGw organization could utilise the ways of doing things in SGSN testing?  Research methods: Interviewing specialists both on the M-MGw and SGSN sides.

  10. Benchmarking • After some investigations, the four research areas were settled on: • Team structures • Test phases • Fault report handling • Quality issues  These areas of software testing were then examined further.

  11. Results and Analysis (1/4): Team Structures • Cross-functional teams are used in early testing of the SGSN, whereas on the M-MGw side traditional discipline-centred teams are utilised: • Early testing of the SGSN is more effective, thanks to cross-functional teams. • Cross-functional teams are constructed around different quite independent features, teams of M-MGw testing around different software modules.  The node architecture of the M-MGw sets some limitations to form feature-based teams.

  12. Results and Analysis (2/4):Test Phases • In SGSN testing some tests of the later phases are performed already in early testing: • This is possible because of the effective tools used in SGSN testing to simulate the node. • Cross-functional teams bring needed knowledge. • It is possible to detect such faults that in M-MGw testing would be found only later. • The M-MGw has real time requirements because of its circuit switched nature, and a large amount of different processors.  The simulation of the node would be difficult.  Test executions should be done on the real M-MGw node.

  13. Results and Analysis (3/4):Fault Report Handling • The Fault report handling is done effectively on the SGSN side: • Fault report writing guidelines are given to the testers. • Lead-time of the fault report handling process has shortened and the amount of open fault reports has decreased. • Concentration on fault report corrections instead of testing the new functionality. • Writing fault reports is not mandatory inside the cross-functional teams. • The number of open fault reports is high in M-MGw testing. • This requires some actions.  Effective fault report handling improves testing.

  14. Results and Analysis (4/4):Quality Issues • Internal quality models, the ISO 9000 quality standard and different test metrics are used both in M-MGw and SGSN testing. • Not any notable reasons explaining the differences in fault finding distribution. • Quality doors, i.e. requirements that have to be fulfilled before delivering software from one test phase to the next, are better followed in SGSN testing. • This assures that the quality of the software is good enough before delivering it further. • Not so many faults left to be found on the later test phases. • Time schedule of the M-MGw testing prevents to hold on to strictly these requirements.

  15. Conclusions • In the M-MGw organization the close attention should be paid to early quality and early testing. • The use of cross-functional teams should be considered in M-MGw testing. • According to the possibilities, some later test activities should be included already in early testing of the M-MGw, using the real node. • The amount of open fault reports should be decreased in the M-MGw organization by concentrating on fault report corrections instead of testing the new functionality. • Quality door requirements should be more strictly followed on the M-MGw side.

  16. Questions

More Related