| || |
Automation proof of concept...
I need to put together a plan including milestones, etc... for a proof of concept to determine whether or not the testing tool we are evaluating (Robot) is the right answer.
I am relatively new to automation and was wondering if there are any articles out there or any advice?
Re: Automation proof of concept...
Yeah, there are numerous tool comparison papers out on the internet. There are a couple on the download page here on this site.
Basically, look for this in a tool.
1) Ability to recognize the application and its objects, or build custom object definitions. Does it define them in script, or in a library. 2) Ability to build scripts and function libraries to extend beyond the tools own built in functions.
3) Flexibility and strength of the script language. Is it a custom language or variant of a common language, or is it a full common language with the custom test functions added on. As part of this how easy is it to build your own custom DLL/OCX (external function library) or tie into one (hook an outside API). Like being able to hook the Windows API DLL's.
4) Does the script editor have good tools. An IDE type interface is good to have, especially where you have multiple windows open so you can work on multiple files at a time.
5) Does the script editor have a way to "check" the syntax and variable definitions without having to "compile"/run the script.
6) Does the script editor have a good debugger feature. Ability to set breakpoints in code and set variable watch points to view values during debug execution.
7) Does the tool have the ability to talk to external data sources (Excel or SQL-Server or other database engines).
8) Does it store the files as standard text files (ASCII) and the object library as standard text files (ASCII). If it stores everything as a binary file format or in a database you will wish differently later on when you have to support multiple projects and applications.
Do not believe the "Automation is Automagic" (Record/Playback and anyone can do this - meaning non-technical staff) B.S. from the tool manufacturers. You will need people with programming knowledge experience (to build scripts with logic and error handling, and understand how to talk to objects/controls on a GUI or how to hook a Windows DLL API) to build out your automation framework and function libraries. Also, have a person with application knowledge and testing experience work with your automator (if you get all 3 in one then that will work too). This last person will able to design tests and data that the automator will script for.
Finally, set a realistic expectation with upper management and other groups. This (automation) will not be something that can be done overnight. It will take time, planning and effort. Start small and build out after you have the building blocks in place. I recommend reading articles by Brett Pettichord, James Bach, Elfriede Dustin, Linda Hayes, and Ed Kitt to start off.