TEST THE RISK!

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.