Software Testing Policy

Navigation Menu
    Add a header to begin generating the table of contents
    Scroll to Top


    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.

    Scope of this policy

    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

    Roles and Responsibilities

    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 planning

    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:

    • To plan testing early so testing activities may be started as soon as possible
    • To identify and engage key stakeholders in the testing process so that testing priorities and risks may be understood from all aspects of the business and technology
    • To ensure that products and services developed satisfy customer requirements in a systematic, reliable fashion.
    • The test plan facilitates the above by providing the team the following:
    • An understanding of the testing process
    • The set of expectations that the project team can have of the test team
    • The testing deliverables that will be created during the test process
    • The measurements to be collected during testing, as well as the ways that those measurements will be collated and reported
    • A roadmap of the strategies and approaches to be executed during testing
    • A tool for allowing accurate estimation (test effort), identification of resources, and risk analysis to be performed

    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.

    Test activities

    Unit tests

    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

    Acceptance testing aims to ensure that user expectations of new features are met by validating requirements against delivered software.

    System testing (aka SIT)

    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:

    • regression testing to ensure previously operating features have not been impacted by recent code changes
    • security testing to mitigate risk of vulnerabilities
    • performance testing to ensure the software will scale as required
    • reliability testing to ensure the software will degrade gracefully when infrastructure failures occur

    UAT testing

    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

    Application Security Testing

    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:

    • confidentiality
    • integrity
    • authentication
    • availability
    • authorisation
    • non-repudiation (data integrity and data origin)

    From the above, security testing results in the following information to support the business and ongoing development.

    • Independent verification of systems and configurations before they go live on your network.
    • Provide management with a proof of exploit, which outlines the assets that an attack can compromise.
    • Assessing the magnitude of potential business and operational impacts of successful attacks.
    • Testing the ability of network defenders to successfully detect and respond to the attacks

    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

    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.

    • Does the change fit within the overall scope and direction?
    • Will the change markedly alter or dilute the overall scope and direction?
    • How will the change be prioritised among other planned features and requirements?
    • How will the change affect clients and their expectations of the product?
    • How will delivery be affected from the scoped change?
    • How will the change be communicated to clients and users?

    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
    Victoria 3004

    New Zealand

    +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

    © Copyright Profectus Group 2020 – Privacy PolicyTerms & Conditions