ExecuteAutomation

Automated Integration Testing and Why?

Karthik kk
In this post we are going to discuss about automated integration testing. So far in ExecuteAutomation.com we have been talking about automated functional testing using testing tools like These functional testing tools addresses the UI (User Interface) testing of applications. There are many sites which exclusively discuss about these above mentioned tools and we have covered almost all these tools as much as possible in many videos (140+) and articles (200+) As the name of the post is, we are going to discuss on Integration testing of application, and the reason behind the sudden paradigm shift on my post is THAT’S WHERE THE INDUSTRIES ARE HEADING TOWARDS !!!

QTP Era

Gone are those days where automation engineers where writing code (to be precise “scripts”) using QTP (Quick Test Professional) tool, where they just record and playback their test by adding some (or more depends) logic for descriptive programming and test their applications. After the dotcom boom, many companies started their focus on web applications and web based services rather just a standalone applications, hence Seleniumgained great popularity while it came to market, since its Free, Open Source and best tool for web application than its peer QTP (as it supports multiple browsers and so many other reasons).

Rapid Release

As that said, now most companies like Microsoft, Google, Facebook, Mozilla and many more are migrating their products towards rapid releases, While this allows faster time-to-market and user feedback, it also implies less time for testing and bug fixing. Since initial research results indeed show that rapid releases fix proportionally less reported bugs than traditional releases. As Rapid releases are adopted by many companies not just the above said, the fragile UI testing is not going to work out for long run.

Problem with UI automation

I am in automation testing field for more than 9+ years now and most of the time we see people complaining each other’s (QA and Dev), I see my managers or my peers complaining about the automation that we do, since it works well on Monday and bursts on Wednesday where we in turn complain developers that they changed something which broke our automation. That happens mostly if the application is not built by keeping automation testing in mind, but some project I worked are very automation friendly and they report us if there happens any change in UI and we take care of beforehand (but its rare case).

Will Integration testing address the problem?

Well, of course not the UI issue, but, the trend in today market seems to be shifting their focus from UI to components level which are deep into the program they are building, by doing this they find themselves following advantages
  1. No separate tool for testing the components (at least proprietary)
  2. Much robust testing compared to UI (since we test the components)
  3. Less overhead with maintaining the code (at least not as fragile as UI)

    Automation testing pyramid

    The automation testing pyramid of current trend (Agile methodologies) looks something like this, you can find from here as well As you can see above, the level of automation testing done for UI is far less than the Unit and Integration testing.

    How to do Automated Integration testing ?

    There are many open source tools available for doing automated integration testing and they can be used for unit testing as well, I have listed some which are very interesting to me
Thanks, Karthik KK