Testing
Unit Testing
The Unit Testing, in other words, the component testing checks the functionality and searches for potential defects in units of the application that can be tested separately including program modules, objects, classes, functions, and others. As a rule, the unit testing is performed by calling the code that should be checked and supported by development environments such as frameworks for unit testing or debugging tools (Chaffer & Swedberg, 2011). All found defects are usually corrected in the code without formal descriptions of bugs in the system management by the Bug Tracking System.
One of the most effective approaches to unit testing is a preparation of automated tests before the start of the main coding that is a test-driven development approach or test-first approach.
Integration Testing
Integration testing is designed to test the interplay between various segments of the system.
There are several integration testing levels:
- Component Integration Testing checks the interaction between the system components after their testing.
- System Integration Testing checks the interaction between different systems after the system testing.
- Bottom-Up Integration that examines all the low-level modules that are combined before testing.
- Top-Down Integration that examines all the high-level modules, and gradually one after the other low-level ones (Whitman & Mattord, 2011).
System Testing
The principal task of system testing is to check both the functional and non-functional requirements of the system as a whole. It identifies defects such as incorrect use of system resources, unintended combinations of user-level data, the incompatibility with the environment, unintended use cases, missing or incorrect functionality, and other aspects. To minimize the risks associated with the peculiarities of behavior in the system in a particular environment during the test, it is recommended to use the environment as close to that on which the product will be installed after the issuance (Firesmith & Jones, 2014). One might distinguish two approaches to the system testing that are as follows:
- Requirements based when for each requirement or test cases, the compliance verification should be provided.
- Use case-based that is focusing on the idea of ​​how to use the product are use cases of the system.
User Acceptance Testing
This type of testing process verifies compliance with the requirements of the system and is aimed at determining whether the system meets the acceptance criteria; a decision by the customer or other authorized persons concerning the acceptance of the application.
User Acceptance Testing is performed based on a set of typical test cases and scenarios developed based on the requirements for the application.
The decision to conduct acceptance testing is made when the product has reached the required level of quality or the customer is familiar with the Product Acceptance Plan or another document that describes a set of actions related to the acceptance test, the date, and other peculiarities.
Pilot Implementation
In case the customer belongs to the same organization as developers, such testing is usually called alpha testing. If the customer wants to test the software product before its official readiness, it is called beta testing. Both alpha- and beta testing are the appropriate forms of the Pilot Implementation, under which the system is installed on a trial basis to identify defects.
Parallel Testing
Parallel Testing is the technique when the behavior of the new (or modified) applications is compared with the behavior of the reference application (Drabick, 2013). The term parallel testing can also be used to refer to the method of the testing when several testers and automation systems perform the testing at the same time, in other words, parallel.
Defined and Repeatable Change Management Process
One of the main causes of failed IT projects is the uncontrollable flow of changes leading to project failure. Figures described in the article by Hu and Liu (2008) might be rather useful to achieve the desired result of the successful change management process implementation.
Speaking of Figure 1, it seems necessary to analyze it in detail. First of all, the Request for Change should be received. The initiator expresses a requirement that goes beyond the scope of the project and is a change. Then, the CCB evaluation should be conducted. The above process allows an understanding of how the proposed change will affect the project. Also on the stage of the analysis, the consequences should be assessed. After that, the required changes should be made. Finally, the verification of the results along with their testing would complete the project. The described change management implementation plan is clear and concise.
However, Figure 2 allows an even more elaborate scheme. Based on the discussion of the proposed changes should be made one of three decisions such as to accept, to reject, or to postpone changes.
At the same time, there are potential additional actions that might enhance the change management implementation plan. For instance, ensuring the use of standard methods and procedures for effective and rapid response, analysis, documentation, current management, and testing. Moreover, the increase of transparency and communication between the customer and IT might contribute to the improvement of the process flows.
References
Chaffer, J., & Swedberg, K. (2011). Learning jQuery: Create better interaction, design and web development with simple JavaScript techniques. Birmingham, UK: Packt Publishing.
Drabick, R. D. (2013). Best practices for the formal software testing process: A menu of testing tasks. New York, NY: Dorset House.
Firesmith, D. G., & Jones, C. (2014). Common system and software testing pitfalls: How to prevent and mitigate them: Descriptions, symptoms, consequences, causes and recommendations. Upper Saddle River, NJ: Addison-Wesley.
Hu, E., & Liu, Y. (2008). IT project change management. Proceedings from IEEE Xplore 2008 International Symposium on Computer Science and Computational Technology, 417-420.
Whitman, M. E., & Mattord, H. J. (2011). Roadmap to information security: For IT and InfoSec managers. Boston, MA: Cengage Learning.