170 likes | 343 Views
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
E N D
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 testing between two network elements, M-MGw and SGSN.
Contents • M-MGw and SGSN • Software Testing • Finding Faults Early • Background • Goals • Benchmarking • Results and Analysis • Conclusions
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.
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:
Finding Faults Early • When faults are detected and corrected as early as possible, costs can be reduced and development times can be shortened.
Background: Fault Finding Distribution • On the SGSN side a larger percentage of all found faults are detected earlier than on the M-MGw side.
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.
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.
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.
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.
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.
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.
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.