A QA-guy blog

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!

Arguably, the biggest damage made by the pandemic is the decline in people's trust and morale. That is the common plot for a horror movie - a group of people get locked in one place. Then something goes wrong, people get suspicious towards each other, then kill each other one by one, only to learn that it was someone's else evil game. Congrats folks - now we can find ourselves living in such movie. Today in one of the social networks somebody has complained that the cashier at the local shop, who was appearing in his 70s was coughing for 15 seconds. The person complaining was scared that cashier might be spreading COVID-19. The comments were divided. The minority has, rightfully, mentioned that coughing may be as well a symptom of quite common long-term conditions, which pose no threat to the public - like Asthma or Lung Cancer. The majority though were getting quite critical or even aggressive. People would suggest that those exposing any COVID-like symptoms should be

First of all, I have to admit, I am not a professional economist, tax-expert or politician. Even though I do have basic economic education, I might miss some obvious things. Nonetheless, I think that the idea of additional tax based on where people decide to work from (which is a `telecommuting` in this case) is not a very sound suggestion Like many other people, I am working from home now. The biggest difference in my case is that I was working from home before and I intend to work from home in the future. I don't mind (in fact, I strongly support) seeing my colleagues once a week or several times a month, but I don't think it always makes sense to be collocated to work effectively. This morning I saw the story posted by the BBC:  Deutsche Bank: Tax working from home 'to support vulnerable jobs' , which suggests introducing a new 5% tax for those, who choose to work from home. I am not going to copy the story here, please feel free to check it yourselves, but I

While there're lots of information published on the internet about how one should develop/buy a Test Automation solution, there's an elephant in the room - which is the fundamental question "Do I need to do it at all?". That is a good question. While I think that there’re some legitimate contexts where product/project/team can benefit from having a sophisticated test automation solution/framework, my general rule of thumb is “If you need a framework - you do it wrong” . There’re at least several decent papers showing the benefit of unit-testing ([1],[2], [3]), while I could not find any research proving that system level tests could bring better results. Please let me know if you can prove me wrong. There’s at least one half-scientific paper showing the benefits of unit tests in comparison to integration/system level tests [4] There’s a good paper bringing a notion of running/writing and maintaining test vs. the benefit of having/running it at

Let's assume a hypothetical situation - you were assigned to a project to help with the "test automation" initiative. You have a huge "test plan" as an input, containing hundreds (if not thousands) of "test cases" and you need to do something about it, quick. Problem statement Your first urge (if it is a Web application) may be to write some UI-level automated checks using tools like, you know, Selenium. In fact, there's a huge demand for such "Selenium test automators" in the industry these days. But please, please, don't do this. There're lots of things which make UI-level automated checking the least desirable approach: UI-level automated checks will be slow. There's just no way to avoid it. You can parallel them or do some other tweaks to speed them up somehow, but they still will be slow. UI-level automated checks will be flaky. Partly - because they're slow. Partly because Web browser and UI interface w

I don't usually write replies to someone else's articles or blog posts. But recently I stumbled upon an article, which I would like to reply to. The article named "10 Best Practices and Strategies for Test Automation" (original can be found here:  https://www.softwaretestinghelp.com/automation-testing-tutorial-7/ ) states: These strategies are taken from my own experience plus from the literature of testing gurus like Michael Bolton, James Bach and Cem Kaner. These practices should be followed in every automation project. Ironically, James Bach has a great post named "No Best Practice" ( http://www.satisfice.com/blog/archives/27 ), in which James puts his view related to "Best Practice" idea, which can be briefly summarized - There's no such thing as "Best Practice" . I wholeheartedly support this viewpoint. A similar idea is stated clearly on the very home page of Michael Bolton website ( https://www.developsense.com/ ). Simp