Monthly Archives: December 2013

How can functional test coverage help rescue waterfall projects?

A typical waterfall project has well defined phases that go from the idea conception until putting the solution in production, being the most typical of them:

Requirements gathering
Design of the solution / Architecture
Implementation
Testing phase (including all kinds of tests)
User Acceptance Test
Go Live (put in production)
Post Go-Live support

It’s very common in big companies that there’s a functional team responsible for each phase. Thus, we get:

Business Analysts to gather requirements
Architects, Systems Engineers or Software Analysts to design the solutions
Programmers or coders to implement it
Quality Testers or Quality Assurance engineers to check its quality
The customer to test the delivered solution

However, one of the big problems from this approach is that usually these teams work in silos. The right hand doesn’t know what the left hand is doing and this causes inefficiencies. To make it worse, sometimes the way to try to reduce silos is through an immense increase in bureaucracy, forcing teams to communicate through documentation.
Continue reading →

Learning Python through Katas, TDD and CyberDojo

2 Replies

DISCLAIMER: This is not a tutorial on how to learn Python, in fact, I have never used Python before so don’t take me as example. What I want to share with you is how to learn a new language, strenghen the TDD principles and practice a Kata in an easy way.

Last week I attended the Global day of Code retreat in Barcelona. It was a wonderful experience that generated me a lot of energy to code again (I became a manager some time ago and I don’t code as often as I’d like to). That day we used the Conway’s Game of Life which I recommend to practice the TDD approach.

After investigating about several other katas I stumbled upon the Cyber dojo online tool. Basically this is a web page in which you can practice any kata and choose among more than 20 languages you want to learn without the need to do any setup at all. In other words, if you want to grasp the basics for a new language, this is the perfect place.

Also, one of the nice features from Cyber dojo is that after you’re done with all the coding you wanted to do, you can download all your changes into a zipped Git file and then you have the repository with all the changes that you worked on.

Continue reading →

Test Driven Development (TDD): Best Practices Using Java Examples

22 Replies

In the previous article Test Driven Development (TDD): Example Walkthrough an example of TDD was given. It went from writing first test and its implementation to having a set of requirements fully tested and developed. Now it’s time to learn what the best TDD practices are. This article will be built on examples from the previous one.

Best practices are solutions to a set of problems under certain situations. Not following them would make us “reinvent the wheel” and struggle with the same problems already solved by others. On the other hand, best practices should not be followed blindly. They should be tried out. With an informed decision at hand, they can be adopted as they are, modified to serve better specific situation or fully discarded.

Some of the best practices described here are inherited from other sets of practices and used when doing TDD. For example, most (if not all) unit testing practices should be used when doing TDD.
Continue reading →

Test Driven Development (TDD): Example Walkthrough

100 Replies

Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards.

The following sequence of steps is generally followed:

Add a test
Run all tests and see if the new one fails
Write some code
Run tests
Refactor code
Repeat

There’s a plenty of articles written on TDD and Wikipedia is always a good start. This article will focus on the actual test and implementation using variation of one of the Roy Osherove Katas. Do not click the link until you’re finished with this article. This excercise is best done when not all requirements are known in advance.

Below you will find the test code related to each requirement and afterwards the actual implementation. Try to read only one requirement, write the tests and the implementation yourself and compare it with the results from this article. Remember that there are many different ways to write tests and implementation. This article is only one out of many possible solutions.

Let’s start!
Continue reading →

Why do we need automation?

2 Replies

If you are still working in a waterfall methodology, you should know that the world is moving towards new methodologies… some famous concepts would be Agile, XP or Scrum and surely those words will sound familiar to you especially during the recent years.

Especially in the case of scrum, the first scrum team in which Jeff Sutherland participated took place in 1993, literally 20 years ago, and now it’s mature enough to be taken by big companies.

Continue reading →

Code and Test Coverage

5 Replies

