 Todd Fitch is the Quality Leader for the Small Business Division of Intuit, Inc. His team is responsible for the quality activities for QuickBooks, Quicken, Intuit BusinessConnect, and many yet-to-be-announced products. His team spans several Intuit locations including Mountain View, California; Bangalore, India; Orem, Utah; Folsom, California; Tucson, Arizona; Plano, Texas; and he also has individuals in Montana, Pennsylvania, and Australia. He is also member of Intuit’s Quality Council.
Mr. Fitch has 20 years experience in the software industry in telecommunications, medical, and financial software, five of which have been at Intuit. He has held roles as a developer, quality assurance engineer, consultant, development manager, and QA manager and has been involved with test automation for his entire career. He holds two U.S. patents in test automation and has over twenty patents pending across a wide range of topics.
Mr. Fitch is a member of San Jose State University’s Computer Engineering Department Advisory Council where he works with department faculty and the Dean on program curriculum, industry partnerships, and goal setting. He is the coauthor on three papers that have been presented at conferences over the past year.
Mr. Fitch earned his Bachelor of Science in Computer Science from San Jose State University. He also earned Masters of Business Administration degrees from the University of California, Berkeley and from Columbia University through the Berkeley-Columbia MBA Program.
In his free time, Mr. Fitch studies karate, reads, hikes, runs, enjoys cooking, teaches macroeconomics, dabbles in politics, and is a Planning Commissioner for the City of Santa Clara. He has a son who has just started his studies at San Jose State University. He and his wife Mia live in Santa Clara in an 1890 Victorian which they hope to finish renovating “some day”.
www.toddfitch.com
|
Test automation has changed considerably over the last twenty years: It has gone from a rare and expensive side effort to a necessary component of product development. However, delivering results is still not a straightforward proposition. One cannot just buy a tool and throw some people at it and expect all of the manual tests to be miraculously automated. Choosing the right tool and the right infrastructure, assigning the right people, picking the right tests to automate, and instituting a good development process are all necessary for success. Further, the company management needs to understand that test automation is a long-term investment that will not necessarily provide returns in the short-run and also that it is not a one-time project.
Two often overlooked components that receive little thought or attention are how to structure the engineers working on test automation and how that work is organized. Yet, the wrong approach can impair a test automation effort or, in the worst case, lead to complete failure. There are primarily two models that have been used for organization and these models are often used for both the people and the work.
The first is the Centralized model. In this model, all of the development, execution, and triage of test automation is handled by a central team. The engineers doing the work are typically people with technical degrees and are experts (or become experts) in software development and test automation. These engineers are generally not domain or subject matter experts and receive their automation requirements from other QA or Development teams. The automation team usually operates as a service organization that takes requests from their “customers” for new test development, maintenance, and execution and results reporting.
The second is the Decentralized model. In this model, the work is distributed across the QA organization. The engineers doing the work often have varying levels of software development and test automation skills but they are product and domain experts. They are responsible for the automation of the testing for their areas and the automation work becomes part of the QA activities that each undertakes. The QA teams are their own customers and at a minimum take on the development and maintenance tasks.
There are significant pros and cons to each model and in deciding the best way to organize the people and the work, and there are many factors to take into consideration. For example, the level of management and executive buy-in to the investment necessary for test automation is a critical factor. If there is little understanding of the benefits and/or a very short-term mentality on the part of management then delivering small, quick results is important. In this case, a centralized team is the right approach. This team can then focus on the test automation program without having to make tradeoffs on testing the product versus developing the automation. The team is then tasked with delivering a minimal set of high-value automation that can be used to show both the value of test automation as well as the possibilities.
Knowing when to transition between models is also very important. What works in one stage of evolution will almost certainly not work during another stage. It is crucial to plan for transitions and to set the expectations of management that the methodologies and models used will change.
|
