What is meant by the acceptance test driven development?

Test driven development is nowadays quite popular among the programmers and developers and is gaining new heights. More and more software programmers and developers are now approving of the test driven development.  

Test driven development now seems to be making its mark after it is being considered as an individual software development process rather than being related to the first programming concepts of the agile software development methodology called the “extreme programming or XP”. 

Many different types of the test driven development have been identified such as the acceptance test driven development, traditional unit test driven development etc.

This piece of writing has entirely been dedicated to the acceptance test driven development methodology. But before we move on to the acceptance test driven development, we should be familiar with the usual test driven development process so that we get a better understanding of the acceptance test driven development. 

Steps in Test Driven Development

Test driven development is a development methodology unlike others which involves the creation of tests before the actual production of the code for the functionalities. The development cycles are shorter than the normal or usual software development cycles and consist of the following steps:

1. Addition of tests for new features that should fail.
2. Writing of code which enables the tests to pass.
3. Finally the refactoring of the code.

Styles in test Driven Development

Above 3 steps constitute a shorter development cycle that is repeated several times till the code is considered to be perfect and complete in all aspects. Several approaches or development styles have been developed like:

1. YAGNI (you ain’t gonna need it)
2. KISS (keep it simple stupid)
3. Fake it till you make it and so on.

All the development styles of the test driven development follow the two basic steps:

1. Writing of the automated unit tests before the actual features and functionalities are implemented in to the design of the software system or application.

2. Failing the above written tests: Every automated unit test is expected to fail because then only it is said to be working properly.

What is Acceptance Test Driven Development?

1. It is a development strategy that helps in building coordination in the software project so that the software product is delivered exactly as needed by the customer or the client and also in this the required functionalities are not implemented halfway. 

2. Acceptance test driven development methodology involves one or more than one customer tests for testing the customer centred features.

3. Here the requirements are treated as the executable tests.

4. We can say that the acceptance test driven development is way of bring the stake holders together on an early basis for the clarification of the requirements and thus bridging the gap between the requirements and the tests.

5. Acceptance test driven development involves the collaboration of whole development team in defining the acceptance criteria and finally turn them in to a set of distinct acceptance tests before the starting of the development process. 

6. It can be considered as a good means to know that what is being developed.

7. Acceptance test driven development is categorized under the category of agile software development process.

8. It involves the extension of the test first approach to front end of the software system or application under development process. 

9. The acceptances test like the other entire test driven development variants must fail.

10. Customers want a software product that increases productivity, helps in making more money, improving operation capability and so on. 

11. This is what is delivered with the help of the acceptance test driven development. 

What is meant by traditional unit test-driven development?

With the growing number of benefits of the test driven development it is becoming choice of a million programmers worldwide! More and more software developers are now checking in to use this option.

In the past years the test driven development was not much in use since it was considered to be a development strategy related to the test first programming concepts of the extreme programming or XP that is an agile software development process.

But later when the test driven development was established as an individual and distinct software development process, it began to be widely accepted. Rules and regulations were formulated for this newly discovered development methodology which made it a completely independent software development process. 

Types of Test Driven Development

Later on as the time passed by, two types of test driven development were discovered namely:

1. Acceptance test driven development process and
2. Traditional unit test driven development process

This article is focussed up on the latter test driven development type i.e., the traditional unit test driven development process. 

But before we start our discussion regarding the traditional unit test driven development process, let us brief up ourselves with the concepts of the test driven development process so that you will have an easy and effective grasp of what the traditional unit test driven development process really is. 

Steps in Test Driven Development

Test driven development makes use of development cycles that are quite shorter than the generally used software development cycles. These development cycles are comprised of the following steps:

1. Addition of tests
2. Execution of all the tests to see if they fail or not.
3. Writing of the code by which the tests will pass.
4. Execution of the automated test cases and check whether they succeed or not.
5. Re-factoring of the code
6. Repetition of all the above steps.

Styles in Test Driven Development

The test driven development can be carried out according to many defined styles like:

1. Keep it simple stupid (KISS)
2. You ain’t gonna need it (YAGNI)
3. Fake it till you make it

Whichever development style is followed, there are two common steps for every development style:

1. Write the tests first
2. First fail the test cases

Traditional Unit Test Driven Development

- Traditional unit test driven development (UTDD) are the result of the advance practices of the test driven development.

- Automated acceptance test cases are created based on the criteria specified by the customers or clients.

- They are used to drive the traditional unit test driven development which in turn ensures that an automated mechanism to check whether the software product meet all the requirements is available to the customers.  

