QTP EraGone 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 ReleaseAs 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 automationI 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
- No separate tool for testing the components (at least proprietary)
- Much robust testing compared to UI (since we test the components)
Less overhead with maintaining the code (at least not as fragile as UI)
Automation testing pyramidThe 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
- Fluent Assertion
- Fluent MVC (for Asp.Net MVC applications)
Moq (mocking frameworks)
FinallyI believe the trend of rapid release cycle is nowhere going to stop in near future, may be, it can go a step ahead to very rapid release cycle, but not the other way around, hence its very important for all of us to start focusing more white box testing rather just the black box UI automated testing. Hope you like this post !!! Thanks for reading and post and share your comments if there is anything missing or misleading