Software Test Plan - Powerpoint

Software Test Plan - Powerpoint Presentation and Speaking Notes

The testing plan that will be configured in this presentation is aimed at providing both a series of steps and phases proposed for the actual testing of the log book application and an overlook of the logistics involved in the testing process, including human and financial resources and the instruments proposed for the monitoring and reporting mechanism.

Scope and Objectives

The main objective of the testing phase in this case is to ensure that the newly created student e-portfolio fulfils all of its assigned and designated functions, including providing a detailed transcript of each completed course and uploading the students' particularities in terms of extra curricular and social activities (participation in different clubs and work groups, membership in different societies etc.).

At the same time, the testing phase will aim to ensure that the application performs its main function, which is that of providing a useful and functional interface between the students and the academic environment: besides the student part of the application, the academics will be able to use this software tool in order to give students feedback on their coursework, projects and general feedback as well as validate their overall marks and degree classification.

The test plan will aim to provide a reasonable step-by-step process by which the application can be tested, but also emphasize some of the segments of the application that are not functional, as well as describe why the respective part of the application is not working properly. The testing phase will need to properly pass on to the developing team the description of the problem, so that this can be tackled by the programmers.

Test phases

The test phases revolve around the different parts of the application. The presentation will be constructed around each particular phase, suggesting different potential areas that should be kept under observation, as well as the steps that can be taken in order to ensure the functionality in that area.

The testing phase will however begin with the conception of a test document that will include and list some of the main operations that the application will need to perform. A simple yes/no checklist is enough to ensure that each of these has been tested and the functionality checked.

Log in - the log in functionality will test the student's ability to log in to his own account and to see the proper material. The log in phase will also additionally test an academic account, in order to ensure that teachers can also log in and see the right information, in conformation with the characteristics of their user. The log in function will be tested by creating a new user (either student or teacher), with a user name and password, and logging in the application. Two things will be recorded: (1) the capacity of the user (either academic or student) to properly log into the application, without any errors on the part of the software and (2) the capacity of the user to access the appropriate information according to his status.

Application accessibility - this phase will virtually test that the different categories of users all have access to the appropriate information. The testing will imply creating a fictive user for each of the categories (we have identified three categories of access so far: students, academics and administrative staff), accessing with each user the different parts of the application and ensuring that the appropriate rights for each user are reflected in terms of accessibility. For example, in the case of a student user, the testing in this phase will make sure that the user can upload details related to their extra curricular activities, memberships to clubs/societies, and student union; ensure that the student user has access to the course transcripts as uploaded by the academics; and ensuring connectivity with other users.

User connectivity. This is an important phase of the testing mechanism, aimed at ensuring the appropriate correlations between the functions performed by the different users. The idea of this testing phase is to ensure that the modifications, uploads and changes performed by one of the users is reflected immediately in the application and can be seen by all the existing users. In this sense, the testing procedure will involve the use of two different computers. On one of the machines, user a (an academic, for example) will perform a routine operation such as loading a course into the application. On the other machine, user B (a student) will check if he can actually see the uploaded document.

Resources

There are two categories of resources to be taken into consideration:

Human resources. In terms of human resources, one needs to determine the number of testers that will be required by the respective testing process. A number of three testers would be ideal for each of the identified categories of users (students, academics, administrative and support staff). This would allow both for alternative and simultaneous testing, involving testers using more than one computer an attempting to coordinate users operating at the same time. The testing team will need to be completed with a tester supervisor, someone who can (1) coordinate with the developing team and act as an interface for the testing team and (2) coordinate the entire testing process and the testing team.

Financial resources. The financial requirements will include salaries for the testers, as well as additional fixed and administrative costs, such as computers and required software.

Monitoring, feedback and reporting

The monitoring and feedback, as well as the reporting function, are essential for a proper development of the testing phase. In this sense, the monitoring and feedback mechanism will need to verify that the errors found are properly recorded and that a functional relationship is constructed with the development team. Ideally, the errors should be solved as they are discovered, which would imply a permanent contact between the testing team and the development team. At the same time, the monitoring and feedback mechanism will probably also need to include some of the other shareholders involved. This can probably be done in the form of regular weekly meetings and updates on the matter at hand.