TEST THE RISK!

I faced an selenium error like " stale element reference " when I changed Capybara's driver to Chrome which was not occurred in webkit and firefox. This error occurs when referencing an element which is not in DOM. Chrome gives this but it doesn't appear when I use Firefox because the dynamic object is appear after the Javascript execution finishes which means that Chrome doesn't wait until javascript execution ends .  You can escape this error by checking your scenario if there is an element requiring in the DOM which is destructed by an action in the scenario or if you have loop and the DOM is updating for each iteration the object you look for changes. However in  my case, scenario is passing with FF but not Chrome which because the Chrome is passing the next step as soon as Javascript execution starts.  I just call waiting function and then assign the variable. Finally scenario is passing for both browsers.        stale element reference: element is

One of the biggest challenge in test automation is updating existing codes. Because of the update in the development, it is very prone to have some changes for the attributes of ui elements and less likely to have some change in behaviour in actions. The second option is most of the time called as bug, otherwise if the business is changed, it could be called as a new feature. For any reasons that cause the automation code gives failures you need to update something. Sometimes I need to refresh my mind :) For easy maintenance, one of the good approach keep your codes modular. It means that each module should responsible for one job and a update problem should be solved by applying just one change in your system. Using Capybara plus Cucumber gives you this features but if you are using them professionally. For this framework, business rules are kept on Cucumber so you can update business rules from your .feature files but related update should reflect to the code. In thi

Web Services are server and client applications to interact with rest of the world over HTTP, or sometimes over SMTP. It is written for accepting requests and giving appropriate answers for each requests. It is assumed that it returns the same response if there is no changing in the request and the condition. Therefore testing and automating Web Services are very easy. You just need to know sending and receiving data and condition, then the rest of the jobs is playing with data and assertions. Information about the  Web Services  should be present in  Web Services  documentations and it should be understandable to the people from third party system.  Web applications take to the next step with the  Web Services  because you can open your system to rest of world without requiring language specific restrictions. This makes integrity of applications very easy. To be able to integrate two or more system, you just know that you are sending some data and receiving data.  I had a t

Page-object model is a pattern that you can apply it to develop efficient automation framework. With the page-model, it is possible to minimize maintenance cost. Basically page-object means that your every page is inherited from a base class which includes basic functionalities for every page. If you have some new functionalities that every page should have, you can simple add it to the base class. Base class is like the following: In this part we are creating pages which are inherited from base page. Every page has its own functionalities written as python functions. Some functions return to a new page, it means that these functions leave the current page and produce a new page. You should write as much as functions you need in the assertion part because this is the only part you can use the webdriver functions to interact with web pages . This part can be evaluate as providing data to assertion part.   The last part is related to asserting your test cases against to the

Appium is an open source tool for mobile test automation, you can automate functional test cases for Android and iOS application. As in my some previous posts, I explained Calabash and I just used Ruby for writing test cases because Calabash only supports Ruby and as I know they have plan to support Java. However Appium doesn't have this language constriction. Since it uses Webdriver, it supports the languages which are supported by Webdriver. It means that Java, Objective-C, PHP, Python, C#, Clojure, Perl, JavaScript with Node.js and plus Ruby are supported. You just install the language client you want to test and then write your test cases. Check for the client for your favourite languages from Appium page . Install Appium: npm install -g appium Install Appium Client: npm install wd Install Python Appium Client: pip install Appium-Python-Client Ensure that you have Python installed, recommend to have 2.7 or above: python --version Ensure that you have

If you tend to use tools effectively, testing is easy and enjoyable. For mobile testing there are lots of challenges and to be honest if you don't push yourself to improve your ability as every developer does you can not test the mobile application good enough. Instead of testing mobile application manually, we can automate the stories whenever the stories are prepared by business analyst with writing cucumber files and then we can start writing the code of automation and finally we can run it when the stories are developed by developer for agile development environment. This is iteration based approach, means you can repeat this steps for each iteration. At the end of the milestone you can run your whole automation code and see the result. For the remaining time you can still test application by using Exploratory Testing techniques to find-out any bugs.  The important point is to make your job effective and efficient. For this you should automate or scripted some repetiti

