It's commonly accepted in IT management circles that Kanban
Just-in-time is suited mainly for projects past active
development. But it seems that most people simply repeat this statement without giving it a good thought -
why is this true, is it actually true? I'd like to explain how this statement came to life, and
show that it's not only possible - it's easy to apply JIT to projects that are being actively
developed.
Many IT managers mistakenly use word Kanban to describe Just-in-time (JIT), others confuse the latter with Lean and think that these are equal things. These are widespread confusions, and in this post we'll go over the terminology and explain what's what.
Popular tools that speed up and simplify work of a software test engineer (under construction).
Although Rich Model seems like a better approach from OOP evangelists' standpoint, Anaemic Model stays prevailing among enterprise developers. While not being very active in OOP debates, I find Anaemic architecture being very harmful for testing - and this is where I couldn't keep my cool.
While doing Randomized Testing I found out that my date formatter works incorrectly sometimes and my tests fail in 50% of cases. Very tricky bug as it appeared, check whether your project have it! This is a good demonstration of how randomization can help us learn new things about the tools that we use.
It’s common for Scrum-like teams to be upset when they don’t fulfill their sprint commitments. But should they? Is it that important to finish everything by the end of the iteration? Commitment is very attractive as a tool to exert pressure on the team, but if used beyond that it takes more than it gives. E.g. often we dedicate whole meetings spending many man-hours just to argue about why we didn't complete all the activities "in time". Hopefully by the end of the article you’ll be convinced that fulfilling sprint commitments in time is actually ineffective and shouldn't be pursued by managers.
It's hardly possible to overrate the importance of the Test Data Management in automated tests. If your strategy is chosen incorrectly, you won't be able to get to the effective testing as this is one of the most important factors that either will help or will drag you down. The article highlights how and where the data for the tests should be kept to make testing as painless and effective as possible.
Still hardcoding concrete values in your tests? That's a shame since better techniques exist that provide better coverage and test isolation. Let's talk about how we can improve testing by adding randomization. We'll cover some of the techniques like Property/Model Based Testing, Test Oracles, etc. The purpose is not to dive deeply into the details of each different kind, but to give an overview and show possible applications.
Tired of fragile tests that break without a reason? Full test run takes hours and you feel sick of endless test optimization? Waking up in the middle of the night screaming SELENIUM PLEASE NO? These are common symptoms of a wide-spread decease called Hypopyramidism. Traditional treatments are usually symptomatic: fine-tuning timeouts, running tests in parallel, taking anti-depressants and so on. But a real cure exists. And you've probably heard of it before. Its name is Test Pyramid and in this article we'll use it to make our tests fast and furious.
In Software Testing the terminology is one of the pain points. Engineers tend to use terms differently and there is no single place that can be considered as a source of truth. The only sources that are considered authoritative are: ISTQB, IEEE 829 and SWEBOK. These sources don't always agree and sometimes their definitions simply don't seem logical. The intention of this post is to suggest the terminology that makes most sense from practical viewpoint and to outline the problems in existing "standards". In particular we'll talk about Test Levels and Test Types.
Resume: when we’re new to a tool, we usually start using this tool in a wrong way. But experience & time changes the way we think of it, we start using it differently. Here I’d like to show what stages I personally went through while writing System & Component tests until I understood exactly how testing should happen in an average web project. Many of others go through similar steps, maybe this post will help speed up their personal evolution.