Software Test Documentation

This document provides an overview of software test documentation, including the system overview, test approach, test plan, and test cases. It also includes a bibliography and test logs. The subject is software testing and the course code is not mentioned. The college/university is not mentioned.

Running head: SOFTWARE TESTING
Software Test Documentation
Name of the Student
Name of the University
Author’s Note

1
SOFTWARE TESTING
Table of Contents
1. INTRODUCTION..................................................................................................................2
1.1. System Overview............................................................................................................2
1.2. Test Approach.................................................................................................................2
2. TEST PLAN...........................................................................................................................3
2.1. Features to be tested........................................................................................................3
2.2. Features not to be tested..................................................................................................4
2.3. Testing tools and environment........................................................................................4
3. TEST CASES.........................................................................................................................5
3.1. Case 1..............................................................................................................................5
3.1.1. Purpose.....................................................................................................................5
3.1.2. Inputs........................................................................................................................5
3.1.3. Expected outputs & Pass/Fail Criteria.....................................................................5
3.1.4. Test Procedure..........................................................................................................5
Bibliography...............................................................................................................................7
APPENDIX A. TEST LOGS.....................................................................................................8
A.1. Log for test 1..................................................................................................................8
A.1.1. Test Results.............................................................................................................9
A.1.2. Incident Report......................................................................................................11

2
SOFTWARE TESTING
1. INTRODUCTION
1.1. System Overview
The eStage application is developed for the management of the online backstage and
the application is designed to select the role of the each of the stakeholders associated with
the management of the backstage. The user needs to login into the information system by
selecting the roles and pass the authentication mechanism for using the different features
provided by the system. On successful login the user is redirected to the welcome page and
different links are provided for the different users. The user can select different options such
as home, logoff, competitors, discipline and sections. The user can get the details of all
processes on selecting the appropriate option and use the system wisely. The competitors can
register into the information system with all their details and the different functionality are
provided for each of the users with different roles. Like the stage manager can move the
competitor, withdraw or change the sequence of the competitors. The results or the
judgement can also be recorded in the information system by logging into the system and
inputting the scores and the results for the management of the information and automatically
distribute the results to the competitors.
1.2. Test Approach
For proceeding with the testing of the software application different approach must be
evaluated and the best approach should be selected for the testing the developed online
backstage management system. The limitation of the project is needed to be identified by
analysing the scope and objective of the project. The test document is prepared by following
the below testing on the developed information system.
Unit Testing – The unit testing is performed for the verification of thee codes and the logics
used for the development of the programs and it is compared with the current structure of the

3
SOFTWARE TESTING
framework. It is performed in the final stage of the software development for reducing the
errors and the bugs in the end product.
Integration Testing – It is used for testing the functionality of the developed software
product and it is done by developing the software into different modules and integrating it
with each other for finding its compatibility with the other module. For proceeding with the
system integration testing it should be evaluated in different platform such that it can run on
different hardware and software configuration.
Business requirement – The testing of the online backstage management software should be
done for the verification of the requirement meet by the solution and reduce the errors in the
final software product developed for the management of the information and functionality
required by the organization. The software product should be aligned with the business
requirement and the different criteria that should be meet by the information system should
be evaluated and tested for management of the defects in the final software. Different test
case should be designed and the test results should be documented for troubleshooting the
information system and increasing its efficiency.
User acceptance testing – A group of friendly users should be involved in the testing of the
information system and the main objective of this testing is to analyse the usability of the
information system. The interface of the final product should be developed such that thee
user does not face any difficulty for finding the different function and end to end flow of the
information should be identified such that the errors can be mitigated. The main participant of
the user acceptance testing can be the users for whom the information system is targeted and
different test case should be developed.
2. TEST PLAN
2.1. Features to be tested

4
SOFTWARE TESTING
The certificates used for the development of the functionality and samples of the data outputs
should be tested. The artifact’s that are needed to be tested should be included in the test plan
for the management of the information system. High level documentation strategy should be
used and a traceability matrix should be developed for the identification of the inputs and the
outputs of the information system. The modules for the stakeholders involved in the system
should be developed individually and tested during the integration of the system modules for
the identification of the errors in during the development of the system.
2.2. Features not to be tested
The security features implemented in the information system should not be tested because it
is not included in the management of the configuration and viewing the control of the
information system. It is considered that the risk for the information system should not be
considered and the network solution should be secured from the unauthorised access.
2.3. Testing tools and environment
A testing tool should be selected for the detection of the fault and the tool should meet the
following features such as;
 Partial or full monitoring of the program codes that should include the following:
o Instruction set simulator used for providing permission for the instruction level
monitoring and providing trace facilities.
o Animation of the program and permission for providing step by step execution
and implementation of conditional breakpoint at the source level and in the
machine code.
o Coverage of the code report.
 Symbolic debugging or formatted dump and allowing the inspection of the program
for the identification of the errors for the chosen point

5
SOFTWARE TESTING
 Benchmark used for the comparison of the run time performance
 Analysis of the performance for highlighting the hotspots and the usage of the
resources.
3. TEST CASES
3.1. Case 1
TC-1 Use Case- Login
3.1.1. Purpose
The test is performed such that the users does not face any error during logging into the
information system.
3.1.2. Inputs
The user should be selected from the dropdown list and input the password for logging into
the system and using the information system for the management of the backstage program.
3.1.3. Expected outputs & Pass/Fail Criteria
The user should be able to login into the information system and it should be redirected into
the welcome page of the information system. The user must be able to use the information
system according to their roles and responsibility and the user must be redirected to a
separate link depending on the roles and responsibility of the user.
3.1.4. Test Procedure
For designing the test plan the components in the information system should be divided into
different components and the testing procedure should be defines. The testing should be
divided into functional and non-functional testing. Different methodology should be followed
for the development of the specific methodology and proceeding with the test plan. The