When you set-up a new android devices or update your .apk file, you may possible get INSTRUMENTATION_FAILED exception: android.util.AndroidException: INSTRUMENTATION_FAILED: com.package.name/sh.calaba.instrumentationbackend.CalabashInstrumentationTestRunner at com.android.commands.am.Am.runInstrument(Am.java:1093) at com.android.commands.am.Am.onRun(Am.java:371) at com.android.internal.os.BaseCommand.run(BaseCommand.java:47) at com.android.commands.am.Am.main(Am.java:100) at com.android.internal.os.RuntimeInit.nativeFinishInit(Native Method) at com.android.internal.os.RuntimeInit.main(RuntimeInit.java:251) To fix this issue you can follow the instruction below: Create new folder Copy your .apk file into the newly created folder go to your newly created folder and run this command to create calabash-android project calabash-android gen run calabash-android via your new devices calabash-android run latest.apk features ADB_DEVICE_ARG=192.168.56.101:5555 resign .apk

Testing the user interface (UI) testing may be the most difficult part of test automation. When we think from the perspective of users there are not hundreds but there may be thousands of different users' environment but it is clear that simulating and testing UI related cases for all possible users' environment is impossible! However we can cover easily the %80 of them by using statistical data taken from analytics tools as Pareto Analysis says 20% of reasons cause the %80 of all problem. If you are doing some kind of internet business, there are two important factors for user environments which are operating system and browsers for normal internet users.  Therefore analytic tools should give us feedback about operating system and versions of operating system; browsers and versions of browsers. To get a general trend we can look at the w3shcool.com statistic but sure it is more convenient to take your own statistic depends on your user profile. In general approach

As a default Capybara runs under Firefox but if you want to change your driver you have to change your javascript driver to your new driver. But you also must define your driver as registered Capybara driver. For example if you want to run with Chrome and change your driver to chrome but not define it, it gives some errors like following irb(main):007:0> visit "http://www.amazon.com" Capybara::DriverNotFoundError: no driver called :chrome was found, available drivers: :rack_test, :selenium, :poltergeist from /Library/Ruby/Gems/2.0.0/gems/capybara-2.4.1/lib/capybara/session.rb:77:in `driver' from /Library/Ruby/Gems/2.0.0/gems/capybara-2.4.1/lib/capybara/session.rb:226:in `visit' from /Library/Ruby/Gems/2.0.0/gems/capybara-2.4.1/lib/capybara/dsl.rb:51:in `block (2 levels) in ' if you add the following line into your env.rb module, you will successfully run under Chrome driver. Capybara.register_driver :chrome do |app| Capybara::Selenium::Driver

BDD, which is stand for behaviour driven development, is created by Dan North . BDD is developed on the top of TDD, which is stand for test driven development to remove the gap of unit testing and acceptance testing. In TDD, every unit is started to be written right after defining the expectations from the units, by the unit testing. However by BDD, regarding the agile story, every unit is specified and tested in terms of desired behaviour. This 'desired behaviour' is what exactly business requires in agile stories.  BDD can be applied by the help of some tools to interpret the business 'desired behaviour' to test code. There are some tools that help this aim such as Behat  for PHP, JBhave  for Java world, and the most famous one Cucumber  for the Ruby world. In this post I want to give some points on how to effectively we can use Cucumber for a Calabash project to automate some agile stories for sample android application. Cucumber takes some keywords lik

In my previous post I explained the Cucumber Capybara and Calabash and behaviour driven development. In this post I want to explain how we can implement and run cucumber and calabash for automating test cases for android applications. If you have not set-up your environment yet, you can read this post . You should also have an android virtual devices or a real devices that is connected to your computer in debugging mode. Your android version should be higher than 2.2.  If your system is ready for testing, you can clone the repository that I created for mobile test automation purposes. Sure, it may be more sophisticated if a real android developer develop something but from this application you can have a fresh starting. git clone https://github.com/gunesmes/calabash_android_automation.git You can check the images on the github so that get information what the application is looking like. Just open the project file and  look at the two important files in feature directory: cala

