A QA-guy blog

I've been thinking about a proper metaphor about traditional (aka waterfall) and adaptive (aka agile) process and came to this - let's think about a rock band. Waterfall You can create a neat studio album using random people. First, you will record drums, then bass. After that, you can try different guitars... If the guitar sounds badly you will try to fix it or use something else. Then you will do mastering and mixing, adding effects and creating a nice cover. In a couple of months, you will have an album with a clean sound and neat content, great cover. The key is that here you should pay more attention to the process. You need to have a good plan (lyrics and music). This going to be lengthy but you will be fine even if bus guitarist decides to leave in the middle of the process - just arrange a replacement. In music, it works fine, but in business, time plays against you and plan may not be relevant. Agile You with your band are on a stage. You did have time f

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 wa

So what it means to have effective test automation? Let's say I can automate 10 000 tests a day. Impressive number, isn't it? Does it mean that my test automation effective? Hardly we can tell without knowing other things. Turns out that test automation effectiveness has little to do with how many tests you can automate a day. To judge effectiveness we need to think about what value test automation adds. That leads me to a thought that test automation may be really the wrong term. Test automation is an activity, not a product. Even worse, the product that test automation creates (the value it produces) may be created by other means, too. What value test automation creates? Faster execution of 70 000 UI test scenarios? Don't think so. Nice test result report? Well, maybe, but not necessarily. My favourite one, "elimination of human error in testing". I will not even bother to comment. So the value it creates? My best guess nowadays would be that testing is a

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

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 are