- Traditional test driven development process involves the creation of automated unit tests that are meant to expose the requirements of the software system or application.

- These tests have to fail obviously since the requirements have not been implemented yet. 

- The software developer then has to write code by virtue of which the tests will pass. 

- One thing to be noted is that the test driven development tests are not the same as the unit tests though the two may appear to be similar on the surface. 

- Unit tests are meant for the testing of a piece of code in isolation. 

- On the other hand, a TDD test is meant for driving the design of the software application or program and expresses what that application is meant to do before the actual production of the source code. 

- The traditional unit test driven development grew out of some aspect of the waterfall model. 

What are different benefits of test driven development?

Everywhere in the field of software engineering the talks about the test driven development are on!  This software development methodology was previously considered to share some relation with an agile software development methodology known by the name of extreme programming or XP. 

Later the process came to be known for its individual standing having its own objectives, features and benefits and of course drawbacks. The test driven development methodology is a kind of repetitive development process that progresses by means of the repetition of some short development cycles that consist of the following steps:

1. Addition of tests
2. Execution of all the tests to see if they fail or not.
3. Writing of the code by which the tests will pass.
4. Execution of the automated test cases and check whether they succeed or not.
5. Refactoring of the code
6. Repetition of all the above steps.

The repetition of the above mentioned steps is continued till the code which is under testing is considered to be complete and proper working. 

Benefits of Test Driven Development (TDD)

The test driven development is known for its several benefits that outnumber its drawbacks. This article is focused up on the benefits of the test driven development. So let us begin by counting its benefits:

1. According to a research it was observed that the test driven development requires writing of more and more tests which in turn increases the productivity of the testers honing their testing skills.

2. A hypothesis stating a relation between the code quality and test driven development was observed which cannot be neglected! There is a considerable affect of the test driven development up on the quality of the source code. This hypothesis established a direct correlation between the productivity and the test driven development.

3. Programmers who use the test driven development process do not need to invoke the debugger quite often as in the case of the other development methodologies. The test driven development when used with a version control system proved to be more effective in the production of the code that has passed the test.

4. The correctness of the code is validated by simple methods rather than the complicated ones in the test driven development along with the driving of the design of the software system or application.

5. It allows the software developer to imagine how a particular functionality will be put in use by the user or client and thus helps in maintaining a sharp focus up on the test cases. The application interface is what that is considered more than the implementation.

6. The test driven development provides a means to approach the code via the test cases unlike other methodologies that make use of preconceptions or some mathematical assertions etc.

7. The test driven development allows the developer to make small steps wherever required unlike the other development methodologies.

8. With the test driven development the developer can effectively focus up on the task at hand.

9. Test driven development provides the coverage of at least one test to each and every functionality. This makes the developers and programmers more confident of the code.

10. Even the though more length of code is required during the implementation of the test driven development, at the end the code typically gets shorter. With large number of tests it is made sure that there are fewer bugs in the code.

11. The testing is carried out quite frequently and early so that more of the bugs are caught. Thus the TDD in a way avoids hectic debugging of the code.

12. With test driven development, more flexible, extensible and modular code is produced. 

What are the requirements in a test driven development?

The test driven development is often abbreviated as “TDD” and has been recognised as one of the common development strategies that are quite popular among the developers and the programmers. 

What is a Test Driven Development?

- This development methodology involves the repetition of short typical development cycles.

- These development cycles are shorter in duration when compared to the usual development cycles of the other software development strategies.

- The developer first requires writing a failing automated test case defining a desired new function or an improvement in an already existing function. 

- A code is then written to pass the test and later it is subjected to refactorization to meet the acceptable standards. 

- Test driven development is often considered to be related to the extreme programming to some extent.

- But, now it is being considered as a development process of its own rules and objectives.

- The test driven development also serves to improve and debug the legacy code that has been developed using the other methodologies. 

No development methodology can be carried out further without requirements, this holds true for the test driven development also. This article emphasize on the requirements of the test driven development. 

Requirements in a Test Driven Development

- The whole methodology of test driven development is supported by a set of unit tests that are automated. 

- These automated test cases are written in order to define the requirements of a particular piece of the code. 

- Such unit tests first identify the requirements and then immediately write down the code for the identified requirements all by themselves. 

- Certain assertions i.e., the true and false values are also contained in those automated unit tests. 

- The code is continually evolved and re-factorized and then subjected to testing via the automated unit tests which are put up on an automated testing frame work such as xUnit.