The conference was hold on September 11, 2014 in İstanbul, Turkey. I want to briefly explain the importance of the conference and what was learnt from it. Thoughtworks, as a well-known consultancy firm in the world, has entered the Turkey's software market. This means that there will be something changes in software industry since there are lots of consultancy firm in Turkey and they have got one more competitor. However this is not an ordinary competitor, they may possibly bring lots of experiences and different kind of consulting culture from the other consultancy firms.  What is the situation in Turkey? As I mention, there are lots of software / test consultancy firm but majority of them work as providing developers / tester to companies to work as outsourced . Therefore the guys generally fell alone when doing their jobs because there is generally no technical supports for them to improve their abilities. Also the major problem in Turkey is software development process.

Be happy guys! We have a day for celebration. Yes, it is today as September 9 which is celebrating as tester's day . The origin of the story goes to the finding first bug in the system. Actually this bug is not a bug we find in the software, it was a real bug which was stuck and dead in the cables. And then it led some flaws on the computer Mark II Aiken Relay Calculator at Harvard University on September 9, 1945.  You can see very famous and first bug report in the picture below.    However, the first time the term "bug" was used Thomas Alva Edison for describing a trouble in a system in the letter written to Theodora Puskas  in 1878. And later on, he used the term "bug" for explanation about a problem in his  phonograph when he gave an interview for the Pall Mall Gazette in 1889 according to the the Yale Book of Quotations .

Mobile test automation is just another era for test automation since the trends for mobile devices are increasing. For more sophisticated testing approach, we should apply the technics what we have learnt from the test automation for desktop/web applications. As test automation is a part of continuos development, it should be run after each commit to test environment. For mobile application we can use the same method to be more responsible.  Cucumber is used describe the test cases and it very easy to understand for anyone so we can use it for user behaviour as behaviour driven development, BDD . Capybara is a library to simulate user behaviour for just web application. However we can use Calabash for mobile test automation.  It means that we can use Calabash and Cucumber together for mobile test automations. As in Capybara, in Calabash there are not much functions to learn. It has basically, finding element, inserting text into textEdit fields, clicking and assertion function

In Poltergeist mode or headless mode, it is different from Selenium since there is no browsers which you can track failure visually. The advantages of Poltergeist are: it is faster, it demands less source when we compare to Selenium, and eventually it is more suitable for Continues Integration (CI). Installation and further information about Poltergeist you can visit git page . Running Capybara with terminal may help you to get quick result. By this way you can check if button, field, or any object can be reachable easily and this method may help you to reduce failure issue on your CI and get you more realistic results. You can just paste the following commands into your terminal, it will go to home page of Amazon.

If you are bored with using old fashioned Java GUI to test the performance of your applications, then you should try Locust. Jmeter , which is old fashioned as I mentioned, is very  mature and used by a big community but you have create your test case with an ugly GUI as much features as allows you. For me the best part of Locust is that you can write your test case with Python which is my favourite language and it is very simple to learn. The installation is very simple, you just need to type: > pip install locustio Some feature / deficiency  of Locust:  You can write your test case in Python You can define the user time consumption on a page with min_wait and max_wait  as milliseconds in locust class so that get a real user simulation.  You can give weight for each test cases so you can simulate real user behaviours like during a specific period of time: 1 person signs up, 10 persons login, 60 persons visit pages, ...  You can make http request as you

For any automation frameworks, handling pop-ups is somehow difficult. By opening a pop-up window, the window changes so you can not control the new window with existing webdriver since it is already assigned to main windows when it was initiated.  Normally automation framework can not work if you don't switch to pop-up windows. For Capybara you can easily handle it by assigning the webdriver to new pop-up window. Then you can perform your test case as same way what you have done and when you are done with the pop-up, close the pop-up and then switch back the webdriver to the main window.      main = page.driver.browser.window_handles.first     popup = page.driver.browser.window_handles.last     page.driver.browser.switch_to.window(popup) Since iframe is a part of another source which is used to display another webpage in a webpage, you must handle it exactly same  as pop-up windows.       page.driver. browser.switch_to.frame(iframe_name) However, for iframe you must