Project Test Plan
Project Test Plan (PTP) covers the Development, System, Acceptance, and Production Deployment test strategy for the Scigateway frontend, which relates to all project phases. This document provides high-level insight into the testing performed in the different layers of the system and explains the practice followed by the project team from the early project days to interim deployment, UAT and Production release. However, as the project progress, aspects of the Test Plan will be updated as and when the project scope change.
The Scigateway project is a new GUI platform for an existing system. The objective is to select libraries and frameworks to support the creation of a library of software components that can be used to create specialist GUIs for different aspects of Scigateway.
Project Test strategy is fragmented into development testing, system testing, and User evaluation and is carried out by various member of the team in different project phases.
- Functional and quality requirements user stories testing
- Unit and Integration testing for the developed code
- UI testing for usability
- WebAPI endpoints tested for functional, performance and security scenarios
- Browser compatibility testing in Chrome, Firefox and Edge
- Migration testing
- Penetration testing
- Accessibility testing
- Browsers that are not listed in-scope
For each sprint, the test strategy is split broadly into development testing, system testing, and user evaluation. These will be carried out by various members of the project team at different stages:
Development testing is managed and maintained by the project developers throughout the development phase. Automated Unit and Integration tests will be created and monitored around all the features where business logic materializes. Formal and informal peer reviews are performed throughout the project to ensure coding standards and good practice guidelines are followed. The code will have automated code analysis and unit test code coverage tools to monitor other quality metrics.
System testing is performed to verify that the delivered system fulfills the captured user requirements. Project tester upholds the system and regression testing of WebAPI and GUI test responsibilities; this includes the broad system testing lifecycle. System testing lifecycle begins when project development starts by defining the test scenario and carries on with the test execution, finding issues, results recording and concludes with regression and deployment testing. Automated regression tests shall be created where possible on a stable build and executed in a dedicated Test environment using managed test data.
Test scenarios will be developed for all the stories planned in the release either ahead of the development or during development and recorded in the story. Post-development the project tester will prepare and execute the test scenarios, to verify the functionality of user stories developed for the sprint. Activities for system test execution include:
- Execute pre-prepared test scenarios
- Update test scenarios to reflect any additions/changes in the story post development
- Identify and communicate defects to the developers
- Test with a variety of test data
- Carry out unscripted testing
Performance and scalability assessment will be performed throughout the development phase along with functional requirements testing to ensure the Scigateway performs well under the expected workload. System ‘Response time’ will be tested on all WebAPI endpoints with production like data. Performance testing will be a shared responsibility between the project tester and developers. Taurus may be used to measure the WebAPI endpoints response time. SiteSpeed may be used to measure the web page load time.
Functional requirements security like authentication, user access role, data confidence and similar will be in testing scope. In addition to that, OWASP ASVS Level 1 recommendations, which are in-line with the project requirements scope, will be assessed.
Browser compatibility testing will be carried out in the latest versions of Chrome, Firefox, Edge and Safari. GhostLab a synchronized browser testing tools will be used to perform browser compatibility testing.
In sprint review meetings, the project team will demonstrate the requirements implementation in the Test environment. Post-review meeting, the business users may perform the user acceptance testing in a stable environment to evaluate the functionality and usability of the application. Functional testing may be focussed on acceptance of the system requirements and Usability testing focussing on the GUI design, look and feel, ease of application use from the Business perspective. Any issue or suggestions identified in the user evaluation period shall be communicated to the development team for further action; most likely story creation and prioritization.
Defects identified in any part of the system testing will be recorded in the corresponding story; by marking the test scenario as failed and add ‘Comments’ with details. The story’s accountable developer will be notified about the same for further action. Should the defect identified claims to be out of the story scope or a low priority issue, a backlog item will be created and prioritized in the later sprints for further action, depending on the Business priority. Issues identified outside the story scope by the project team or Business users will be recorded in the backlog and prioritized based on the defect severity and priority. Any showstopper issue identified in the current sprint will be pulled into the working sprint for an immediate fix. Medium and Low priority issues will be moved into the backlog for future sprints.
Unit and Integration tests are carried out in different application layers like the app layer, service layer and similar. ‘tests’ folders are maintained in the source code repository in the corresponding layer folder, where unit and integration tests are managed.
- Test scenarios for all user stories
- A regression test document capturing key user flows. This regression test document may act as Acceptance test script (ATS) as well during user evaluation testing. ATS document will be written as the project pans out and will be completed just before the User Evaluation phase. The test script will be stored on the project repo.