Bloggo back to the blog
Continuous Integration Best Practise: Effective QA practices for CI Development Projects-->
Faster, better and cheaper is the expected result of any given hour in any given business case. Now that many organizations have adopted continuous integration in practice, it is for testers to get aligned to continuous integration development practices.
In this blog let us have a quick look at Continuous integration practice & its benefits and why the combination of behaviour driven testing and exploratory testing has to be the best fit for continuous integration quality control.
Continuous Integration practice and its benefits
Continuous Integration (CI) is a practice in agile methodologies where all developer workspaces are merged with a shared mainline several times a day.
In Continuous integration practice, software development is achieved by adding new code several times a day, but also by refactoring existing codes written during previous iterations. This refactoring can be safely achieved only with a strong test system so that the whole software doesn’t break when new code is added or when existing ones are modified.
Continuous integration benefits:
• Developers detect and fix integration problems continuously by avoiding last-minute chaos at release dates
• Early warning of broken/incompatible code
• Early warning of conflicting changes
• Perform immediate unit testing for all changes
• Immediate feedback to developers on the quality, functionality and system-wide impact of code
• Metrics generated from automated testing and CI (such as metrics for code coverage, code complexity, and features complete) focus developers on developing functional, quality code, and help develop momentum in a team
Continuous Integration quality control
From the above mentioned points, you can clearly see the need of an efficient quality control system that replaces the regular practice of following quality control processes with different phases and cycles for testing systems after completing all development. Also, continuous integration quality control has to be different from the traditional quality control processes of phased unit, system and system integration testing.
I can only see Behaviour driven testing which is based on the principle of unit testing focuses on behavioral specification of software units as a best fix to continuous integration quality control
• Develop test scenarios that cover software behaviour as in Behaviour Driven Development feature pattern. Note: BDT test scenarios can be created even when development team follow methodology other than Behaviour Driven Development
• Execute test scenarios with manual/automated scripts. Tools like Cucumber, JBehave and Selenium support BDT test automation with can be integrated with continuous integration servers
Only possible cons which I encountered while practicing BDT is the possibility of missing system integration scenarios between the codes written in previous iteration with the current iteration.
Exploratory testing helps me in addressing the missing system integration scenarios within the iterations with minimum effort.
Cem Kaner, who coined the term in 1983, now defines exploratory testing as “a style of software testing that emphasizes the personal freedom and responsibility of the individual tester to continually optimize the quality of his/her work by treating test-related learning, test design, test execution, and test result interpretation as mutually supportive activities that run in parallel throughout the project
The balancing act: BDT and Exploratory Testing
I strongly recommend that balancing Exploratory Testing with manual and automated Behaviour Driven Testing is the way to go for continuous integration quality control.
Though BDT helps in testing the business outcomes and unit conditions as early as possible in development life cycle, exploratory testing will help in going out of box and catching the interface related testing gaps which we would have missed in BDT test script.
Now that you are at the end of this blog, my question to you is whether you agree with the mentioned balancing act as the best bet for continuous integration quality control? If not, feel free to comment with your point of view.
Author: Muthiah Palani
Handling various Testing projects at Aspire (www.aspiresys.com), Muthiah brings years of experience in Migration testing, System Integration testing, Acceptance testing and Program Management. As a senior QA consultant he has worked with global clients, assisting them with implementing an effective testing strategy. A dynamic professional with extensive knowledge of almost every domain, predominantly in Finance and Retail, he has led Aspire to develop matchless Testing services. You can follow Muthiah’s posts here.