- Such frame works facilitate the automatic execution of the unit tests.

- These small unit tests drive the development of a small fragment of the solution.

- These unit tests also serve a tested and canonical documentation for the usage of the program’s object. 

- In the test driven development, writing the test is given the first preference rather than writing the code first. - But, this approach is considered to be difficult by many of the software programmers and developers and even some resist the use of the test driven development methodology since for them it turns out for them as the upside down approach for development.

- The test driven development methodology takes in to consideration the fact that the test is the rightmost important thing and it is required that we make sure that the test passes. 

But what is to be done if the unit tests itself are wrong and do not suffice for providing adequate coverage to the code? 

- If it is the latter case i.e., if the tests are not able to provide enough coverage then there is one possibility that your unit tests are missing out some of the requirements of the code. 

- This often happens in the case of manual testing but not so when we use the automation techniques.

- Automated unit tests make sure that no requirement of the code is left uncovered.

- So, the quality of the unit tests defines the quality of the whole test driven development process also. 

Starting with the requirements is known as the top down approach and is more commonly followed than the bottom up approach. The requirements are treated as the executable tests which are clarified by the managers, stake holders and developers. 

What is meant by application testing cycle?

An application testing cycle states what all the activities are to be carried out in the testing. Although different organizations might be following different procedures or test plans for testing the software applications, they all follow the same application testing cycle. They draft their plans based on a common testing cycle. This is basically done to maintain the standards of testing.

APPLICATION TESTING CYCLE
The application testing cycle that we are going to discuss here is a typical test cycle for the organizations that base their application’s development on water fall model.

1. Analysis of Requirements
- Since this is the first phase in the development cycle of an application, the testing should begin from here itself.
- After the identification of the requirements of the application, the testers and developers together determine what all the requirements should be tested.

2. Drawing up the Test Plan
- The whole testing is planned and it includes the test plan, the test strategy and test environment creation.
- Testing is a very complex process.
- Therefore a plan is needed so that there is no messing around.
- The test plans are usually of a high level.

3. Development of Test
- A procedure for carrying out the test is designed.
- Other things like test cases, test scenarios, test scripts and test input data are also made ready.
- This phase also includes the verification of the test cases.
- The automated test cases are scripted.
- This phase is commonly called as the construction and the verification phase.

4. Execution of the Test
- The test cases are executed by the tester as per the test plan and any error or bug found is reported and documented at the same time.

5. Reporting of Test
- A final report on the carried out test is prepared which contains all the observations made and also the testing details.
- This report is submitted to the development team.

6. Analysis of the Test Results
- The results of the test are then analyzed by the whole development team in the presence of the client.
- The client and the development team together decide which issues are to be resolved and which are to be rejected.
- Risks to the application are identified and a risk assessment is prepared.
- Features and functionalities of the application software are validated.

7. Retesting of the Defects
- After resolving all the issues stated by the client, they are once again reviewed by the development if in case they have caused some other bug.
- This is commonly called as resolution testing.

8. Regression Testing/Final Testing
- This is the last but one phase of the application testing cycle and very important.
- This testing is done after making all the major as well as minor fixes in the application in order to ensure that the application is still working properly.
- If any changes are made to the application, at the same time the documentation is also updated.
- The verification of the application is done under the production conditions.
- Metrics of the test efforts are also prepared in this phase.

9. Closure of the Test
- As we know that for every test exit criteria is defined.
- When the test meets these criteria the testing is declared close and all the reports and documentations are archived.
- These archived reports are used for future reference.
- A line of attack is identified and used to prevent such similar bugs and errors in the future applications.
- The whole testing process is evaluated and ways are sort to make it better.
- The test environment is cleaned up and the restoring of all the testing machines and tools to the baseline is also done.

What are different aspects of iterative approach?

Iterative approach along with incremental development forms the heart of software development process or cycle which has been developed in response to the weaknesses of the sequential approach of water fall model.

Iterative approach begins with the execution of an initial plan and is ended with deployment with the interactions between the implementation and testing components of the cycle.

Iterative approach forms an important part of the extreme programming, rational unified process and agile software development frame works apart from the cyclic software development process.

It is similar to following the plan- do- check- act cycle of business development process.

BASIC IDEA BEHIND ITERATIVE APPROACH

- The basic idea behind this iterative approach is to develop a system or application through repeated cycles or iterations and in smaller units at one time (called incremental development).

- Such an approach allows the software testers and developers to take the advantage of earlier learnt lessons during the development of the software system or application.

