Case Study: Apodora used on "Project T"

Prepared By: ACULIS, Inc.

This case study will examine the use of Apodora as it relates to Project T. Project T is a real project whose name has been changed to protect the privacy of those involved. This paper will discuss the implementation details, how Apodora is being used today, and some of the drawbacks and advantages to using Apodora in this situation.

Project T Before Apodora

Our case study begins with "Project T." This project utilizes data-driven web pages. The site contains 15-plus pages with entities that can be created, modified, archived and set to interact with other created entities.

No automated testing was used on Project T before Apodora. All testing was accomplished manually, which took upwards of 3 weeks or more, after code completion. A three-person team was required to complete all the test cases. Regression testing time is not included in these figures and, when necessary, regression testing extended the completion time greatly.

Implementing Apodora

Apodora was introduced to Project T with the hope that test cases would be completed faster and more accurately, in addition to performing functional testing and creating time to add necessary test cases for an expanding project.

Apodora was implemented according to the standard, documented procedure IronPython and a MYSQL database. The first task Apodora was applied to was to replace manual, core, test cases with scripted ones to be used in regression. These manual test cases served as blueprints to script the automated ones. Maintenance of the scripts was less important than getting the core test cases automated and would be dealt with later. Once the scripts were created, they were put into source control where they could be checked out and used. These scripts were used as a regression test to insure the functionality of the project. After these core test cases were automated, other manual test cases were scripted and put into source control. These other scripts were used after the regression scripts were completed in order to check more the functionality and features more thoroughly.

Project T Today

Today, Apodora is used by a team of 5 to run regression scripts that check the project's core functionality after every build. This team is also continuously adding new scripts to expand the regression tests and allow more detailed automation testing. Increasing automation shortens the manual testing required and allows the testers to explore deeper issues, implement load testing, and test new implemented features. This team of 5 also performs maintenance on the automation scripts. If any script is found in need of maintenance, one member the team corrects the issue while the others move on to other areas of the project. In this manner, testing can proceed without interruption.

Drawbacks Experienced

A few drawbacks were encountered using Apodora. The most prominent was discovered when first scripting the tests. Maintenance of the scripts slowed down the testing. If a script was in need of maintenance, it had to be remedied before automated testing could resume. A second drawback involved learning the scripting language, Python. If this language is already known, then naturally, this drawback is averted. In addition, if several team members are using Apodora, the naming scheme of these objects can be different. This can lead to memorizing the same objects with different names.

Advantages Experienced

Several Benefits were realized by using Apodora. The time required for manual testing of core functionality was greatly shortened. Regression testing could be performed relatively quickly, and the time formerly spent on manual testing could now be devoted to creating more and better test cases. Maintenance of the scripts was easy due to Apodora's ability to memorize object attributes. If an object did change, it was changed in one place in and saved in the database, simultaneously correcting all scripts which used the object. Another benefit in using Apodora on Project T was the ability to create entities much more quickly then doing it manually. This time-savings allowed for load testing to be completed. In addition, Apodora could use the same scripts on different testing machines, thus increasing testing efficiency and removing the limits inherent in only one machine with one set of scripts.

Conclusion

Overall Apodora has been beneficial to the testing of Apodora. It has decreased the time required to perform the core functionality testing, and in turn closes the gap between code builds and testing feedback. Although maintenance did impede the progress of the Apodora implementation, Apodora's unique approach to handling that maintenance made it easy to deal with and overcome. The time that Apodora saved has allowed Project T's test engineers to increase their test coverage while decreasing their overall time used in testing.

Download PDF Version

Click here to download PDF of Project T Case Study

Apodora Flash Tutorial

For a demonstration of how to script in Apodora please view the Apodora Flash Tutorial Video here. The demo will show a number of the core concepts of Apodora as listed below.