Intelliswift Pioneers Practical Adoption of Acceptance Test-Driven Development (ATDD)

What is the manifesto for Agile Software Development?
Information systems development projects have a reputation for failing to deliver business requirements, meet cost, quality and time targets, or realize benefits, despite 30 years of research and development of best practices. Of late, the adoption of Agility has promoted joint application development methodologies with high user involvement in software build decisions. These methods promote continuous monitoring and adapting of deliverables to meet fixed benefits. It promotes individuals and interactions over processes and tools to help us choose working software instead of comprehensive documentation. Agile recommends customer collaboration instead of long-drawn contract negotiation. The game changer in Agile adoption is that it enables service providers to quickly respond to changes instead of following a plan and occasionally end up in a surprise failure.

The Traditional Acceptance Testing
Acceptance testing is performed to determine whether or not the software system has met the requirement specifications. The main purpose is to evaluate the system's compliance with the business requirements and verify whether it has met the required criteria for delivery to end users. Some forms of acceptance testing that are adopted across the industry are User Acceptance Testing, Business Acceptance Testing, Alpha Testing, and Beta Testing. The traditional approaches for acceptance testing are manual acceptance testing, wherein the user executes the system manually using his creativity. The other flavor is acceptance testing with GUI Test Drivers, wherein tools are used to do functional/acceptance testing through a user interface such as a native GUI or web interface. The drawbacks of both of the above two approaches are that these are expensive, error-prone, and not repeatable.

Why all the buzz around Acceptance Test-Driven Development? 
Analogous to Test-Driven Development (TTD), the Acceptance Test-Driven Development (ATDD) practice consists of the use of automated acceptance tests with the additional constraint that these tests be written in advance of implementing the corresponding functionality.

The product owner, customer, or domain expert is able to specify new functionalities by writing new acceptance tests or test cases, after consultation with developers.

The Intelliswift way of Acceptance Test-Driven Development 
Here at Intelliswift, the practice of ATDD is adopted by using tools such as Fit/FitNesse. Fit is a framework for integrated testing and FitNesse is a wiki that uses Fit. FitNesse is a Software Collaboration and Communication Tool and it works very well with numerous technology stack traces such as Java, C#, Python, Smalltalk, .NET, and C++, to name a few. This tool is used for Automated Functional Testing, defining Acceptance Tests, as well as to check whether “we are building the right thing.” It helps us to create a feedback loop between customers, testers, and programmers. Tests are written before the code, so this approach supports TDD, i.e., Test-Driven Development. FitNesse is open source and execution of the tests are automated, moreover, the tests are deterministic. Testing within the FitNesse system involves the wiki page, which expresses the test as a decision table. It also has the testing engine, which interprets the wiki page. There is a test fixture, which is invoked by the engine and in turn it invokes the system.

How to utilize FitNesse as a collaboration tool for software development following Agile methodologies? 
FitNesse enables the ability to measure the running system performance as well as the tested features, which is a key metric for measuring software project progress and success. The success of the software project depends mainly on collaboration and communication. We use Fit to a great extend for enhancing collaboration in software development based on Agile methodologies. It also enables customers, testers, and programmers learn more about their software by comparing expectations to actual results. This is the best way to collaborate on complicated problems early in the development cycle with fewer errors.

The Fit tool is used to write, organize, and execute table- based tests. Fit tables help to clarify “textual requirements.” The tables “are taken as requirements verifiable and executable.” The motive behind Fit/FitNesse testing is to demonstrate working functionalities.

Advantages that we derive from FitNesse Tests

FitNesse automated acceptance tests provide several advantages over other traditional tests. FitNesse tests give us the feature feedback very early in the project. In fact, as the tests are written first, programmers can code to the tests. FitNesse tests also give us the feature feedback very frequently in the development life cycle. They can be run manually or automatically by developers or testers with web access to the server, as frequently as required. The tests are deterministic as they either run green or red. If they run green for a given requirement, either the requirement is done so that we can move on to the next requirement, or the set of tests is not yet exactly right, in which case we refine them. Either way, we are successively refining the system in an orderly way. With each new test running green, we can all see the system getting better, more valuable, and closer to what we need. Being based on example data, FitNesse tests exercise more paths through the business logic. When we use FitNesse, we run less risk of missing an important feature or functional behavior.

FitNesse with Selenium in Intelliswift

Conclusions
A key Agile principle worth reiteration is that “individuals and interactions triumph over tools and techniques.” Giving up certainly does not mean giving up predictability. Instead of invisible buffers hiding the progress of the project, we can see the true flow of work. By delivering in parts using small batches, the project’s progress should be clearer and the prediction of delivery dates is more robust. This is a trade-off against the traditional approach and depends on the customer’s business drivers. We help organizations adopt Agile practices such as ATDD and stay ahead of the competition.