To read more about our CBT program please click here. To see it demoed, please click here.

So: What do you think? Let us know by emailing our sales team.

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)

On the other hand, plovers clean the teeth of crocodiles, and shrimp clean the grunge off of fish, and all benefit. Crocs and fish welcome these hygienists and leave them unharmed.

IT consultants would prefer to be thought of as plovers. And indeed, most of the time, they provide a beneficial service to their customer and are rewarded with something in return. The greater the benefit relative to the cost, the more in demand their services are likely to be.

However, what happens if the consultant is faced with a situation where they can greatly enhance the benefit to the customer, but with negative short-term consequences for the themselves? This presents them with something of a dilemma.

I was recently reminded of this phenomenon when chatting with the lab director at the QA Center of Excellence for a very large, global consulting firm. (So as not to embarrass anyone, let us call him Fred.)

Fred told me that initially, when they heard our claims about ~5x faster implementation and ~10x faster maintenance, and all of the other benefits we touted, he thought we were full of it — just another vendor over-hyping their products.  But, he had been directed by his boss to check us out, so he had his team set up the lab and run our stuff through its paces.

Fred’s team came back to him and said that while there is variability in the efficiency gains to be had depending on what is being tested, the experience of the test engineer,and so forth, by and large our claims checked out.
Fred then advised his company’s local practice managers of this, sharing the results of the evaluations. He expected to get a lot of questions and excitement, but instead he received … silence.

This puzzled him, so he called around the practice managers.

Some were just too busy and hadn’t read or digested the message, others didn’t have any immediately pending projects and had filed his report for future reference, some were scared to use anything they had never used before.But a couple who had read it and had near-term needs showed little interest. When Fred asked why, he was told that improving efficiency by a significant margin would lead to fewer consultants for a shorter period of time for a test automation project, negatively impacting short-term sales of their consulting services.

So what was best for the customer was bad for the consulting firm.

Or was it ?

Fred and I discussed this, and we talked through some scenarios, as follows:

-     Imagine you are quoting around $250K for a project while your competitors submit bids of $500K or so. Who would the client select ? And when the project is done on time for the stated price, who is going to have pole position for that client’s next project? And who will the client recommend to their circle ? Long term, all other things being equal, your business increases as you blow away the competition on value.

-     In the above example, there may be a lower short-term revenue number, but what about margins ?  If your cost is now $125K instead of $400K, and you bill $250K instead of $500K, you win a definite $125K profit versus a potential $100K profit. Factor that across multiple projects and the fact that you win more projects than before due to lower prices, and your bottom line is greatly improved, and, your customers are also reaping the benefits. Eventually, your competitors would catch on and use the tools that give them the efficiency gains, then the usual margin squeeze would be in, but in the meantime you increase margins, win more projects, and reduce costs for your clients.

This is germane to a truism of business: Do the right thing for your customers and they’ll do the right thing for you. Not always, but usually.

As business people, we all have a choice. We can be plovers, benefiting our business associates and gaining some benefit ourselves. Or we can be ticks, trying to reap maximum gain for ourselves with little regard – and perhaps even negative consequences – for those we do business with.

To all you plovers out there – thank you, and I hope to work with you one day.

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.

There are a number of reasons why this wall was there but, for the most part, it persisted thanks to the very different ways in which design engineers and test engineers then approached their job. As a result, the way in which such accompanying technologies as simulators and programmable test equipment worked echoed the split between design and test. These differences were of course driven by the specific needs and focus of each test environment, a situation which resulted in test data being structured completely differently for designers than it was for testers.

To this day, this difference in mind-set and the way test data is represented persists, but the SemiCon industry has realized the value of design-to-test re-use and has found ways to bridge this gap. The result?  An entire support industry that specializes in technologies designed to convert test data from the formats used by design engineers to a format that can be used by test engineers. This conversion is often an extremely complex task, but tools and methodologies have evolved to the point where re-use of design test data by test engineers is the norm throughout the industry, and has resulted in dramatic savings in test engineering costs and reductions in time-to-market for products that are often characterized by an extremely small market window.  While the wall is still very much intact for now, the results seen here still represented a dramatic, positive shift in the way technology firms view the separation between design and test. As such, it should serve as an example for the high tech sector.

At SmarteSoft, we’re taking the lessons learned in the semiconductor industry and applying them to the wall that divides software development teams from the QA folks who test their applications. With such revolutionary products as SmarteStudio (look for a full release in September) and the forthcoming SmarteScript 6.0, our clients will find themselves suddenly able to integrate development and QA, cutting both costs and time to market, thus improving their ROI. In ten years this may well be the norm. For now, you can only find such revolutionary implementation here.

To read the full report please visit the Gartner homepage.

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.