What exactly is Continuous Integration and Continuous Testing – and why should I bother with either of them?
Here at Galil Software, we’re widely acknowledged in the QA industry for our testing skills. And those skills include, of course, extensive experience in both continuous integration and continuous testing.
But why is there a buzz about continuous integration and testing?
Well, the reason the QA and testing industry is so smitten by continuous integration and testing is that they provide the continuous, non-stop development of code.
Don’t miss our recent CI survey of testing professionals in Israel!
Continuous integration (also known as CI) is the practice of frequently integrating new or modified code with your existing source control repository. “Frequently” typically means several times a day, when all working code is integrated with a shared mainline. Each check-in is verified by an automated build.
The big advantage with this type of integration is that any problems that may arise (and they typically do, often!) can quickly be spotted and handled. Feedback regarding any possible defects is amazingly quick. This is one heck of an advantage that has led to CI taking on a major role in agile development methodologies…
The various CI tools out there, including Jenkins and Bamboo, generally automate the various development steps for you. Hence the ease of implementing integration runs, which can be run, as we mentioned, several times a day. And yes, some companies even schedule an hourly integration run. See how we typically implement continuous integration and testing at Galil Software in the section below.
One last thing: if your automated builds fail or there’s a failed unit test, those CI tools should stop you from continuing. In other words, there’s a HUGE red flag that should help kick your integrations into the premier league of integrations.
Continuous testing is the practice of running overall tests, typically nightly, that validate the health of the product being tested. These nightly tests generate reports which enable testers to understand which parts of the product are stable and which are not. These tests include both sanity tests and specific tests for each unit of the product.
When choosing continuous testing tools, you should make your decision based on the development language and nature of the application. And if you’ve selected the right tool, it should watch the code for changes and automatically run the tests after compilation – and then follow that up with proper reporting.
How we implement continuous integration and testing at Galil Software
As is typical throughout the testing industry, we use a mix of code sync and integration locally on each developer’s computer (usually with an IDE like Eclipse) with code committed (checked-in) to a source control repository, such as Git, SVN, ClearCase, or Perforce, in order to catch any compilation errors, and to ensure the release of stable builds.
Generally, this process is combined with continuous testing, which is done via a daily/hourly scheduler, or automatically triggered by the actual code commit.
Once the code has been successfully committed, a proof build is released and the product successfully deployed on various platforms, complete with a sanity test. The code is then integrated into the main code branch.
We use Continuous Integration frameworks (such as Jenkins, QuickBuild or Build Forge), that continuously build development code, launch the SUT on multiple platforms simultaneously, and then executes sanity or regression tests in Robot Framework, Selenium Grid, TestNG, JUnit, or other testing frameworks.
If you’d like to discuss the finer points of continuous integration and testing and how we at Galil Software can assist you in both, please drop us a line!
