About this blog

Hey everybody. My name is Alexander Pushkarev (feel free to call me Alex). I've been working in IT roughly since 2006, and most of my work experience is about testing, automated testing, and test automation.

Even though I do enjoy programming, I find the task of testing that thing was programmed well more challenging and exciting. Besides, I would rather do little thing well, that big thing bad, if you know what I mean.

Currently, I mostly using Java for my work, but I also worked with .Net framework (and have warm feelings about it) and also I adore languages like Python or Kotlin, so chances are I will post most examples in any of these languages or platforms.

My ultimate goal is to achieve an effective and feasible quality control approach for projects, and I am going to share my ideas with a wide audience. I do this both to be heard and to be criticized, so I could see and learn from my mistakes. That being said, I enjoy constructive conflicts, and if you see I am writing bullshit, please don't hesitate to tell me so. This also means I am going to share only my personal views, and ask you to treat them so - please don't assume that I am representing any company or community views in this blog.

I will try to do this blog as interesting, challenging and enjoyable for you, as I can. By target audience, I see a test and test automation specialists, and developers and project management people who are interested in software quality and want to know more about it.

I authored a couple of blog posts in other places already, I hope you may find them enjoyable:
Test automation framework types overview
Fair IT-services for IT-services company, employee and a customer

If you happen to speak Russian, you may also enjoy these posts:
Kanban
Scrum

From time to time I present talks at the various conferences. Below is the list of conferences I have participated in or am planning to participate:



Feel free to follow me on Twitter:


Comments

Post a Comment

Popular posts from this blog

Test automation framework architecture. Part 2.1 - Layered architecture example

Image
Let's consider an example of what Layered (Tiered) architecture may look like for a test automation framework. As a system under test, we're going to use this simple and neat "Todo list" application. First, let's do a brief analysis of the application. From my brief exploration I came up with the following checklist: Area/Group Things to check Comments Todos CRUD 1 Create item Basic scenario, UI-level case 1.1 Create an item with the same name The case is not valid. There's no validation for that - nothing to check really. 1.2 Create an item with an empty/not valid/malicious name While it would be a nice thing to test manually, from test automation standpoint I would expect this to be filtered on service or repository level, so either integration or unit test . 2 Mark item complete Basic scenario, UI-level case 2.1 Un-mark item complete Basic scenario, UI-level case 3 Delete item Basic scenario, UI-level case 3.1 Delete item
Read more

Test automation framework architecture. Part 2 - Layered architecture

Image
Probably the most popular architecture pattern used for test automation frameworks (TAF) is layered architecture. This pattern is so well known that on job interviews for some companies when they ask you about TAF architecture you are supposed to describe this one. If you don't - they think you know nothing about the architecture altogether. I suggest you first read a brilliant description of the pattern at the O'Reilly web page , cause in this post I am going to describe the pattern in a way it is usually applied to build test automation solution. Usually, there're three distinct layers, which may have different names, but follow the same logic mostly. Sometimes those layers called test layer , business-layer and core layer , but there're no standard names really. Key rules for layered architecture are the dependency direction (each level depending on the level below) and call direction (no level can call/reference code described in the level above). The rough
Read more

Efficient test automation - Secret #1 | Test Club

Image
It seems everyone talks about efficient test automation, but not so many people have actually seen it! To cover this I decided to make several videos regarding the secrets of efficient test automation. Today we will talk about the first (and, arguably, the main) secret - realistic expectations. Very often, test automation projects or initiatives are started with the following unrealistic expectations: "Test automation will replace 'manual' testing" "Test automation will provide fast results and benefits" "Test automation efficiency depends solely on test automation engineers" Unfortunately, all those expectations are not realistic! Watch the video to know more!
Read more