Skip to main content

Test automation in agile

Test automation importance
With our change to agile, we have made an important paradigm shift. In the old days we would stick to our planned roadmap, and compromise either on delivery dates or software quality. In Agile software development we are willing to compromise on scope, but not on software quality or delivery dates. This means in short: no code goes out untested.
 
What tests to execute?
It is nearly impossible to test everything. There are so many types of tests, like: regression, story acceptance, developer, integration, usability, performance, security, upgrade, user acceptance etc. In our release planning, we must make a conscious decision which of those types we want to execute. Some of the test types may require additional experts, some of the tests may not be relevant, some may be just too costly.  

The usual scrum tests Within our sprints, we tend to stick to regression tests, story acceptance tests, developer tests and integration tests. Developer tests are internal component tests, that test a component directly without the need of other components. Integration tests review the interaction between two or more components. Story acceptance tests verify the acceptance criteria. Regression tests are the story acceptance tests of previous sprints and may also include parts of the integration tests.
 
Which tests to automate?
For some tests it may not make sense to automate. Will the test ever be executed again? If not, then it will probably not pay off to automate it. Also consider the cost of test automation versus the time needed to test manually. Especially for UI tests, it may be cheaper to do manual tests. Drag and drop, and visual control of the result are very hard to automate. For normal webforms or low level service tests, automation is efficient.  

What are the risks of not automating?
It is likely, that those tests that we decided not to automate, will not be executed in future sprints. So future sprints may break existing functionality without us knowing it. With less test coverage, we will get afraid to refactor our code. In the extreme case, we would end up with an application that we don't dare to touch. So it is very important to have automated regression tests with good coverage.

Comments

Unknown said…
there should be a robust Software Test Automation framework to trace the test scripts for test cases and deliver quality reports
12:45 PM
Post a Comment

Popular posts from this blog

SSL handshake failed: Secure connection truncated

Got this problem on Ubuntu 9.10 and 10.10. svn co --username=xx https:/yy zz “SSL handshake failed: Secure connection truncated” According to this link bug-ubuntu The solution is: sudo apt-get install libneon27 cd /usr/lib/ sudo rm libneon-gnutls.so.27 sudo ln -s /usr/lib/libneon.so.27 libneon-gnutls.so.27
12 comments
Read more

Junit4 running parallel junit classes

To run junit testcases parallel, you can create your own class to run junit with: Add this tag to your class declaration. @RunWith(Parallelized.class) Implementation of this class looks like: package mypackage; import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors; import java.util.concurrent.TimeUnit; import org.junit.runners.Parameterized; import org.junit.runners.model.RunnerScheduler; public class Parallelized extends Parameterized {         private static class ThreadPoolScheduler implements RunnerScheduler     {         private ExecutorService executor;                 public ThreadPoolScheduler()         {             String threads = System.getProperty("junit.parallel.threads", "16");    ...
Post a Comment
Read more

Create a groovy console and bind to selenium

Required groovy files In the previous posting we defined the pom file that we need for our build environment. Now we will setup some groovy files to get selenium and groovy running interactively. ConsoleWaiter.groovy The idea of Groovy Console I found on some other sides. Honour goes for instance too: http://josefbetancourt.wordpress.com/tag/eclipse-2/ I copied some code of this, and put it under src/test/groovy/com/jankester/selenium/test/utils: package com.jankester.selenium.test.utils /** * File: ConsoleWaiter.groovy */ import groovy.lang.Binding; import groovy.ui.Console; /** * Provides a wrapper for the console. * * Based on source by John Green * Adapted from: http://www.oehive.org/files/ConsoleWaiter.groovy * Released under the Eclipse Public License * http://www.eclipse.org/legal/epl-v10.html * * I added methods to allow use from Java. * * The run() method launches the console and causes this thread * to sleep until the console's window is closed....
1 comment
Read more