1. Use the same deployment mechanism for all environments
When you do something often, you get good at it. So deploy to all environments using the same mechanism. That way, when you deploy to production things less likely to go wrong.
Agile emphasises the importance of communication. This is not just about the formal communication at stand-ups and meetings, it is also about everyday communication within the team.
Consider the following example.
A team member tries something new with some automated tests. They hope the change could be an improvement and that it could provide significant benefits.
Performance testing is often difficult and expensive to do. When you need to get real-World performance figures you need to test on real-World hardware and this is not always possible. Even when it can be achieved it is difficult to do frequently without a dedciated (and hence expensive) performance environment.
When we talk about non-functional requirements we often focus on performance and response times. But there are many other types of non-functional requirements and their obscurity can lead to them being missed.
Here are some non-functional requirements that can get forgotten:
Agile drives frequent releases and frequent releases drive automated testing. You can't just switch on test automation though, there is a lot of investment in time and energy required and the payoff is usually in the medium to long term.
So far we have built a simple Spring MVC web application and added a Cucumber based acceptance test. The next step is to add in a Selenium based Cucumber acceptance test. First we add in some Cucumber scenarios. Here is the feature file:
With the basic application in place it is now time to focus on testing. First up we add a Cucumber acceptance test. It is a good idea to keep your acceptance tests separate from your unit tests, so I tend to run them in the integration-test phase of Maven. To do this use the failsafe plugin, adding something like this to your pom:
