Software Testing Policy
The Software Testing and Quality Assurance (QA) processes at Profectus aim to ensure that software products and services are delivered as specified and within the client’s quality expectation. The process to achieve this consists of activities designed to ensure that quality is built into the software at every level.
This document describes the basic set of practices that a QA Test Analyst should address and be in compliance with, during the activity of planning for testing of a project. It is used to facilitate communication regarding performance expectations by providing a common frame of reference regarding definitions and expectations.
This policy covers all software testing activities at Profectus, including any outsourced or contracted team members. Profectus employs an Agile development methodology and aims to continually increase emphasis on automated testing. Therefore this policy is written from that perspective
It is the responsibility of all software development and engineering staff to ensure the policies and guidelines contained and referenced herein are adhered to.
The relevant project, development and test team leads are responsible for ensuring all members of their team adhere to the principles contained within this document.
It is the responsibility of the CTO to ensure communication of this policy to all team members. This includes any updates or changes to the guidelines.
This document shall be reviewed at least annually as part of the overall policies review.
Test plans for each sprint and software release are compiled in consultation with the team and usually during the sprint planning process. The QA team will aim to fulfil the following objectives:
Test plans may be either documented on Confluence, or incorporated as a part of the Agile story card developed by the team and describing a feature or other unit of work, or both.
Prior to a release or at iteration end (as agreed), a test summary report is compiled and communicated to the team and other relevant stakeholders. Any internal project or product audits will include test plans and associated goals.
It is the responsibility of every software developer to unit test the code they write. Unit tests are executed as part of any normal build during the development cycle. Within a Continuous Integration (CI) environment, unit tests will execute across the complete code base and fail the build should anything not return as expected.
Unit testing remains the responsibility of the individual developer.
Acceptance testing aims to ensure that user expectations of new features are met by validating requirements against delivered software.
System testing ensures that the system performs as expected and integrates successfully within a sample deployment environment. A process sample is shown below. This includes:
Prior to production release, UAT may be performed to further mitigate any residual risk of usability issues or newly developed workflows not meeting end user expectations. An example of when this might occur is for customers that have a very specific or unique set of configuration settings in their production instance
Security testing aims to validate the fundamental assertion that a software application has sufficient security controls to ensure continued operation and withstand malicious attack.
Web application security testing focuses only on evaluating the security of the web application. The process involves an active analysis of the application for any weaknesses, technical flaws, or vulnerabilities. Any security issues that are found will be presented to the team, together with an assessment of the impact, a proposal for mitigation or a technical solution. Depending on the nature of the vulnerability discovered, this may result in immediate (patch) or at least near future unit work.
The six primary concerns to be validated and tested cover the following:
From the above, security testing results in the following information to support the business and ongoing development.
As a part of every software release, Profectus test resources will schedule internal security and penetration testing. Security and penetration testing is performed in separate production mirror environments in isolation from complete production instances and other testing and staging systems.
The recommended tool for internal penetration testing of Profectus applications and services is ZAP by the OWASP team. ZAP is an open-source web application security scanner allowing for complete penetration testing and scanning with a variety of configuration options and scenarios.
Where a security issue has been identified and deemed high or critical severity, the software release will not proceed and work is halted until the issue is resolved and validated.
Change management process and procedures are performed during any development stage for existing production systems. Change management control is applied where a product road map or client requested feature or item is scheduled for development.
Specifically, all production releases of software and all production configuration changes must be approved by the CTO.
Change management will consider the following before any work is scheduled or planned.
The above mirrors parts of the planning process at any stage within Profectus agile development. Any requested feature or other change will be scoped and prioritised with any other. Where appropriate, a change may not be implemented if it is determined that the cost or impact of the change would compromise the overall direction of the product or service.
The QA representatives for the project will be consulted for input on how this will affect any planned deliveries and to gain an appreciation of test scope and any specific QA requirements or issues that may be foreseen. Any estimation or similar process will include the QA component as a part of the change process.
Where a change is deemed to require an Information Security component or has some impact on Information Security, further analysis will be conducted to appropriately measure and define the scope of the Information Security change. Any Information Security controls required will be monitored and validated by the QA team to ensure that Information Security levels expected are maintained.
Changes will move through the development and QA cycle as with any other scheduled work.
+61 (3) 9009 8500
Level 12, 492 St Kilda Road
+64 (9) 215 3479 Profectus, Rewired, Level 2/96 Saint Georges Bay Road, Parnell, Auckland 1052
+84 (28) 7107 8108 Support Office
Level 2, Dinh Le Building
1 Dinh Le street, Ward 12, District 4, HCMC, Vietnam