testing

Continuous Deployment changes your mind

Posted in agile, continuous delivery, continuous integration, deployment, management, software development, testing on August 14th, 2011 by Joerg – Be the first to comment

We are practicing Continuous Deployment since about a year. When looking back I realize the dramatic way this practice changed the way we work.

Just to draw the fine line between Continuous Delivery and Continuos Deployment I use the definition I once heard from Neal Ford. Continuous Delivery allows you to deploy every commit but you don’t do it every time. With Continuous Deployment you go further and really deploy every time.

I have recently been asked what the benefits of Continuous Deployment are compared to Continuous Delivery. I think the impact on your development practice is a huge thing.

In our company we practice agile development since about 2005. During that time I can remember many discussions about agile practices like:

  • Test Driven Development
  • Definition of Done
  • Potentially Shippable Product
  • Refactoring in baby steps
  • Not committing on a red build

Many of them do not easily reveal their benefits in daily business. So it becomes difficult to use them consequently.

The Definition of Done is a great example. It is easy to declare something finished or appropriately tested when there is usually a QA department that will find your mistakes during release tests. So the common recipe is write down your definition, post it on the wall and “be more disciplined”. Force yourself to write more tests, force yourself to declare things done only if they are really done and so on. This is not easy. In my experience it seldom works.

This changes dramatically when using continuous deployment. Between your commit and the production system is only an automated deployment pipeline, that usually takes something around 30 minutes. There is no QA department that does a extensive release test. Your mistakes will only be found by automated test that you wrote yourself. Well or they will be found by your Users.

Automated tests become your safety net. This again changes the way you think about TDD. It totally makes sense to have a near full coverage of your code. It also makes sense to have integration tests on API and GUI level to make sure your deployment pipeline catches most mistakes. It will not catch any mistake, but in my experience the same is true for most QA departments.

You will think differently about Potentially Shippable Products. Every commit has to be shippable and it will (not only potentially) be shipped.

This forces working in baby steps. It is just not possible to refactor a system by destroying it for several days.

If a build is red the deployment pipeline is halted. Nobody is able to apply more changes to the system unless this problem is fixed. Again something that used to be a discipline thing becomes a necessity. You need to help your teammates to fix the problem otherwise you can’t work yourself. The same is true if there is a red build in the evening. One of my teammates even talks about an addiction to fix the build before going home. It just gives you a good feeling to finish your day in a green state.

Continuous Delivery has several immediate business benefits I might tell you about another time. But most of them don’t need every commit to be deployed.

But I think the impact of deploying every commit on your development practice huge. Many agile practices make so much more sense. They fit naturally in this environment and you follow them easily. This will then result in benefits for your business on the long term.

Continuous Delivery Slides

Posted in agile, continuous delivery, continuous integration, deployment, java, management, software development, testing, version control on July 5th, 2011 by Joerg – Be the first to comment

The last Java User Group event in Berlin was hosted at Hypoport. It was about Continuous Delivery. We had about 100 guests.

There where two talks. One by Axel Fontaine who introduced Continuous Delivery especially in a Java environment. You can find his talk on Parleys or on his Blog.

I had the pleasure to introduce our experiences with Continuous Delivery. We are currently developing a new product. Since we started about a year ago we consequently used Continuous Delivery. We learned quite some lessons on our way which I presented that evening. My Slides are available here. (As this was a german event the slides are in german)

Thanks to everyone who attended the event. It was a really nice evening. Special thanks to everybody who helped organizing it.

Inheritance of class annotations in TestNG

Posted in java, software development, testing on April 5th, 2009 by Joerg – 1 Comment

Recently Oliver Fischer introduced TestNG at the Berlin-Brandenburg JUG. At one point there was an interesting discussion with the audience about class level annotations. Why should they be used? You can annotate a class like this:

@Test
public class Foo 
{
...

Now every public method in this class is considered a test method. Several people in the audience mentioned that they would still prefer to mark the test explicitly. This is just more readable. But if so, what might be a good reason to use class level annotations?

One very nice characteristic of class level annotations is that they can be inherited. Let’s assume you want several classes in a specific testgroup. What you don’t want to do is to annotate each and every test method with @Test(groups = {“MyTestGroup”}). This is simply not DRY. Using inheritance, you can instead create a base-class like this:

@Test(groups = {"MyTestGroup"})
public class BaseClass 
{
...

Now each test class that should be in this group can just extend BaseClass.

public class MyTestClass extends BaseClass 
{
...

Every public method in these classes is a test method and they belong to the group MyTestGroup. You probably still want to add the @Test annotation to each of the methods for readability. The group assignment is still valid.

What other ideas do you have for making use of annotation inheritance in TestNG?

Super simple method to create a boolean decision table

Posted in software development, testing on March 27th, 2009 by Joerg – 3 Comments

Today one of our test engineers, Manfred, presented about systematic identification of test values. One of the topics were decision tables. I was fascinated how easy he created tables with all possible combinations. Here is how:

  1. Write the conditions in seperate rows.
  2. Condition A 
    Condition B
    Condition C
    
  3. Now make 2^n columns where n is the number of conditions.
  4. Condition A |   |   |   |   |   |   |   |   |
    Condition B |   |   |   |   |   |   |   |   |
    Condition C |   |   |   |   |   |   |   |   |
    
  5. Start at the bottom condition and write alternating Y and N.
  6. Condition A |   |   |   |   |   |   |   |   |
    Condition B |   |   |   |   |   |   |   |   |
    Condition C | Y | N | Y | N | Y | N | Y | N |
    
  7. Fill the next row with alternating Y Y N N …
  8. Condition A |   |   |   |   |   |   |   |   |
    Condition B | Y | Y | N | N | Y | Y | N | N |
    Condition C | Y | N | Y | N | Y | N | Y | N |
    
  9. Each row you double the number of consecutive Ys and Ns.
  10. Condition A | Y | Y | Y | Y | N | N | N | N |
    Condition B | Y | Y | N | N | Y | Y | N | N |
    Condition C | Y | N | Y | N | Y | N | Y | N |
    
  11. Do so until all rows are filled.
  12. Now you can add your decisions to the table.
  13. Condition A | Y | Y | Y | Y | N | N | N | N |
    Condition B | Y | Y | N | N | Y | Y | N | N |
    Condition C | Y | N | Y | N | Y | N | Y | N |
    ---------------------------------------------
    Decision 1  |   | X | X |   |   |   |   |   |
    ...
    

Using this algorithm you can be sure you covered all combinations. It doesn’t matter how many conditions you have and you don’t even have to think :)

Thanks Manfred!