QuickCARE Software Services, LP is a privately owned company, headquartered in Dallas, Texas, and a valued AutomatedQA customer. QuickCARE is currently working on their QuickCARE v.3 .NET software, an enterprise-level solution for managing clinical and financial processes in the long-term healthcare industry. Robert Leahey from QuickCARE recently took the time to tell us how they have used AQdevTeam to track their QuickCARE v.3 .NET software development process.

Robert used to work for AutomatedQA, but even before that he was an enthusiatic user of our products. We're honored that he's still just as enthusiastic about them and is an active member of TeamAQA.

Much of the information surrounding our new project (requirements, change requests, test cases, etc.) was contained in different locations and proprietary, static formats. We needed to:
a) Consolidate information into one repository.
b) Make the data dynamic for better automation.
The complication here is that, since various departments are involved, we were not able to get a full buy-in on a single repository. We needed a highly customizable, flexible and automatable data management tool for tracking multiple items from a variety of sources.

Given my prior experience with AQdevTeam, I knew that it was the tool for our needs. Even if it was only the QA department using it, I knew it would handle our test cases, linking, importing and automation.

Given our situation that various important documents needed by our QA department were sitting in a variety of locations and formats, and we wanted a dynamic and linkable version of all that information for our test cases, we chose to use AQdevTeam to serve as our mediator to those other sources. We created custom item types, links, and macros that regularly import data from the other sources into our AQdevTeam solution.
- For requirements (generated regularly by another department into HTML docs), we pull some general information about the structure of the requirements, and then link to the HTML pages.
- For change requests (stored in a SQL Server DB), we run a macro which grabs the requests, and imports them into a matching item type in AQdevTeam. They are updated nightly and are essentially a read-only resource, for use in creation of test cases, etc.
- For test cases, we created a complex custom item type in AQdevTeam, ran a one-time import of the existing test cases (at the time stored in text files) using a macro created in the Visual Macro Builder, and now we maintain all our test cases in AQdevTeam.

- We also have item types for tasks, imported TestComplete logs, TestComplete project links, etc.

As a result, we’re able to have superior control over our test cases, linking in and taking action using the information gathered from external sources with imports that are refreshed on a nightly basis.

We’re also able to emit data from our AQdevTeam items, sending defect reports to our development team in a format that they request. But most notable is the output automation for test cases and for documentation.

- Test cases; our test cases are mapped on a one-to-one basis with test suites in TestComplete (or “test items” in TestComplete 4). Once we’ve defined a test case in AQdevTeam, there’s usually still a good bit of work to do in order to get all our test information into a TestComplete script. As a result, we created automation scripts in AQdevTeam that do the following:

1 - Create a new TestComplete project (if needed), pre-populating the project’s script code units with common routines and comments.
2 - Name the units in the new project with prefixes from our test project name, i.e. if the new test project is named “Login and Logout”, then the generated prefix would be “lal”, thus lalMain.sj, lalImplementation.sj, etc.
3 - New “to-do” items are created in AQdevTeam, reminding me to check the new project into source control and some other housekeeping related to a new project.

For implementation of a new test case, the automation continues with the following:

4 - A new Test Suite is created in our TestComplete project, named with the name of the test case, and the AQdevTeam identifier is plugged into the description field, for later linking.
5 - A new routine is added to the project’s Implementation unit, and the Test Suite is mapped to the new routine for its main procedure.
6 - Test code comments are generated for the new test suite and added to the new test code. These comments can include the automation and verification steps defined in the test case, links back to the test case and requirements.

All of this is automated from AQdevTeam for each new test case item that we define.

As for documentation, each night AQdevTeam generates a file containing summary information about our thousands of test cases, our test projects, issues being worked and results of latest test and profiling runs. This file is parsed, along with all of our test script code, by a 3rd party documentation tool and generated into an internal QA department website which anyone in the company can browse to see our QA team’s accomplishments and processes.

A final note: just this week I’ve added a new AQdevTeam item type called “QA Newsletter”. We try to publish a very brief summary of our QA work every 2 weeks, so this item type contains fields for each QA member to add a 2-3 paragraph story on what we’re working on, and this newsletter is automatically generated, added to the QA web site and sent out to management.

In short, AQdevTeam is importing, maintaining and generating data and saving the QA team’s bacon each day.

Given the amount of material being generated by AQdevTeam on a daily basis (see previous answer: documentation, summaries, TestComplete projects, test suites and test script implementation code) we are able to avoid the repetitive and “no-brainer” parts of developing robust test projects. Test implementation routine stubs and projects are all created for us by AQdevTeam; thus, when we are ready to create a test, we start directly with the pertinent code. Everything else has already been created or hooked up for us. It’s a tremendous boon to our team’s productivity.

With its flexibility, customizability and automation capabilities, we’re able to make AQdevTeam become multiple tools (documentation generator, test case manager, reporting tool, issue repository, requirements tracking, etc.). But each of those custom tools have a common UI, security and scripting tools (i.e., AQdevTeam); they also have a single, reasonable price tag (i.e., AQdevTeam).

We’ve also been able to avoid having to hire someone else to come in and handle some of these tasks for us manually. We’re a small team, and yet we’re able to manage all this ourselves.

As I said, we’re a small team, but that’s no excuse, and we refuse to be the bottleneck in our product’s delivery process. As a result, we have to continue doing more with less. By using AQdevTeam to manage our tests, results and other data, we don’t have to worry about slowing things down by having disorganized or hard-to-get-to data. By using the import automation I mentioned, we waste no time finding what we need in other locations; our test cases quickly generate their own test scripts; our TestComplete result logs are automatically imported into AQdevTeam where needed; issues and tasks are also automatically generated and finally, management can get reports and summaries anytime they want, without having to wait for us to create something for them.

End result? We can focus on the critical path: quality assurance.

In 15+ years as a programmer and IT professional, I’ve never seen a product that can compete with AQdevTeam in its flexibility, automation power or scope. Any process this product touches can be improved, and it can touch virtually any part of a development process.