Software development: Proof of concept
A proof of concept in the context of software development comes to be the validation of a functional or non-functional aspect of an information system or part of it, either by the technical area or by the user area.
We could say, for example, that acceptance tests are a specific type of proof of concept.
Therefore, it can be considered as a useful tool in the development process. However, it is convenient to adequately manage your expectations and objectives in the current context of the project and the information system, that is, what is intended to validate? What are the minimum thresholds required? Does the validation meet qualitative, quantitative or both criteria? What are the consequences of not exceeding them? Are the limits well calibrated concerning the effects on the Current status of the project and the current phase of its life cycle? Who will participate in the proofs of a concept know in advance what aspects are not going to have the expected behavior?
In a formal testing process, test levels are often very easily confused with test types, and although they are intimately related, they have different connotations in the process. To understand a little more, let’s start from the fact that the tests can be executed at any point of the software development process, and this is where the test levels allow us to understand the different aspects or stages where specific tests can be executed. Because of the above, it is common for some people to refer to the levels of evidence or try to classify them as developer tests, functional tests, and end-user tests.
Nevertheless, the appropriate terminology to apply to the different levels corresponds to the following four (4) classifications that are: unit tests, integration tests, system tests and acceptance tests. In each of these test levels, different types of tests may be executed, such as functional, non-functional, architectural tests and the change of the products associated.
Here is a brief description of each level of evidence:
Unit or Component Tests: This type of tests are typically executed by the development team.They consist of the execution of activities that allow the developer to verify that the unitary components are coded under robust conditions, that is, supporting the entry of erroneous or unexpected data and demonstrating, thus the ability to deal with errors in a controlled manner. Additionally, the tests on unitary components, usually denominated tests of modules or tests of classes, being the convention defined by the programming language the one that influences in the term to use. Finally, it is essential that all the functionality of each unit component be covered by at least two test cases, which should focus on testing at least one positive and one contrary feature.
Integration tests: It is as well executed by the development team and consist of checking those elements of the software that interact with each other, work correctly.
System Tests: This type of tests should be executed ideally by a test team outside the development team, a good practice in this point corresponds to the outsourcing of this responsibility. The obligation of this equipment consists in the execution of test activities where it must be verified that the total functionality of a system was implemented according to the specification documents defined in the project. The test cases to be designed in this level of tests must cover the functional and non-functional aspects of the system. For the design of test cases at this level, the team must use as deliverable test bases such as initial requirements, use cases, user histories, designs, technical and end-user manuals, etc. By last,
Acceptance Tests: Independently of the fact that the testing process has been outsourced and that the firm responsible, for these activities has issued a quality certificate on the system under test. It is essential that the client appoint personnel to be part of the business processes for the execution of acceptance tests, it is even recommended that the end users participating in this process be independent of the personnel that supported the development process. When the acceptance tests are executed in facilities or environments provided by the developer, they are called Alpha tests, when they are performed from the client’s infrastructure, they are called Beta tests. In cases where the acceptance tests of the product have been executed in the supplier’s environment,
On the other hand, the security of a system or application does not depend on the use of SSL protocols, firewalls or compliance with an ISO 27000 standard. The form of security tests (penetration testing) at the end of the software development cycle is not enough either.Security is a factor that must be taken into account in each phase of development since the production of software is a process in which it is necessary to identify and correct vulnerabilities continuously.
The key, therefore, is in the following question;
Are we building a secure software?
At our site we propose the following tools that help develop secure software:
Checkmarx, which is a source code tool used for security analysis, can be integrated with the most common SW development environments (Eclipse, MS-Visual Studio, Jira, Jenkins …) that will alert programmers to the vulnerabilities they enter in their code.
BlackDuck, a tool for analyzing the security, licensing and operation of third-party open source libraries used in the developments themselves. Also integrable with the usual development environments.
Contrast, a security analysis tool for the running application based on IAST (Interactive Application Security Testing), or what is the same gray box tests.
We help our clients in the implementation of the Secure SW Life Cycle, an essential practice:
(i).Analyzing the situation of SW processes and the SW development tools used.
(ii).Propose the most appropriate security tools in each case.
(iii).Performing concept tests for the proposed tools and their use in customer processes validity.
(iv).Forming and supporting development engineers.
From a practical point of view, the number of possibilities to exhaustively test a system is merely unmanageable; it is then necessary to use adequate techniques to maximize the number of essential failures found with the allocated resources. Each method used to detect defects leaves a residue of more subtle abnormalities against which this technique is ineffective.
The software test implies, therefore, the application of appropriate techniques and tools in the framework of a well-defined process, determined by the type of software development projects that are addressed.
For more information, please contact us, a top software development company in Vietnam to get free quote and consultancy.