The team I am working with was never into Agile before. We have a daily scrum-call and before that, we have to define all the tasks that we are going to work on for a number of sprints. For example, there is a Product Increment Planning meeting where we put all the user requirements into the product backlog. Then we put them back to the respective sprints.

A product increment consists of about five iterations, or five sprints. And we pull each of these backlog items to these particular sprints or iterations, so that it is easy for the development team to pick up, based on the priority. The backlog is set, and it is pulled into particular sprints, based on business priority.

So it helps the development team to take up and finish tasks within the required timeframe. It helps in productivity, traceability, and saves time.

It should allow the teams to create automated test cases a lot faster. They can do their testing within a two week sprint and then get the products released into production a lot sooner.

We deliver test cases ten times faster and automate in hours vs. days or weeks. We went from 90+ days behind in new automation to full, in-sprint automation with little to no technical debt.

Automation maintenance is now manageable. It reduced the number of people required for testing by 75%.

We deliver more stories faster.

Using the test modeling approach helped 

• get early alignment on requirements
• prevent design and implementation defects in earlier development phases if models were used from the start to get everyone’s alignment
• improve test coverage (with manual and automated testing).

In terms of meeting business challenges, it helped to shorten the dev/testing cycle by identifying requirements gaps early in the process, by having models shared within the development team. It helped increase test coverage and reduce the number of issues experienced by clients/customers. It made test design & writing process more efficient. 

We are trying to establish a process. As of now, we have not come to a point where we are only using ARD with other tools. We are trying to find better ways of how to use it. We have just done a type of PoC, where we have some model and created a number of test cases, which gives us an idea of the test cases to be executed afterward. We wanted to use it digitally, in practice, but what we see is data integration points. This does not give us the flexibility of ramming the test with multiple sets of data at one time. Therefore, we are just trying to look into the aspect where it gives us more flexibility in terms of integration and using it in our continuous process.

Optimization is something which I like in the tool. It gives me an idea of what are the minimum number of cases which I can execute in order to complete my testing.

There are three major benefits. The first one is there is a time savings. It's much faster to create the model than it is to generate test cases. It's much faster to update the test cases in the model than it is to update them manually. 

The second benefit is really around organization. It helps you organize the different parts of your application and it really forces you to understand how they work well together. 

The third benefit is it's a visual representation of your requirements, which is very useful when communicating with a business partner or communicating with another person inside the company, to help them understand the application.

The best example of improvement would be better communications available for my project.

It has been pretty dramatic. We have rolled it out across many of our digital teams. In the first year, we saw about a 70% reduction in our script creation time. So, we went from five days per sprint to one day, one to one and a half days per sprint in the script creation. So, it has been really effective.

I believe the best thing is that you can automatically generate your test cases.

We have a number of challenges and one of the methods we use to solve these is model-based testing. That's what we're researching right now. We're doing a proof of concept with Agile Requirements Designer, which is pretty feature rich. ARD was a startup and CA bought it a little bit more than a year ago. Since then, the quality has greatly improved.

It reduced the effort required for test case creation, test case review, automation script generation, and maintenance of test cases and automation scripts. We were able to reduce our QA team size by 50 percent. It helped resources without programming knowledge to create automation scripts. It enabled in-sprint automation and implement continuous testing.

It helped us to move from manual testing to automation testing. Application level SMEs without scripting knowledge were able to create automation scripts. Integration with Test Data Manager, reduced the effort required in synthetic data generation and finding the test data from a master testbed quickly. Integration with Rally helped us to upload test cases quickly.

We used to provide RTMs to the technical team or the testing team, but now, CA ARD is an extra helping hand. We can provide the exact scope of testing or development to the technical team. That enhances things at the organizational level.

I think it helps the communication between the testing organization and the requirements group. It helps us to simplify the work. Instead of dealing with individual test cases, you're working with a model. And a lot of people - and I agree with that - like the visual aspect of the modeling.

By using ARD it allowed junior developers to write code because they had all of the requirements in the business flow.

We can deliver software better and faster.