Skip to main content

Posts

Showing posts with the label Methodology

Testing in Continuous Delivery: Shift Left

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

Recruiting Software Engineers: company perspective

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

Software testing vs modern architecture

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 review for Testers

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

Software Testing Certification

Professional certification is a hot topic. While professions are getting more and more specialised and rivalry is not only on the employee level, but HRs and recruiters also, who’re competing in hiring best professionals, it takes even more to promote yourself and prove your value and knowledge. On the other hand, professional certification is a business, and while exams are paid, certifications centres takes profit from number of people attending. There’s also no certification trend lately, saying that in professions like software development, certificates don’t prove ones value, because they don’t show experience, ability to learn and wide knowledge. Are professional certifications worth taking in software development world? The answer is – it depends, obviously. Let’s consider this question from few characters (fictional), being in different state of their careers and coming from different background. Peter – 0 years of experience, student  Although Peter is a coll...

Microservices testing

Modern software engineering is all about scalability, product delivery time and cross-platform abilities. These are not just fancy terms – since internet boom, smartphones and all this post-pc era in general, software development turns from monolith, centralised systems into multi-platform applications, with necessity of adjust to constantly changing market requirements. Microservices quickly becames new architecture standard, providing implementation independence and short delivery cycles. New architecture style creates also new challenges in testing and quality assurance. In this article I would like to outline strategies for testing microservices architecture. Most important thing is to understand difference between specific testing layers and their complementarity. Why microservices?  What’s the architecture of typical, corporate IT system in sectors like financial services, insurances or banking? Typically it’s monolith-like architecture, based on single, relat...

How to hire a tester

Being a tester is quite confusing: you write code, but you’re not a Programmer. You perfectly know business requirements, but you’re not a Product Owner. You handle test environments, but you’re not an DevOps. Role of technical testers in modern agile development teams is significantly different, and requires knowledge in many fields: software engineering, programming, test automation, environment management, …etc. Result? Hiring good and experienced testers becomes more and more difficult, since being one often means to be in temporary state before turning into programmer or product owner role. So, how to hire dedicated testers ? Screening job candidates  We’re lucky ones working in IT, since it’s employee market, and usually you don’t have to search for a job – you receive the offers. For recruiter, first and most obvious phase of searching an ideal candidate is screening LinkedIn profiles. I’m not a recruiter, but from candidate perspective it’s looks too often like sendi...

Top 5 traps of test automation

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

What is Agile Testing?

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

Test Automation: Good, Bad and Ugly

The modern approach to software quality and software development life cycle requires that business guys, developers and testers understand that the long manual test phase, although often still necessary, must be reduced to a minimum and replaced by test automation. Working in continuous delivery and continuous integration environment requires us to create automated tests that run on demand, checking our application integration and it’s core functionality correctness. However, there are still many problems with designing and writing automated tests, resulting in their costly maintenance or abandonment in favour of a return to manual processes. In this article I will focus on describing common good practices of test automation. This post is more than an overview than complete reference guide. Broader aspects, such as the Page Object pattern or Page Factory will be described in detail in a separate article on this blog. Although most practices apply for every types of automated tests...