At V-Key, we believe that the ability to deliver the high calibre of security which we offer, lies with how we uphold the quality of our engineering. Quality, in turn, is measured according to industry standards and the degrees of excellence.
Federal Information Processing Standards (FIPS) and Common Criteria (CC) are the standards we measured ourselves against, to attest to the quality and hence the level of security we provide.
Having said that, getting the quality in place is only the beginning as we need to ensure quality is maintained also after our solutions are implemented and integrated by our customers.
Hence, we have broadly grouped quality enforcement into two parts:
1. Regular code reviews
2. Levels of tests
Regular code reviews
We run regular code reviews as code changes are inevitable. For instance, there may be dead code or dubious conditions resulting in stack overflow situations potentially leading to security vulnerability; such situations will be part of the code review check list.
In the regular code reviews the developer who made the changes is required to perform their own unit tests before they check-in their changes and include them in the release notes.
At V-Key we also encourage peer reviews to promote cross training and unbiased reviews.
Excellent automation tools are used in this process as well to ensure total coverage.
Following the regular code review, A Project Lead or Architect will act as the final “gate-keeper” to ensure any changes made are carried out according to what was described in the release notes.
This level of reviews ensure good programming code integrity even before testing by QA.
Levels of Tests
At V-Key, our Engineering process includes the following industry level tests specific to V-Key’s market and solutions:
With the increase in mobile phones and related operating systems, compatibility testing is one of the most essential tests to date. To cover most of the industry norms, we used physical devices to test. For the rest, we use cloud-based devices.
No matter how small a change may be, there may very well be some impact on other components which may be missed out. This test ensures that no matter the size of the change, there is no breakage to the solution we provide to our customers.
Functional vs Performance Testing:
All functional aspects of the solutions are automatically tested by our Continuous Integration (CI) build.
Progressive performance testing takes place after all related functional testing is completed, and any performance issues will be fixed immediately. Functional testing will be repeated to ensure performance fixes do not break functional aspect of the solution.
To ensure the solution we have provided to our Customers is able to handle any situation, we will attempt to break our solutions by these tests. e.g. A known integer value is expected in the API. We will inject a non-integer into the API to test if it is able to handle it. But V-Key’s virtue, we aim to handle such situation gracefully.
Depending on the solution provided to our customers, usability aspects are vetted against our in-house or mutually agreed with our Customers’ standards, automatically and manually.
Penetration and Vulnerability test is part and parcel of every release we perform before proceeding to the next level of testing. Any findings are fixed immediately and all the above-mentioned tests are performed again. This ensures high security coding standards without breaking the functionality of the code.
Depending on change, each change in the scripts are subjected to the scrutiny of a few “gate-keepers” before being updated. Depending on the nature of the solution(s), this may be the initial or final test in the suite of tests to ensure the success of deploying components, change and etc
System and Operational Testing:
For every solution for release, we perform an end-to-end testing to ensure no surprises.
There may be situation, where permissible, we would deploy our solution(s) in production environment where it focuses on smoke test and other selected non-functional testing. This is commonly known as Operational Readiness Test (ORT)