What does your task board say about your team? Many teams have a separate testing column. This indicates that we are still doing hand-offs from development to testing and that testing is an afterthought. Testing is not a phase that happens at the end of a project and it’s not a phase that happens at the…
Most teams today use an inverted pyramid where most of the tests are manual User Acceptance Tests and System tests and are manually executed via the UI. Unit tests are non-existent or are too few to be beneficial. In order to have a maintainable test suite, as explained in this post, the base of our pyramid…
When trying to decide how to distribute our testing efforts and how many tests to write for each different type, it’s important to consider: Test coverage: How much of the code has a test that verifies its behaviorTest execution time: How long does it take to run the test and get a result backTest feedback: How…
Merriam-Webster defines the word bug as "an unexpected defect, fault, flaw, or imperfection." In 1946, the 1st ever case of a software bug was reported in an early electro-mechanical computer called the Mark II. An actual moth got trapped in the computer relay and caused it to malfunction. The moth was removed and taped into a…
When we look at the different types of tests and the Agile Testing Quadrant, which tests in which quadrant can we automate? In general, any tests that can be scripted can and should be automated. If we can map out a series of preparatory steps, followed by an action that results in an expected value or…
Brian Marick came up with a way to categorize the different types by 2 dimensions: Tests that support programming or the team and tests that critique the productTests that are technology facing and tests that are business facing Test that support the team: These are tests that help the team build and change the application with…
Test definitions vary. Sometimes they are categorized by type, level and approach. Below is my take on the different types of testing. Unit Testing: Verifies that a single unit of code (a specific behavior in a method) behaves as intended. Integration Testing: Verifies that two or more units communicating with each other behave as intended. Component…
Beyond Iterative Coding Many software teams think they're "doing Agile" when they're really just breaking down their coding phase into smaller chunks. This fundamental misconception might be holding your team back from achieving true agility and delivering real business value. The Misconception: "Agile Is Just Iterative Development" I've visited dozens of organizations that proudly claim to…
Over many consulting engagements, I’ve come to see 4 stages that organizations and teams go through as they try to learn and implement Scrum on their own. Typically, these engagements start when an organization reaches out asking for help as they are not seeing the benefits they expected after adopting Scrum. I usually find the organization…
In my previous post, I talked about establishing a debt payment plan. On a Scrum team, there are several approaches a team can take to pay down the debt. Debt Limit Trigger – Whenever our debt limit is reached, the team focuses the next Sprint on technical debt reduction (better than nothing).Release Trigger - After every…
In the previous blog, we looked at how when we don’t actively manage our debt, it can lead to a vicious cycle we can’t get out of. We want to make prudent and deliberate decision on debt and have a plan to service the debt and make our payments. So to do that, we need a…
In my previous post, we looked at the difference between good technical debt and bad technical debt and highlighted the importance of keeping our debt low. Unfortunately, the typical scenario that most teams face is that they eventually reach a point where their output is lower then what it used to be. Instead of stopping and…
In my previous post, we defined technical debt and saw how not all technical debt is bad. Just like in the financial world, some type of debt is considered ok as long as it is paid back. Consider a house loan or a car loan for example. Those are generally considered acceptable types of debt in…
In my previous posts we looked at symptoms of bad code and reasons we write bad code. And bad code leads to technical debt. The Technical Debt Metaphor Ward Cunningham introduced the Technical Debt metaphor by stating: “Shipping first time code is like going into debt. A little debt speeds development so long as it is…
In my previous post, I discussed symptoms of bad code. Here I’m going to look into some of the reasons we end up writing bad code: Top 5 Reasons For Writing Bad Code 1. Deadlines You’ll hear excuses like we have a deadline to meet so we don’t have time to test or to make the…