A QA-guy blog

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