TEST THE RISK!

It is a raising question around performance testing people that how to integrate, super hero tool, Locust to Jenkins as a step to continues integration (CI) pipeline. There have been some solutions for this but they are not simple, plus you need to write own log writer to handle this problem.  Actually there was a commit to save the result of the test but it has not been merged to Locust. With these commit we can integrate Locust to Jenkins. Update Locust This  update  is still open so you can not see it in latest Locust version yet. However you can  use this by updating your local repository, or just change two files  main.py  and  stats.py  with the files in your local. For Window change the files in the following directory:  C:\Python27\Lib\site-packages\locustio-0.7.3-py2.7.egga\locust\stats.py and for Unix-base OS change the files in the following directory:  /Library/Python/2.7/site-packages/locust/stats.py.  Alternatively, you can clone this commit from github and instal

For a successful Continuous Integration pipeline, there should be jobs for testing the performance of the application. It is necessary if the application is still performing well. Generally performance testing is thought as kinds of activities performed one step before going to live. In general approach it is true but don't forget to test your application's performance as soon as there is an testable software, such as an api end point, functions, and etc. For CI it is a good approach to testing performance after functional testing and just before the deployment of next stage. In this post, I want to share some info about Jenkins and Locust. In my previous post you can find some information about Locust and Jenkins. Jenkins operates the CI environment and Locust is a tool for performance testing. To run the Locust on Jenkins you need command line arguments which control the number of clients ,   hatch rate,  running locust without web interface and there should be so

Continuous Integration is easy if you are ready for the definition of DONE (DoD). It is not only accepting a story as successfull after developped by a developer but it also includes a process which ends after deploying to live and ensuring that it works and does not cause a defect in the live system. Handling DONE actually means of CI. With Scrum there is always one shippable product at the end of each sprint. This shippable product has to include some new features. Definition of Done helps to Scrum to clear the definition of every stages of development, such providing checklist for discussion, estimationa and design, so it makes the user stories more understandable and applicable.  What Definition of Done includes: Identifying the list of acceptance criteria Development Unit testing Funtional testing Regression testing Acceptance testing Performance testing Deployment Documentation Tracking  DONE Every stage can also have sub-stages, DoD should be prepea

If you want to update your code in the local repository from git (gitlab, github, gitorious), you need to run git pull  into your repository. If you want to do this by Jenkins, you can create a job that can perform this action. There may be easier way to solve it but you can follow the instruction below: Create a Job to Pull the repo Jenkins > New Item > Freestyle Project > "OK" Build > Build Steps > Execute Windows Batch Command> Enter your command and save it Install GitLab Hook Plugin Jenkins > Manage Jenkins > Manage Plugins > Find Correct Plugin > Install it Create Deploy Keys on GitLab GitLab > Your Project Page > Settings > Deploy Keys > Click 'New Deploy Key' Be sure that you are changing your project settings! Create Deploy Keys and Services on GitLab GitLab > Your Project Page > Settings > Services > Click 'GitLab CI' Enter token, run the fo

I think the most challenging part of test automation is nowadays having Continuous Integration and one step more is having Continuous Deployment. These two terms have been a buzzwords around the software community, and everyone is talking about them but there are very few companies that can apply these. The reasons behind this can be listed as: Mis-understanding of agile and scrum Lack of "real" test engineers and Lack of Dev-ops culture  Lack of stable test environments  Lack of vision in the software industry, which saving the day is more critical than saving the future Out-of-budget, not investing on good people but investing in tools On the other hand, there are lots of open-source tools that you can just build and configure your own CI, and maybe next step goes to continuous deployment. In this post, I want to explain how you can set up CI on a Windows server. I will use the following tools/technology and language: Ruby, Gem (many Gems), Capybara, Cucumbe

Continuos Integration shortly as CI is a development practice which developers push their code frequently to the development environment and then automated build system build the code and then test it and gives feedback about the newly added code. By this way, codes are added to the main repository in a small piece which reduces the complexity and deltas between new code and the code in development environment. Developers also can reach the latest build code easily. Think that every developer pushes one time in a day, the delta is just a day but if they push one time for week then the delta is 5 times bigger, correspondingly complexity is also 5 times bigger. CI Pipeline One of the biggest problem for delivering a feature late is spending longer time for testing product and fixing defects. A classical approach tells us to test at the end of the development but it is usual that planned time is consumed during analysis and development periods. Therefore, after the develo

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

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

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.

Almost every methodological approach in software development aims to reduce development time and produce more qualified products. Continuous Integration (CI) also aims to reduce development time. Basically, CI is software development practice that developers need to check-out their codes in their local development environment and than integrate them to shared repository. According to Martin Fowler who known by his studies about CI, there should be at least one integration to shared repository done everyday, but the frequency of integration is expected to be more than one integration. By this way, test activities are performed during every integration and problems caused by the integration can be minimized. As it is emphasized in this blog , CI says us as "pay me now, or pay me more later" . If we look at the history of CI, it goes back to extreme programming (XP) which advocates that there should be frequently code merged to master to cover unstable requirements of customer