Industry Carelessness

-
Looking through the LinkedIn feed I see a horrible thing. I think we can call it "Industry Carelessness". I see lots of posts of the kind:
  • Automating testing using XXXXium
  • Digital transformation using microservices architecture (please download our brochure)
  • We will transform your business, here's how
And so on. This is very disturbing. It is like "we don't know what the problem you have (if any) but we have a solution already!" Moreover, I worked for a company whose whole business model was like that, which was delivering what it had in place instead of what was necessary.

I interviewed employees who did not know where we were but already knew where we should go and how do we go there.

"Ok, we shall do this and that".
"Hold on a second, don't you want to know what we already do and what results we get?
"Not necessary, the industry goes into that direction so let's do thing 'right'"

And even worse, I was once the one who did not understand what was really happening but was eager to suggest disruptive measures to "fix things". It was a great experience - on the job interview where I was asked about the "ideal test automation process" and I described Pretotyping, BDD, TDD, and testing in production.

"We will get awesome time to market" - I bragged happily
"Yes. You are right. The thing is that time to market is not actually our concern... Our concern is that we have lots of issues in production and that badly affects our business" - calmly said the guy who was interviewing me
"Oh, shi~"

So chances are that my treatment would be worse than the disease. Or, more accurate, they were for the wrong disease.

So hereby I want to share a dream with you.
I have a dream where companies care about their customers, who tell "We don't know the solution yet, but promise to understand your problem and do our best to solve it. If we fail we will suggest another company who could do this better".
I have a dream where employees first understand what is wrong before "fixing" it, and me being among them (so I hope not to repeat this mistake again).
I have a dream where my feed full of thought-provoking posts, for instance, "Ok, that was the problem, we tried this and here how it is worked - let's discuss".
I have a dream where we and companies care.

Say no to Industry Carelessness.

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