A QA-guy blog

Some time ago I had an argument with another team member - he was claiming that Test-driven development (TDD) was not applicable to our application. He thought it would be more efficient to rely on manual or E2E testing instead. I disagreed. Without going too much into the details, the core of the application we were working on was a graph-traversing algorithm with some amount of mathematical calculations. It was painful to test on a system level as the number of possibilities was huge and it was not easy to put the system into a particular state to check specific conditions. I thought that thorough unit-test coverage, and, ideally, TDD would be more efficient, but was not able to persuade my colleague. At the end of the day, I started to doubt if I was right. Challenge was accepted, so I tried to do something more or less similar (though simplified) - implementing a Tic Tac Toe computer player logic via as pure TDD as possible. Long story short, after some time I managed to g...

Yet another time I think I see people using word Agile wrong. Yet another guy claimed "we need to have more predictability and stability so I think we would go for Agile methodologies, Scrum in particular". Nonsense. I don't think that "predictability, stability, whatevershitability" has anything to do with Agile. If you start Agile transformation with such a goal you've already failed. Agile is about maximizing value delivery rate in a state of uncertainty, that's pretty much what it is. If your business is uncertain as hell why do you think that "predictability" with engineering teams is going to fix things? It is not. Worse, if you make engineering teams predictable while having unpredictable environment, you will miss the whole point and make things worse while still thinking you're doing fine. Nonsense. An agile team is about removing management layers between engineering and customer, not making management happier. ...

I am getting tired of posts about how "automated testing" going to replace "manual testing". Let me offer you a simple analogy. I have a car that has lots of useful self-check lights, like "check engine", "low gas", "low battery", etc. Automated tests are similar to those lights - if a light is on, most likely something is wrong and I need a mechanic to look at my car. Does having those self-check lights let me not to visit a mechanic for human-driven check yearly? They don't. Fact that self-check light is not on does not mean my car is OK, does it? Areas covered lots with self-check may require less time to check (as risk they would be broken is lower). However, there are lots of areas that is not feasible to cover with self-checks. There're some car parts I am not even aware of, while mechanic knows they weak points and can find an issue in a couple of minutes. It is possible to have only automated checks and not have ...

"Modern software is of a lower quality that it was in a past". Maybe. Perceived quality of software may have decreased, but I don't think that "more testing" is a proper solution. More testing does not mean more quality More testing may find more issues, but not necessarily. Simply spending more time on the activity does not mean results would be better. And somebody needs to fix bugs, test bug fixes. So we can't tell that more testing means more quality but certainly means bigger costs. Software quality != No bugs Bugs matter, but that's hardly the only factor to measure quality level. There are a whole bunch of other things that matter: UX, number of features, documentation, price, delivery model, cute logos... Spending more time on testing may mean spending less time on these things. Adequate quality level So it is obvious that one can't spend 100 years testing every possible case. I think that each product has some Adequate le...

I have published several posts with the aim to deliver one message - sometimes it is more efficient (fast and convenient) to change the application under test (make it more testable or eliminate the need for testing at all) then invent or employ complicated test automation techniques to check the same functionality. Even though there was a lot of misunderstanding caused by badly forming those posts, I still think I stroke something deeper. For instance, this twitter post made me think that we speak two different languages: That's like asking a pharma company to self-certify that their drugs are safe without any independent approval! #softwaretesting #CIO — Ayush Trivedi (@ayushtrivedi) 4 September 2017 Now it started to seem to me that there're two different views on what test automation is. First, probably prevailing point of view is that test automation is a part of ages-old traditional QA process, where test automation specialist is just a test specialist usin...

Preface: I am in the middle of writing a series of posts about test automation frameworks architecture. I am still going to continue that series, even though this posts kind of devaluate the whole test automation framework concept a bit. Sorry for that, just can't stop ranting. Looking through the internet I spotted a couple of posts where some test automation specialists were talking about "page object" "pattern"/"model", as it was something special they had invented. Well, I also have something to say about "page object". “Java test automation engineers were told that there are different patterns than a PageObject” ( http://classicprogrammerpaintings.com/post/153817288474/java-test-automation-engineers-were-told-that ) "Page object" may be described as a pattern that allows us to decouple things you can do with the web page (external interface describing test/business logic) from the real implementation code you will h...

There's something that I haven't seen in the education plan of IT degrees ever - professional ethics, and I think it is a huge miss. Ethics is being taught for lawyers, MD, teachers and lots of other degrees. Ethics tells us that there's something beyond our job responsibilities. Ethics reminds us that the one who is footing the bill may not be the final decision maker of everything. That if something is legal, it yet does not mean it is a right thing to do. Let me share a story about one of my previous project. I was working for an IT services company and we were helping our client to deliver a new version of the software. A peculiar thing was that if there were a bug in the Product, then something horrible could happen (in the worst case - somebody could die). And I was the quality guy on a project. Our sponsor (the one, who was footing the bill, and ultimate decision maker) had his deadlines. He already made a demo for marketing people and wanted to ship the softwar...