A QA-guy blog

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 ...

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...

Being Developer In Test specialist, I do lots of coding, automating, meeting, refactoring, code reviewing and other related things these days. I do enjoy most of my daily activities, and I didn't think that being forced to do some manual testing stuff can be anything interesting to me. Chances turned, though, that I was the only QA-focused specialist in a team and we had to provide quality feedback on a product that had had little (close to not at all) unit test coverage. Being inspired by James Bach's and Michael Bolton's Rapid Software Testing methodology , I devised exploratory test session plan for the application, distributed activities between team members and did my best to find any possible issues in the application we worked on. Being overwhelmed by regular work activities, I couldn't even imagine how fun this bug hunt could be! I found quite a few issues, and I felt being House, M.D., detective Columbo, or somebody of a similar fashion. I was chasing a...

With "Agile methodologies" currently gaining more and more ground, there's a little bit of anxiety, especially among Software Testers, about "Roles merge" idea. Let me comfort you - roles do merge, but they do not disappear. Let's have a look at this in a little bit more details - first, let's discuss why roles do and should merge in Agile projects, then why they will never disappear. Why roles merge An agile team is typically is a cross-functional team having a shared goal (well, at least in theory). For instance, this goal may be to paint a room, prepare a party, write the best ever software or anything else. This means that there will be a situation where one needs to step in and help others do their job.

So, you decide that your project needs test automation because manual testing is too long or too costly to address your needs. How would you approach that? In essence, there’re two opposite approaches to test automation. Let’s call them “test-first” and “automate first” Test-first approach  In this realm, you have the luxury of having somebody actually designing a test case for you so you can automate it. Quite often, this is a place where many “test automation” engineers would like to be. These means they are actually being developers because they have requirements (which is a test case) and a product (which is an automated test case). They also have a clear goal (automate that) and they are not responsible for the quality of the product under test. In contrast, they are responsible only for the quality of their automated tests. All things considered, this approach is actually quite sustainable from a quality control perspective. Provided automated tests ...

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 writin...