When moving from the traditional waterfall process with manual testing towards BDD with automated execution of scenarios, one of the often asked questions is “how do you measure your test coverage?”. What it really wants to say is “we have high test coverage with manual testing, can you guarantee the same or more with the BDD?”. From there on usually comes the suggestion to transfer one-to-one manual tests to the BDD format. That’s not a good idea since the result would be less than adequate transformation to the different format without any tangible change. BDD is not only about automation but about the way we construct and deliver software.

Code Coverage Analysis

Main usages of code coverage analysis is to:

Find areas of software under test that were not exercised by a set of test cases.
Help in creation of additional test cases to increase the coverage.
Provide quantitative measure of test coverage as indirect measure of quality.
Identify redundant test cases that do not increase coverage
Identify parts of the code that is not in use

Continue reading →

Quality Assurance is not Quality Checking

4 Replies

Since years, many software companies have their Quality department, which in many cases implies that they have the responsibility to assess the quality of the releases. This department is typically called QA department (standing for Quality Assurance), but I rather think that they are doing much more of checking releases than to assure the quality and I see a huge difference these two concepts, that is, between a QA engineer and a QC engineer:

QA stands for Quality Assurance, therefore an engineer that ensures the quality. Every time a new release is being built, the QA engineer ensures that the quality is built in it. The QA is responsible for improving the processes and participates actively in the creation of the testing tools.

QC stands for Quality Checking or Quality Control. This engineer typically waits for the release to be finished in order to check if the quality is built there. A Quality Checker typically creates a list of test cases based on the requirements themselves and puts them in a tool to plan each of the BTCs. Later he executes all the test cases, in most cases manually and tracks their execution.

Continue reading →

Black-box vs White-box Testing

9 Replies

Testing shows the presence, not the absence of bugs. Edsger W. Dijkstra

Two common types of testing are black-box and white-box testing. Both can drive or be driven by development.

Black-box testing

Black-box testing (also known as functional testing) treats software under test as a black-box without knowing its internals. Tests are using software interfaces and trying to ensure that they work as expected. As long as functionality of interfaces remains unchanged, tests should pass even if internals are changed. Tester is aware of what the program should do but does not have the knowledge of how it does it. Black-box testing is most commonly used type of testing in traditional organizations that have testers as a separate department, especially when they are not proficient in coding and have difficulties to understand the code. It provides external perspective of the software under test.
Continue reading →

How to memorize the Lean Software Development principles easily

1 Reply

As part of my work, sometimes I need to memorize some speeches or some presentations and in order to do that, what I frequently use is one technique called: Memory Palace (which originally comes from an ancient method called Method of Loci).

The approach of this technique consists on basically breaking down your speech into the main concepts you want to talk about and you try to look for a visual image for each of the concepts. It is very important that you have a vivid image for every concept you want to memorize because it will be much easier to retrieve it from your memory later. Once you have all your images, you mentally place them in a place that you know perfectly that we’ll call your “memory palace”.

Continue reading →

Behavior Driven Development (BDD): Value Through Collaboration (Part 4: Automation)

2 Replies

This post is part of the “Behavior Driven Development (BDD): Value Through Collaboration” series.

Automation

The first 3 posts explored the process to define project requirements as behaviors. Once you have mastered writing BDD stories you are ready to start the journey towards the automation of scenarios.

Execution of BDD scenarios can be accomplished using many different frameworks. Some of them are JBehave (Java), Cucumber (Ruby), RSpec (Ruby), SpecFlow (.Net), and Jasmine (JavaScript). This post will use examples from JBehave. With slight modifications, they can be applied to any other framework. The above-mentioned frameworks provide installation instructions and documentation on how to write code that supports BDD. This article focuses mostly on the best practice and ways to avoid some of the common pitfalls. For detailed installation instructions and documentation, please consult the website of the selected framework.

Decision on which framework to choose should be based on which technology your team is most comfortable with, as well as the support it provides for the implementation of the phases described below. Next post in this series will provide comparison of different BDD frameworks.

Successful implementation of the BDD automation should be done in three phases.

Create library of normalized steps.
Combine steps into composites.
Empower scenarios with examples tables.

You should start with the first phase. As soon as enough steps have been created to support the first scenario, you can start with execution of the other two phases. From there on, work on all three phases should be done in parallel.