6
SOFTWARE TESTING
scalability and the performance of the information system should be identified for testing the
security constraints. The defects and the failures should be identified and the usability,
performance, maintainability and the security of the information system should be considered
and a single defect in the system can cause different failure in the information system.
The faults should be identified early during the development of the information system and it
should be fixed for reviewing the requirement. For the testing the software the final step is to
create a test summary and the functionality of the different components should be included in
the test summary report for identification of the quality issues in the final software product.
Cost to fix a defect Time detected
Requirement Architecture Construction System
test
Post
release
Time
introduced
Requirement 1x 3x 5 -10 x 10 x 10 to
100x
Architecture - 1x 10x 15x 25 to
100x
Construction - - 1x 10x 10 to
25x

7
SOFTWARE TESTING
Bibliography
Barr, E. T., Harman, M., McMinn, P., Shahbaz, M., & Yoo, S. (2015). The oracle problem in
software testing: A survey. IEEE transactions on software engineering, 41(5), 507-525.
Black, R. (2014). Advanced Software Testing-Vol. 2: Guide to the Istqb Advanced
Certification as an Advanced Test Manager. Rocky Nook, Inc..
Briand, L., Nejati, S., Sabetzadeh, M., & Bianculli, D. (2016, May). Testing the untestable:
model testing of complex software-intensive systems. In Proceedings of the 38th
international conference on software engineering companion(pp. 789-792). ACM.
Deak, A., Stålhane, T., & Sindre, G. (2016). Challenges and strategies for motivating
software testing personnel. Information and software Technology, 73, 1-15.
Godefroid, P. (2015). Between Testing and Verification: Software Model Checking via
Systematic Testing. In Haifa Verification Conference.
Harman, M., Jia, Y., & Zhang, Y. (2015, April). Achievements, open problems and
challenges for search based software testing. In Software Testing, Verification and Validation
(ICST), 2015 IEEE 8th International Conference on (pp. 1-12). IEEE.
Kempka, J., McMinn, P., & Sudholt, D. (2015). Design and analysis of different alternating
variable searches for search-based software testing. Theoretical Computer Science, 605, 1-20.
Long, T. (2015, July). Collaborative testing across shared software components (doctoral
symposium). In Proceedings of the 2015 International Symposium on Software Testing and
Analysis (pp. 436-439). ACM.

8
SOFTWARE TESTING
Luo, Q., Poshyvanyk, D., Nair, A., & Grechanik, M. (2016, May). FOREPOST: a tool for
detecting performance problems with feedback-driven learning software testing.
In Proceedings of the 38th International Conference on Software Engineering
Companion (pp. 593-596). ACM.
Mäntylä, M. V., Adams, B., Khomh, F., Engström, E., & Petersen, K. (2015). On rapid
releases and software testing: a case study and a semi-systematic literature review. Empirical
Software Engineering, 20(5), 1384-1425.
Marculescu, B., Feldt, R., Torkar, R., & Poulding, S. (2015). An initial industrial evaluation
of interactive search-based testing for embedded software. Applied Soft Computing, 29, 26-
39.
Orso, A., & Rothermel, G. (2014, May). Software testing: a research travelogue (2000–2014).
In Proceedings of the on Future of Software Engineering (pp. 117-132). ACM.

9
SOFTWARE TESTING
APPENDIX A. TEST LOGS
A.1. Log for test 1
Task Artifacts Projected
Completion
Completion of the
test plan
Test Plan document Version
1.0
13/05/2018
Preparation of the
test environment.
Hardware and software
elements
20/05/2018
Execution and
recording the test
cases
Collection, Test Plan
Document version 1.0, Test
Result Document
27/05/2018
Submission of the
defects and
tracking the
changes to be done
in the system.
Unit Testing Results
Document
03/06/2018
Integration testing Test Plan Document Version
1.0
10/06/2018
Acceptance of the
client
Test Plan Document Version
1.0
17/06/2018
A.1.1. Test Results

10
SOFTWARE TESTING
Test
Case
Use
Case
ID
Description Result
TC-1 UC-1 The user should select the
role from the dropdown
list
The username and the password
validation is checked and the user
is granted to access the system
TC-2 UC-2 The information residing
in the information system
is edited and the view is
updated for selection of
the profile section of the
user
A pop up message is displayed on
successfully updating the system
and ask the user for confirming and
returning back to the profile page
of the user.
TC-3 UC-3 The reboot option is
required to be clicked and
the nodes linked with
system should be listed as
a node list.
A pop up message is required to be
generated after rebooting is done
and status of the machine becomes
ready for handling different
programs.
TC-4 UC-4 The add and delete option
is required to be managed
by the system admin and
control the operation of
the users.
A pop up message appears when a
user is created successfully.

11
SOFTWARE TESTING
TC-5 UC-5 Admin clicks on nodes
button and selects
add/delete node option
Confirmation screen is displayed
verifying that selected nodes are
added/deleted
TC-6 UC-6 Admin clicks the nodes
button, Once the nodes
are listed, clicks on the
Red power button
A message is displayed on startup
and the colour of the button
becomes green.
TC-7 UC-7 To list the user menus the
admin can click on the
accounts option placed in
the online back stage
management system.
.the list of the users are generated
with their name and the types.
A.1.2. Incident Report
The testing personnel’s involved in the testing of the software product is responsible to notify
the following:
 The software development team for reducing the errors
 Others as defined by the testing rules
 The individuals involved in the usability testing
The incident should also be reported to the directors and emails should be used for the
reporting. It helps in identification of the contact information and the report should
include the following details such as:
 Contact information of the test team

12
SOFTWARE TESTING
 Description of the incident
 Effort status and determining the incident cause.