Skip to main content


Showing posts from 2016

Adding Slave Jenkins to Master Jenkins

Jenkins is an orchestration tool that you can use it for general automated jobs. Using one Jenkins for every kinds of job create some inefficiencies so the better idea is grouping jobs for their functionalities and having them done with slave Jenkins. Each slaves can be attached to master as a node and waiting for command. With this way you can run Windows related jobs in Windows; unix or mac related jobs by unix system and so on. Moreover you can add multiple and exactly same slaves so that to run the jobs more quickly. In this post I want to share an idea for adding slaves to master Jenkins.  1. Go to master Jenkins > Nodes > New Nodes >    - Enter "Web Automation Slave 1"    - Select "Permanent Agent"    - Click "OK"      - Enter Labels > " regression "      - Click "OK"      - Click "Web Automation Slave 1"      - Copy the URL of this page          2. Go to slave Jenkins Mac

Importance of Testing: Case of Samsung Note 7

Test it or let the customers do it in wild! Testing is not a state it is a process, any failures in the process, make the quality ruined. Moreover, any failures detected in any part of a product make the product fail in terms of customers. Therefore we need to deploy the quality as a process of products and services which are given to customers along the product life cycle. In this post, I want to explain the importance of testing with the case of the successful Korean technology company 'Samsung'. The real problem with the product is that design of the battery has some defective points because they want to push boundaries too much for having more power small battery cell. For more detail, you can this post . Let's look at product life cycle management (PLM) first. It explains a product from an idea to delivering a product and terminating support. It divides the product life cycle management into four main stages as follows: Conceive  : Imagine, specify, plan, innovate Des

Repeatable Test Case Design: Escaping Flaky Behavior

Automation means repeating some steps to have some tasks done with test code. However when it comes to test automation fulfilling this meaning is not that easy because of unpredictable reasons. You may face that a case has run successfully for a period of time but it fails for without an unknown reason. Actually there is always reasons which can make test failure but it may not be possible to handle it when writing the test. This kind of test cases are called as  flaky   test cases by Google . Flaky tests are the last thing you may want in CI environment because test are writing for fast feedback not for checking accidentally failed test cases. In this post I want to explain what I have done to overcome, actually minimise the effect of flakiness. Nature Of Flakiness Most of the time flakiness cause by our own mistakes. This could be not understanding the automation frameworks deeply or could be the result of non-adequate analysing the case. The other reasons like third party t

Using ChromeOptions for Capybara: Disable Images and More

Chromedriver lets us set preferences via capabilities when it is initiated by Webdriver. These preferences can be used for specific purposes for example disabling images can reduce network needs and fasten the test runs; and disabling popups can make your cases more stable by reducing non-deterministic cases. In this post I want to explain how to use these feature of Chromedriver for Capybara with Ruby, you can also apply the same method for other languages with their bindings. Sometimes bandwidth is crucial if you have parallel pipelines for test runs. Think that you have 10 parallel pipes and very pipeline consume bandwidth to complete its tasks, the most heavy part of website generally images. If we disable the images we can fasten the overall test runs. To disable the images you should set the images option to 2 in preferences. For Capybara you can disable the images by following Chrome instance: Sometimes you need to disable popups which intermittently occurs and make

How to Add Screenshot to Jenkins Cucumber Reports for Capybara

If you are using Capybara and Cucumber for test automation and Jenkins for CI/CD process you can run your test over Jenkins and see the result by Cucumber Result Plugin , for more information check the plugin page . By this plugin you can also see the screenshots taken when test cases fail.  To produce the result you need to save the result of the test as .json file, you can use the following command:      cucumber features -f json -o cucumber_result.json To enable to take screenshot if a case fails you need to set the application hook  of after case. The following configuration makes it automatically. See it and change screenshot path with your path. The key point is embedding the image after taking it then reports plugin make it visible on the report. Cucumber Result Plugin Screenshot for the failed test case

Appium vs Calabash

If you want to test your mobile application and looking for an open source testing tools then most probably you will face Calabash and Appium . These are the top two most popular tools for mobile automation. At first glance, they seem to be learnt easily but in detail you would have to deal with many challenges and must spend little bit longer time than you expected. Since these tools are open-sourced and still not mature level of quality there would be some problems when you want to use them for your special needs.  In this post I want to write down my experience about Calabash and Appium. This post may help you to choose which one is suitable for your needs. I used following versions: Calabash-Android: 0.7.3 Calabash-iOS: 0.19.1 Appium: 1.5.2 Appium Support Many Languages But Calabash is RUBY! In the background Appium uses Selenium which was created 14 year ago by Thougthwork, check thoughts about Selenium  for mobile testing by Thougthwork. Since Selenium supports Ja

QA in Production

For a while, I have been thinking about the responsibilities of QA Engineers by broadening them to the production environment. In this post, I want to write the reasoning behind the needs of QA Engineers in production. Integration Testing: Tools and Technology Every day we are facing new integration points with third-party tools or technologies for a win-win strategy. Most of the time these technologies are in the term of the trial period or just a cheap alternative to the present one. These technologies or tools simply don't have adequate documentation so it makes the development and testing of integration riskier. This means that the development, test, uat or preprod test environment is not enough for catching all possible bugs, as a result, the production environment is the final destination for checking logs and monitoring the integration results. Validation of Non-Functional Requirements There are also unclear points behind the non-functional requirements like performance a

Change Default Timeout and Wait Time of Capybara

One of the biggest challenge for automation is handling timeout problem. Most of the time, timeout is 60 seconds but it may sometimes not enough if you have badly designed asynchronous calls or the third party ajax calls. This makes handling timeout more complex. set large enough to tolerate network related problems. For Selenium based automation frameworks, like Capybara, default Webdriver timeout is set to Net::ReadTimeout (Net::ReadTimeout) Changing ReadTimeout If you have timeout problem for Capybara, it gives an error like above. This means that the page is not fully loaded in given timeout period. Even you can see that page is loaded correctly but webdriver wait until the Ajax calls finish. class BufferedIO #:nodoc: internal use only def initialize (io) @io = io @read_timeout = 60 @continue_timeout = nil @debug_output = nil @rbuf = '' end . . . . . def rbuf_fill beg

What Reminds From Testistanbul 2016

First of all, I am appreciated to attend to an international conference on software testing. It is 7th international Testistanbul conference. There was good number of attendants from newly starters to over 30 years of experienced professionals. Most of the attendants were from Turkey thought there were some guys from abroad and some international companies to present their products. Testistanbul conference is important because it is definitely the most valuable conference on software testing in Turkey. It gives us opportunity to meet largest professional group and to share the knowledges in domestic market. The conference topics were as follows:  09:00 - 09:30 OPENING CEREMONY SPEECH: FORMULA 1, CONTINUOUS INTEGRATION, CONTINUOUS DELIVERY AND TEST DATA MANAGEMENT PROCESSES - TURKEY SOFTWARE QUALITY REPORT (TSQR) 2016 / 17 (In Turkish) Koray Yitmen 09:30 - 10:15 IBM SPONSOR SPEECH: SHIFT LEFT FOR HIGHER QUALITY AT GREATER SPEED Mehmet