In today’s constantly changing market, continuous delivery is one of the most popular engineering approaches: most companies claim they work according to CD rules, or at least don’t say out loud they don’t. Popularization of this methodology comes from its main idea: an engineering process based on short, repetitive iterations, where every iteration ends with delivering user value and getting feedback from it. Knowing the main rules of the continuous delivery approach, how do we deal with testing and quality assurance in such a fast and repetitive process? Get rid of the walls Let’s consider a simplified engineering process based on the following consecutive phases: specification, development, testing and operations. From a quality assurance perspective, the problem is that testing is the last phase before shipping features to the users, which is often too late, especially if we’re dealing with the iterative nature of a continuous delivery approach. Throwing changes over pro...
Posts
Recruiting is never an easy process. It doesn’t matter on which side of the table we’re sitting – whether we’re applying for a job or interviewing candidates, there’s always some tension or misunderstanding, hence good recruitment is considered almost as an art. Since Software Development is an employee market, recruiting engineers is even harder. I’ve already wrote about hiring software testers, where I focused on bigger picture – from publishing job description, onboarding process, to creating skills’ development environment. Although there’re still a lot of questions in this area, both from established companies and small startups. I’ve also noticed substantial concern about recruitment experience on few QA communities. Therefore I decided to revisit this subject and dig even deeper. In this post I want to focus on recruitment process from recruiter’s perspective, and in future one I’ll wear candidate’s hat. All thoughts are based on my own experience in recruiting candidates a...
If you work with distributed version control systems like Git, concept of pull requests should be clearly obvious to you. In simple words: if you want to have some code implemented in project maintained by others, you make yourself a branch, write code and create a pull request that will be merge to this project after code review. In big picture: it’s you who should make changes and the project owners are only doing code reviews. Distributed architecture means distributed organization Idea of external pull request works well also when it comes to single company and distributed architecture. Quoting Conway’s law on software architecture: “organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations”. I’m not going to argue whether architecture or organization structure comes first, but the fact is that most companies that implemented distributed architecture are organized into teams. T...
Code reviews are essential for an software engineering process. Popularised with open-source community, they becoming a standard for every development team. When done right, can not only benefit in avoiding bugs and better code quality, but also be instructive for a developer. Although code reviews and pull requests are well popularised through developers, it’s still kind of an unknown land for testers. In most of the scrum teams I’ve worked with, test engineers weren’t participating in pull-request reviews by default. It’s high time to change testers (and teams!) mindset. In this post I would like to consider code review from test engineer perspective and point it’s benefits, both for testers and scrum teams. Wait, but ISTQB says… I need to do a little disclaimer first: yes, I’m familiar with black/grey box testing approach. I do consider that testing without knowing implementation details can be beneficial. This aims problems of tendency due to knowledge of decisi...
This article by me was originally published on TheServerSide . There’s a common phrase in testing: if you do something more than once – automate it. Software testing, where we routinely perform similar actions, is a perfect base for automation. In modern software development, with the use of microservices and continuous deployment approach, we want to deliver features fast and often. Therefore, test automation becomes even more important, yet still facing some common problems. Based on my experience, here is my list of top 5 mistakes that teams make in acceptance test automation. Stability False Fails? Always-red plans? We all know that. Stability of automated tests is one of the most obvious issues, yet most difficult to obtain. Even big players like LinkedIn or Spotify admit to have struggled with it. While designing your automation, you should put extra attention to stability, as it is the most frequent cause of failure and test inefficiency. Writing tests is just a ...
So, what is this Agile Testing? It’s kind of fancy term and everybody use it in software development and QA world, but do we really understand it? What is different in agile approach to testing than in classic ones? I will try to highlight core concepts, that stands for Agile Testing approach. Please don’t consider this as any kind of manifesto, rather that I want to summarize list of good practices for testers and QAs working in agile teams. Continuous Quality We’ll look down on whats’s in my opinion the most important part of the concept. In stardard – let’s say – waterfall aproach, testing is just another step in the process. When development is done, here comes the test stage, and usually some kind of QA branch is responsible for testing the product of preceding development stage. This approach have been prove correct in case of large systems, with stable and well know requirements. However, today’s way of delivering software differs from this. There is hu...