Skip to main content


Centralized Monitoring System for Automated Tests with Elasticsearch and Kibana

In this post, I want to give you some practical information about a monitoring system for automated tests. I will touch the following topics: Why we need a monitoring system for automated tests What are the potential benefits of the monitoring system A simple approach using the following technologies: Elasticsearch Kibana Firebase test lab, gcloud and gsutil XCTest and Espresso What is the Centralization of Log Systems In a development pipeline, we have a variety of tools and technologies with different languages and scripts. CI/CD pipeline is a good place the see the process of the development, but to get the detail of an item in the pipeline, we need to get into that item and tackle with logs and data. Some times this investigation requires some capabilities to understand it. One of the easiest ways to get a common understanding from the logs in the pipeline is using one easy tool for the whole process. When we collect all the
Recent posts

Benefits of Using Native Mobile Automation Tooling: Espresso and XCUITest

Testing will be more efficient when testers and developers work in collaboration. Especially when it comes to automated testing, we have many challenging points that should be solved with the help of the other team members. This is a basic explanation of the cross-functional team. For mobile application automated end-to-end testing, this cross-functional team approach can be easily applied by contributing the same code base so native toolings give us this. This can increase the quality of the tests code and the framework by the feedback from the developers, and increase the quality of the tests by the feedbacks from the testers. In this post, I want to give some idea about the benefits of using native mobile automation toolings such as Espresso and XCUITest. What is Native Tooling Native mobile automation toolings are integrated libraries to the mobile application development framework so that developers can write UI tests for the products under development. Native toolings are part

(Framework) API Test automation with Ruby Rspec and Airborne

Automated tests for API and services are very important so there are lots of solutions for API test automation in the market. These solutions can be commercial-off-the-shelf (COT) or opensource libraries also, there are many frameworks created around these opensource libraries. Testing APIs with tools that have IDE can be easy to start and learn but it can be challenging to customize for your unique problems or integration to CI/CD tools can be hard. Therefore I can suggest you use one of the opensource libraries by implementing it with your favorite language. In this way, it can run faster,  easily extendable, and configurable.  I have created a framework with Airborne and Rspec for automating API tests, you can  check it from Github .  In this post, I want to explain what is Airborne and how I implemented a framework around it. You can simply update the environment variables and write your specs file in the ` specs ` folder.  What is API Testing API stan

TestOps: What is it and Why we need it

Years of experiences in the software industry shows that there are many more thing that has not been discovered yet. Every approach found in the software industry aims to accelerate the development speed with more customer satisfaction.  Hence the new term "TestOps" is also creating different perspectives on the relationship between test activities to the operational activities within the DevOps culture. In the post, I want to explain my experience with the TestOps.  What is TestOps It shortly stands for tests and operations. Within the DevOps culture, it is a sub-discipline DevOps. There are two approaches to TestOps, these are related to the test approach that you are applying the overall test approach. Mainly if you are applying ` shift-left testing ` then the TestOps should be adopted to have more collaboration with the development team, ` TestOps shift-right `. On the other hand, if you are applying ` shift-right testing ` then the TestOps should be adopted to have more

GitHub Actions: CI / CD Tools - Applying for Ruby / Rspec Project

Github released the beta version of " actions " last year for creating a CI/CD pipeline for the projects. This feature enables us to create a pipeline easily with the web interface of Github.  I want to run the tests for one of my public project in the Github before merging branches to the master. For testsozluk aka " test dictionary ", which contains terms frequently used in the software industry with the meaning and usage of them in Turkish. For the project, tests are critical because JSON files in the Github project are the data source of the application so if any corruption in the data may break the android and the ios application. The tests in the project are written in Ruby by using Rspec to assert them so I used the Github actions to verify before merging code. In this post, I want to explain how this can be done. Github's actions are very easy to apply. You can add it just go to the Actions tab in your project and then select one of the predefined opt

capycon - New Ruby GEM for Running Capybara on Console

Testing is enjoyable if you are using the right tools and technologies, of-course you also need to understand the philosophy behind the testing. I generally use testing tools interactively to try different options that the tool you are using gives as alternatives. For Selenium and Capybara, I have scripts to run get to get them ready on my console, you can read more this post for Windows and this for Unix-like . Under the quarantine days, I wanted to create a Ruby GEM for any want to get Capybara experience on the console for their project.  Capycon is simple, the short version of Capybara-Console, a GEM file so you can install it by: gem install capycon To use it, open your terminal and switch irb or pry  and then require the capycon , then you use all the functionality of the Capybara on the console. See the following steps; ~ /P/ p / c / capy_con (master ⚡→☡ ) pry [ 1 ] pry(main) > [ 2 ] pry(main) > require "capycon" * * * * * * *