Since my last post on functional testing, KSM has been hard at work transforming the ideas from that post into a new product and service offering. Toffee (“Test Orchestration for the Enterprise”) allows QA professionals to build and execute automated tests in an interactive, online test environment, without requiring programming expertise. For those test cases that automation cannot easily reach, Toffee lets you include manual test steps in your scripts alongside automated ones. Automated screenshots capture your entire desktop, providing evidence for steps whether executed within or outside of the browser. Test results for both automated and manual tests are presented in a familiar step/expected result/actual result format, along with screenshot evidence.
Toffee started as a command-line based solution, which allowed us to focus on the syntax and scope of the Toffee command set. We used this first incarnation to test solutions we developed in house. The largest test suite achieved 100% automation with over 28,000 test steps, and completely replaced the Selenium tests we had written in Java.
On the trade show floor of the Society of Quality Assurance Annual Meeting last week, KSM previewed the next generation of Toffee, called Toffee Composer. Composer provides the same level of functionality as the initial version, but in a user-friendly web interface. Build your scripts, execute them, and store your results online, either in our cloud-based environment or in your own data center.
For more information about Toffee, visit http://toffeetesting.io. We would be happy to schedule an online demonstration for you; just send us an email at email@example.com.
KSM Technology Partners LLC is seeking solutions-focused professionals who enjoy using technology to solve complex, open-ended business problems. A KSM Consultant develops custom application and integration software for our clients in the pharmaceutical and utilities industries. The ideal candidate is a multi-disciplinary professional with 2+ years of experience writing great code in multiple languages, eliciting and documenting requirements, and designing and executing thorough unit and functional tests. Our consultants work in small, cross-functional, hyper-productive teams that deliver business value quickly and with a minimum of overhead.
Our offices and many of our clients are located in the greater Philadelphia area, particularly in the route 202 corridor in the western suburbs. Telecommuting is occasionally available for some engagements. We prefer local candidates.
This is a full-time position; we are not a body shop looking for subcontractors. We offer a competitive salary, flexible working hours, paid time off, healthcare and long-term disability coverage, and 401K with a generous match and no-wait vesting.
We will not consider candidates presented by agencies or other third parties. Applicants must be able to work unrestricted in the U.S.
If you are interested, email us at careers [/at/] ksmpartners [\dot\] com.
If you’ve never played it before, a hand of manual testing misery poker plays out something like this:
“It took six of us eight weeks to plow through a three and a half foot stack of system test scripts”
“That’s nothing. Our site acceptance testing alone took fifteen of us three months for a six-foot stack.”
“But were yours double sided?”
“Then what took you so long?”
“Screenshots every step”
“Oh. I fold.”
We automate functional testing for a reason: the alternative is tedious, resource-intensive, and expensive. So why do test suites still comprise so many manual tests? Continue Reading…
In my last post I wrote that the reality of automated functional testing has so far failed to live up to my expectations. In this post I’ll define what I mean by functional testing. What follows might not be the definition you’re familiar with, and I don’t mean to suggest that this is the only valid definition. It is certainly influenced by the industries I work with, where:
- The subject of functional testing is a black box
- The standard of functional testing is the set of functional requirements
- The evidence of functional testing formally links test cases to those requirements they test
From my first encounter with HTMLUnit over ten years ago, I had high hopes for automated functional testing for web applications. Comprehensive test suites would run continuously and unattended, and notify us promptly of incipient problems. We would dazzle our customers and quality auditors with slick, comprehensive, and electronically signed hypertext reports. We would dispense with hundreds of person-hours of manual testing, and pass the cost savings on to our customers. We would retire waist-high piles of paper test scripts and reports to long term storage and, after the obligatory retention period, dance around the bonfire where they burned. Continue Reading…
A friend recently invited me to compete in a shooting match where the targets are hardened half-inch steel plates. Speed counts: the faster you hit them all, the better your score. I had only ever practiced on paper bulls-eye targets and an occasional tin can lineup, and I never shot for time. To me, shooting required careful aiming and controlled squeezing, and lots of trudging to mark or replace the target. I enjoyed what I called “target practice” for at most 20 minutes at a time, but I wasn’t sure I could blow an entire Saturday at it.
I understand it now: it’s the nearly instantaneous, oddly musical, and immensely satisfying sound of lead striking steel. I have a new hobby.
The best developers love short code-to-test cycles. They obsess over the performance of their compiler and test framework. They divide their code base into smaller sub-projects that build independently. They consider code-to-test speed when choosing languages, frameworks, and application servers. They fight like cornered rats for their own dedicated full-stack environment, including a local application server and data store. To reduce startup and redeployment times, they strip both the application server and the data store down nearly to the metal, and they build lightweight unit tests that require neither. They can deploy and test their code in seconds.
They build their own equivalent of what shooters call “reactive targets.” Continue Reading…
We are pleased to announce the formation of the Greater Philadelphia Amazon Web Services User Group (GPAWSUG). This user group is intended to be a collaborative community of AWS end-users sharing knowledge and real-world experience. All are welcome, including, but not limited to devOps professionals, developers, DBA’s, big data wranglers, and IT executives. The organizers will schedule bi-monthly presentations of interest to both AWS novices, and experts. Presentations both critical of, and favorable to, AWS products are welcome.
The group’s online home is found on Meetup.com. Members will be given early access to event seating for future events, and can participate in the group’s online discussion forums and (at their option) mailing lists. The group’s charter explains the grass-roots philosophy that guides the selection of presentation topics and the rules of engagement. To summarize: this is a private members-only group, the membership list is not to be used for marketing, and no product vendor presentations are allowed (excepting, on a limited basis, Amazon itself, as with the inaugural meeting).
The inaugural meeting of the group will be held on Thursday, September 19, 2013 from 5:45 PM to around 7:30 PM (EST) at Villanova University. Sanjay Kotechas from Amazon Web Services will discuss how to integrate AWS’ data warehousing product, Redshift, into your solutions.
Light dinner fare (a sandwich bar) will be served.
You need not join the Meetup.com group to attend the meeting, but you must RSVP using EventBrite.
Amazon Redshift is a fast and powerful, fully managed, petabyte-scale data warehouse service in the cloud. With a few clicks in the AWS Management Console, customers can launch a Redshift cluster, starting with a few hundred gigabytes and scaling to a petabyte or more, for under $1,000 per terabyte per year. Continue Reading…
KSM Technology Partners is pleased to announce the alpha release of Ernie, an open source asynchronous report generator based on the Eclipse BIRT framework. You can find it on GitHub at https://github.com/ksmpartners/ernie. There is also an Ernie support forum on Google Groups for the community to ask questions and offer feedback.
For developers, Ernie provides both Scala and Java APIs for:
- building and maintaining a catalog of reusable BIRT report definitions;
- running parameterized reports asynchronously to create jobs;
- interrogating the status of enqueued jobs; and
- accessing report results in PDF, CSV, or HTML format.
For integrators, Ernie provides a JEE .war implementation that can be deployed standalone, and controlled via a RESTful API. Continue Reading…