Reference no: EM131506844

Relevant Objectives from the Unit Outline

- Apply different test case design techniques, recognising the strength and weakness of each and being able to choose techniques appropriately

- Examine a suite of test cases in terms of test adequacy coverage

- Implement a case study, demonstrating appropriate use of testing techniques and generate the test harnesses for the software system.

Task

You have just been hired as a software tester by a software company. You are asked to carry out software testing of a prototype system that the company has contracted a group of students to develop. Source code and limited amount of documentation associated with this software is available. Using the source code and the documentation provided for this initial prototype, the team leader for testing has asked your team to implement the testing of the system using Eclipse and JUnit.

Details about the specific software system can be found in the Case Study document. The assignment consists of you working in small teams. It is important that in the first two weeks you organise yourselves into three person teams and provide your lecturer(s) with the email addresses (ECU Student Account) of all members of your team. It is important for your team to meet and work on the project at regular intervals.

The complete list of deliverables at the completion of this assignment is shown in the table below.

Key Deliverables

A report describing:
(a) your testing approach/process,
(b) a table, showing the stages/progress in your testing process
(c) how to execute your test cases,
(d) Test Plan and defect report (Appendix 3)
(d) Results from implemented test cases (e.g. screen shot from JUnit on completion of test case execution), the faults you found and how they can be reproduced.
(e) Discussions and Conclusions

Other Relevant Artefacts
All Java files associated with implementation and execution of test cases (JUnit tests) - submit as zip files with appropriate names.

Presentation
Presentation of the testing process and summary of testing results (Power point slides).

In the section of your report for your testing approach, it should include a description of what steps you have undertaken (so that someone can repeat your approach by following the steps that you have outlined) and what testing techniques you have employed together with relevant artefacts (e.g. control flow graph in the case of white-box testing or equivalence classes in the case of black-box testing). Your report should have a Result section followed by a section on Discussion and Conclusion.

Meetings -- Minutes
Do not leave the compilation of minutes to the end of the project-it is an on-going activity. This deliverable is marked on a pass/fail basis, with a fail resulting in the loss of up to two (2) marks. Record your minutes following the template provided in Appendix 1. It would be expected that a team would meet weekly to discuss progress. Note that each item on the action list must have a unique identifier across the life of the project.

Peer Assessment
Each person's peer assessment (Word document) should be emailed to the lecturer by the same date/time as other deliverables in part B. If all team members have not submitted a valid peer assessment by the due date/time, then this will constitute non- submission of the project and will be dealt with under rule 39(5) of the Undergraduate Handbook.

Defect Report
See Appendix 3 for the template. Each member of the team is expected to develop test cases associated with one or more functionality of the software system by applying appropriate testing techniques (for example, black-box: equivalence partitioning, boundary value analysis; white-box: control-flow, data-flow). The test suite should be as complete as possible for testing your system. On each of the submitted suite of testcases, the name of the team member responsible for its creation should be clearly visible (see Appendix 3). This item of assessment may be used by the lecturer to adjust the marks for the individuals in the team if there is a wide disparity in terms of the quality of the work between different team members in this section.

Attachment:- Case study.zip