- Learning comes simultaneously from development as well use of the software system or application.

- The basic idea of this whole iteration approach is to implement a task and its redesigning as stated in the project control list.

- It involves analysis of the current version of the software system or application.

STEPS IN ITERATIVE APPROACH
- The key steps involve implementation of the sub sets of the software system or application requirements and this in turn leads to the enhancement of the evolving versions until the implementation of the full software system or application.

- At each step of iteration approach slight modifications in the design are made and new functional features are added.

- The first step in the procedure for iterative approach involves the process of initialization.

- The objective of the initialization step is to create a basic version of the software system or application to which the users of the software can react and give useful feedback.

- The created basic version offers a sample of all the key features and aspects of the problem concerned and also provides a solution to that problem which can be easily implemented.

- The second step is the iteration step.

- The third step involves the controlling of the project development cycle.

- The third step involves creation of a list records of all the tasks and processes that are needed to be performed and the steps which guide the whole process of iteration process.

- The project control list also includes the new features and aspects that have to be added to the software system or application.

- Apart from all this the list also mentions the areas of the software system or application that have to be redesigned from the existing solution of the problem.

- During the analysis phase the list is regularly revised and new points are continuously added.

PRINCIPLES OF ITERATION TESTING
According to the principles of the iteration testing:

- The design as well as its implementation of any iteration should be simple, modular and straight forward.

- However the level of designing is not mentioned in the project control list.

- The analysis of an iterative project is solely based up on the user feedback and the program analysis methodologies available.

- The analysis includes testing of the structure, usability, modularity, reliability, efficiency and goal achievement rate.

- If the project is found lagging in any of these aspects, the project control list is modified accordingly.

- The iterative approach involves slicing up of functionality of the software system in to small portions or increments as they are commonly called.

- In each and every increment functionality is added via cross discipline method and from the requirements to the deployment.

Quick Glance : Sociability(Sensitivity) Tests, Tuning Cycle Tests, Protocol Tests, Thick Client Application Tests, Thin Client Application tests

SOCIABILITY(sensitivity) TESTS

Sensitivity analysis testing can determine impact of activities in one system on another related system. Such testing involves a mathematical approach to determine the impact that one system will have on another system. For example, web enabling a customer 'order status' facility may impact on performance of telemarketing screens that interrogate the same tables in the same database. The issue of web enabling ca be that it is more successful than anticipated and can result in many more inquiries than originally envisioned, which loads the IT system with one work than had been planned.

TUNING CYCLE TESTS

A series of test cycles can be executed with a primary purpose of identifying tuning opportunities. Tests can be refined and re-targeted on the fly to allow technology support staff to make configuration changes so that the impact of those changes can be immediately measured.

PROTOCOL TESTS

Protocol tests involve the mechanisms used in an application, rather than the applications themselves.For example, a protocol test of a web server will involve a number of HTTP interactions that would typically occur if a web browser were to interact with a web server - but the test would not be done using a web browser. LoadRunner is usually used to drive load into a system using VUGen at a protocol level so that a small number of computers can be used to simulate thousand of users.

THICK CLIENT APPLICATION TESTS

Thick clients, also called heavy clients, are full-featured computers that are connected to a network. While a thick client is fully functional without a network connection, it is only a "client" when it is connected to a server. The server may provide the thick client with programs and files that are not stored on the local machine's hard drive.
A thick client is a purpose built piece of software that has been developed to work as a client with a server. It often has substantial business logic embedded within it, beyond the simple validation that is able to be achieved through a web browser. A thick client is often able to be very efficient with the amount of data that is transferred between it and its server, but is also often sensitive to any poor communication links. Testing tools such as WinRunner are able to be used to drive a thick client, so that response time can be measured under a variety of circumstances within a testing regime.
Developing a load test based on thick client activity usually requires significantly more effort for the coding stage of testing, as VUGen must be used to simulate the protocol between the client and the server. That protocol may be database connection based, COM/DCOM based, a proprietary communications protocol or even a combination of protocols.

THIN CLIENT APPLICATION TESTS

An internet browser that is used to run an application is said to be a thin client. But even thin clients can consume substantial amounts of CPU time on the computer that they are running on. This is particularly the case with complex web pages that utilize many recently introduced features to liven up a web page. Rendering a page from after hitting a SUBMIT button may take several seconds even though the server may have responded to the request in less than one second. Testing tools such as WinRunner are able to be used to drive a thin client, so that response time can be measured from a users perspective, rather than from a protocol level.