The Achilles’ Heel of Continuous Integration: Business Process Testing
#ICYDK: These days, it’s hard to have a conversation with anyone related to application delivery without the word “continuous” being brought up. If an application is not being developed, tested or deployed in some continuous fashion, the inevitable question is, “Why Not?” DevOps purists working on the development team may say, “if you’re not testing within Continuous Integration cycles, then you’re not really testing.” Testers working within QA, who don’t want to be associated with the stigma of testing taking forever and stalling a project, will banter about the merits of Continuous Testing. But are both really needed? Are there differences in when and where Continuous Integration (CI) and Continuous Testing (CT) should be applied based on the system(s) under test?
Continuous Integration (CI) as the Best Approach
As a starting point, let’s say CI is the best approach. Every unit of code and every change is tested within the CI server. Change lists are committed to the CI Server, tests are correlated to the changes, and then tests validate the changes are functioning as designed. The change could be related to new functionality or to an update to existing functionality. The commitment of changes in this manner makes complete sense to developers who are used to working with tooling that is structured around versioning and merging changes. Since CI is used primarily in development and developers mostly write unit tests, unit tests are therefore the most common type of tests run as part of CI cycles. Each unit of code is tested with a corresponding versioned test. Tests are versioned and changed as the code is changed. The application is not deployed into production until each unit of code passes the associated test. https://goo.gl/wTJv22 #DataIntegration #ML
