What is Product Quality Assurance?
Last updated: Oct 21, 2020
Product quality assurance is a means by which Octiga can ensure the overall quality of the products and service which are used by our clients. It is our rigorous commitment to quality that ensures that you, the client receive the product functionality and service level that you expect, that the product is safe to use, and that your data is safe and that your business can leverage the product with confidence.
It has three main constituents:
- Software Quality Assurance is a means and process by which Octiga can monitor the methods used in software projects to ensure proper quality of the software and in turn the product.
- Service Quality Assurance is commitment to a provision of certain level of service, and also a means by which this service is provided
Software Quality Assurance
Octiga commit to the engineering of highest quality of software in our products. Here we cover the verification processes that occur in the software development lifecycle (SDLC), the risk analysis for risk mitigation, software assessment and secure coding standards
SDLC Quality Characteristics
Octiga utilise the most modern agile development software techniques, Continuous-Integration and Dev-Ops throughout the SDLC.
We employ a customed version of scrum, which provide the following characteristics which we feel produce the highest quality product in an efficient manner
- Fast and iterative release cycle of small pieces of decoupled working functionality
- Easily defined deadlines and projected deliverables at those deadlines
- No fixed deliverables. Only working features becomes released
- Emphasis on Collaboration, communication, transparency and the identification of risks
- Early and often fault and failure identification
- Suitable for our small development team
- Tuned for feedback at every level of the project
- Tuned for customer interaction and feedback
- Tuned for quick change feedback to change request implementation
SDLC Stages and Quality Assurance
The SDLC has the following defined stages, each of which have defined checks and associated gates. At each gate ricks are assessed, and failures/flaws are identified. Through each stage pass sets of atomic work items (deliverables), each of which must pass these checks. Any failing items (and their dependencies) are thus independently and efficiently stopped from progression. As such only high-quality working features and functions become deployed to the product. It should be noted that an entire SDLC iteration from requirements through Review takes a short-fixed period. This period can be called a sprint. In Octiga the sprints are only 1 week in duration. Hence feedback and continuous improvement, and hence quality, are maximised, while also rapidly producing features and fixes for client needs.
The data includes:
This phase identifies, specifies, analyses, and documents all the requirements that the software must satisfy regarding functionality, performance, design constraints, attributes, and external interfaces. It is important to perform a risk assessment during this phase.
This phase identifies the features and function which can reasonably and safely reach deployment and maintenance. Risky items are held back for further breakdown and risk mitigation, both to the features themselves and to the system as a whole
This phase develops, documents, and reviews a design that satisfies the requirements previously documented. As complexities and interdependencies are better understood, ill understood or risky items will be returned to planning or requirements phase
The development phase is about writing code and converting design documentation into the actual software within the software development process. There aren’t many changes between the iterations here, however previously unidentified risks and complexities are communicated directly with the product leads and technical leads. If needs be items are returned to the design phase and often moved
- Integration, Testing and Code Review
This stage is spent on making sure that the software is bug-free and compatible with everything else that the developers have written before. Open and transparent code reviews are completed by all team member in order to maximise peer learning. The more complex and interdependent items are reviewed by more senior/experienced engineering leads. The Quality Assurance (QA) team conducts a series of tests in order to ensure the code is clean and business goals of the solution are met.
During the further iterations of this SDLC stage, the testing becomes more involved and accounts not only for functionality testing, but also for systems integration, interoperability, and user acceptance testing, etc.
Features passing the previous phase are deployed to the production environment and provided to the customers — either for the demo or the actual use. Deployment is done incrementally to serverless environments where iterations update the already installed software, introducing new features and resolving bugs. Serverless environments mean that technology upgrades and configuration updates are all deployed as code and maintained in the codebase. In this fashion we can ensure that there are no tangible differences, right down to the infrastructure level, between testing/staging environments and production environments. This in turn ensures that features perform as tested and that crucially changes can be backed safely in exceptional failure scenarios
Product owners, Developers and QA team meet to discuss the lifecycle iteration and how the requirements were met, what requirements were not met and any improvements that can be made to any stages of the process from arising issues. These are taken into consideration for the next iteration in a manner of continuous improvement
- Monitoring and Maintenance
The deployed product, the infrastructure on which it resides, and the client interactions are monitored for defects and failures on a continuous basis. On the server side this is done using various monitoring and alerting functions. Failures are also monitored on the clients web browsers in real time. This information is sent (anonymously) to our bug analytics platform which alerts on issues as they arrive. Furthermore, issues are counted and compared across all clients to find issue trends other important quality metrics. Alerts are continuously monitored by the development team. High impacting issues immediately trigger break fixes/ hot fixes. Such fixes can be deployed immediately in exceptional circumstances. Other issues are triaged and fed back into the SDLC for consideration in the next iteration.
Secure Development Practices
While our SDLC ensures the quality of and functionality of our finished features, functions, and overall product, we still require a method of ensuring our software is free from security vulnerabilities. Such rigor protects the clients by ensuring their data is secure, within our services, from malicious intent or theft by external threat actors.
To this end Octiga employ a secure software development culture. Employing a deep rooted culture rather than ad hoc contracted security specialists is a superior approach in that it is maintainable and consistent throughout our development process. Once embedded it is easy to self-perpetuate at minimal cost and risk of degradation. The mantra of this approach is to secure while we work rather than after were done and by implementing secure techniques before employing specialized security libraries. This technique is borrowed from the Synopsis Agile Security Manifesto
The practices enshrined in this culture conform with the recent National Institute of Standards and Technology (NIST) Secure Software Development Framework. The framework outlines a set of practices which are integrated with the SDLC and involve all the key actors and stakeholders in the organization.