Archive for the ‘Tips and Tricks’ Category

Working With OCR

Tuesday, December 1st, 2009

Face it, occasionally there is an object — or a group of objects — that gives fits to your automation project. Often, it goes like this: We testers need to select an item based on its text, and, much to our frustration, it’s embedded in an image — or we are faced with a large tree containing thousands of items that change regularly.  Typically, these things are barriers to automation. Enter Optical Character Recognition (OCR). With it, the computer can “read” whatever is on the screen, wherever it is. It performs this task by looking at the image and matching what it sees to a database of known options.

With SmarteScript, you can build a database of options on install. This may take a few moments but will improve your chances of accurately recognizing characters and words. If your application uses a font that is not installed locally, we would recommend installing the font and re-building the database.  To do this, select tools>options>utilities settings. Once there, click on the OCR database setup option. Again this may take some time but it is well worth the effort.

Occasionally we need to tweak the OCR engine. This is accomplished by manually editing the textract.ini file located in the directors c:/program files/smartesoft/smartescript/bin. Within this file you will find several options — here are the areas for adjustment:

[Recognition]
Include1=* (this allows you to name specific fonts to be included in the database build, * allows all installed fonts to be built into database to the maximum number defined in this file)
Include2= (additional position for inclusion of font names, can be left blank with no ill effect)
Exclude= (specific fonts to exclute, i.e. dingbats)
Italic=0 (0 will exclude italic characters from the database, 1 will include italic characters)
Bold=0 (0 will exclude bold versions of fonts from inclusion in the database, 1 will include the bold versions of fonts)
Underlined=0 (0 will exclude underlined versions of fonts, 1 will include)
Sizes=8-12 (defines the size range, can be maxed to 6-72)
Multicolor=0 (setting this to 1 will improve the performance of OCR in multicolor environments, but it will be slightly slower)
Multifont=0 ( allows for the recognition of character strings that switch font)
Line align=10
MaxNFonts=256 (setting for the maximum number of fonts, increases database build time, i.e. 4000)
Database Preload=0( if set to 1 the entire database loads into memory, using resources but improving performance)
Flip=1 (allows the recognition of upside down characters when set to 1)
MaxDepth=1 (how many colors allowed in font, 1=b/w)

Tips and Tricks — Refining the Test

Tuesday, September 15th, 2009

Often, we, as testers, are asked for the impossible.  Take, for example, the task of certifying a piece of software which has no defined — or very loosely defined — requirements.  I am not talking about the stories in Agile, but I am talking about the loose development style that typically starts in a meeting where someone says, “wouldn’t it be cool if..” and ends with a developer taking some time to write in the cool.

Requirements exist for a reason: they define the job. By the job I mean, the developer’s job, the marketer’s job, the customer’s job, and the QA department’s job.  Without the requirements being written and debugged (i.e. agreement on goals) there can never be a true SDLC.

As a tester, and a believer in the fact that software should be created to the highest quality standards, I would encourage QA to get involved in the process.  If there are representatives involved from the interested parties, Dev, Marketing, Mgmt, QA, and the customer, people’s needs are going to be met.  Not only that, but the ability to meet real — not perceived — needs will be enabled at a rapid rate.

So you need to get educated as to the goals of each interested party in the chain.   Know what development wants.  Know what management wants.  Know what your customers want.  Once you know the needs you can help to craft a requirement document that satisfies those needs and insures successful deployment.

WSDL Automated Functional Testing with SmarteScript

Monday, August 10th, 2009

Web services have become an integral part of many websites and products we have been called on to test. Testing the functionality of the application is still the straight forward method that we propose in our standard training–even if web services may require a small amount of harness building.

Service oriented applications may have data which extends beyond the display layer, such as messages which initiate a new process or procedure. Testing those messages without a back end, code driven tool can present quite a challenge.

Most testers just want to get to testing, and would like to avoid generating an application which has to be re written each time the process or data changes. To facilitate this, SmarteSoft currently recommends creating a simple form that accesses the WSDL from the server.  This simple piece of HTML will provide for the inputs as well as the outputs.  As this service page is created it will allow for both functional testing of the web service, as well as load testing.

The SmarteScript Virtual TE Keyboard

Wednesday, July 1st, 2009

Do you ever encounter a field–like username or password–that your developers have added security to?  One way we have seen this done is to disallow the pasting of information from the clipboard. To test for this, type your password (or username) into a text editor.  Select the password text, then try to paste it into your login page.  Now select another field.  Does you app accept the pasted data? If not there may be a security method preventing this method of data input.

When this is the case it is necessary to enter data “manually”.  By this I mean using keystrokes. For anything involving more than a couple of keystrokes this process is tedious, and it also means that you can use only one input word. This is unacceptable and there is a good way of working around the limitation created by security.

In SmarteScript you can do this by creating commands to strike individual keys. Thankfully, the application includes several commands/functions in a file called the init file.  Within this file is a command called virtual_TE_keyboard.  This function emulates typing the individual keys as opposed to pasting in the value.

To use virtual_TE_keyboard:

Create a variable for your input by right clicking on a window

Select add input column

Name the input column appropriately

Create a click command

Right click on the window name in the tree

Select add command

Select click object command

Fill out parameters for the object in question to left click on it

Create virtual_TE_keyboard command

Right click the window name

Select add command

Select init file commands

Select virtual_TE_keyboard

Select the window name

Input the variable for the input

This will allow you to create commands to input data via the keyboard where necessary.  The command will type the letters of the string it is passed and allow you to move forward with your test. The only caveat is that your data should not include special characters.

Moving Files

Tuesday, June 16th, 2009

Often in the course of testing a complex system, there is a need to move files about. SmarteScript has a built-in command called File Move, which allows you to easily move files around in the Windows system.

A secret to automation is to replicate the actions that you would normally take in the simplest form–don’t worry about bells and whistles, just get the job done.  In this case, there’s no need to test an FTP client just to move files.  Using simple dos commands allows you to easily accomplish complex tasks and call them from within a script.

For this exercise you will need to create a test file that you will save as a .bat file in a known location.  The structure of this batch file is governed by the specification of FTP as implemented in windows (additional information can be found at http://support.microsoft.com/kb/96269). For example:

———————–
open xxx.xxx.xxxx.xxxx

USERNAME

PASSWORD

lcd c:\

cd DIRECTORYNAME

get FILENAME

bye
——————–

To call this batch file you would use the SmarteScript command  Shell(DOS.”ftp -s:c:\\ftp.txt”).   The -s specifies a script that will be run and this is your batch file.  We would suggest playing with your batch file manually to insure it works well, every time, before including it in your automated test.

Example: FTP a file to the server

* Log onto the FTP server (see above)

* cd <pathname> – use this to CD to a directory on the remote computer

* lcd <pathname> – use this to CD to a directory on your local computer.

* bin – Turns on binary transfer.

* hash – Turns on progress.

* put <filename>  – This will FTP the file.

* debug – toggle debugging mode.

On a side note, this functionality opens up the world of batch files for any DOS based feature to automated testing.

Good luck and Happy Testing.