(This is an older news post that has been migrated into the blog)
If you are a geek, you’ll find that our new 10.1 release contains what is probably the most exciting and highly anticipated feature to date: Advanced Scripting. This feature is targeted squarely at our core audience of system administrators, and is the start of a whole new level of flexibility and functionality.
What have we done? First, we added a script editor to the admin interface:
Browser based script editing
The first use of the new advanced scripting feature is to write print scripts – scripts that run when a new print job arrives. Your script can do a whole host of things including checking details of the job and influencing what happens to it. Some examples:
Displaying a pop-up message if a user forgets to select duplex on large jobs.
Showing statistics on the environmental impact on large jobs via a fancy popup dialog.
Prompting the user to confirm large jobs before printing.
Automatically routing large jobs to more efficient high volume printers.
… and much much more!
So what does an actual script look like? Something like this:
Example print script
The user manual contains a new Advanced Scripting chapter that will help to get you started. Happy scripting!
Welcome to the first 2010 PaperCut Vote for a Feature!
After the fantastic success we had we our last vote for a feature we’re going for another round! Our last Vote for a Feature Survey focused on Big Ticket items. This time we’re evaluating the “smaller items” that can have a big impact – the small little things that can help make your life easier as an administrator/user. The goal of this round of voting is to determine type of small features help out the most.
You can access the latest Vote for a Feature survey via:
Administration console -> About -> Product News.
PaperCut is considering sponsoring a public mailing list enabling all users to share ideas and innovative print management practices with each other. If you are interested in this please enter your email into the space provided in the survey.
When I first started as an intern at PaperCut in late November I didn’t now what to expect. As I first entered head office in Melbourne, I mentally prepared myself for all the usual mundane tasks that interns are inevitably assigned to (fetching coffee being at the top of the list). Now, being almost three months down the track, I can confidently say that my experience here at PaperCut couldn’t be any more personally and professionally fulfilling.
During my first two weeks at PaperCut I quickly realised that quality assurance was a BIG thing. Any new release candidate for PaperCut goes through a stringent testing process. For a period of time all development stops, and the whole team gets their hands on the newest version. We then go through a check-list of features to test, all of which must be tested on each supported operating system (Windows, Mac, Linux). Testing is no small thing here at PaperCut, it’s an intense process designed to catch as many bugs as possible in our print management software.
So, after I had settled in at PaperCut, Chris asked me to look into how we could increase the effectiveness and efficiency of our testing process. PaperCut has been using automated unit testing (testing of individual software modules) for a while, but Chris pointed me in the direction of automated functional testing. In affect, automating the manual testing described above.
Functional testing is the testing of the software as a whole. This form of testing provides benefits that are unachievable using unit testing. While unit testing is still useful for ensuring we don’t make any silly mistakes in small parts of of the product, functional testing is essentially simulating a user interacting with our software.
How is this all done? Over the past two months I’ve designed and written a framework that uses existing, mature software (including Selenium). I then used this functional testing framework to create scripts that simulate tasks that most users would do every day, syncing groups/users, editing printer properties, generating reports, performing printing.
It does this all by opening up a web browser and interacting with the user interface of PaperCut. It’s is completely automated, robust, and many times faster than any human. Below you can see a little demonstration of the testing at work, this test, which is one of dozens, is designed to generate every report and ensure that they successfully completed. This process was previously done “by hand” and took 30 minutes or more:
The automated testing framework is designed to help us accomplish two things; firstly, we don’t want to catch ‘most’ bugs, we want to catch all bugs. By reducing the potential for human error involved in our test processes, we increase the quality of testing. Secondly the speed at which these tests can be completed not only increases the amount of the application that we can test, but it means that the development team has more time to continue improving PaperCut.
This automated testing was used side-by-side with regular user testing, and unit testing, in the latest version 10 release, and will continue to be integrated into our standard testing procedures in the future. Automated testing was never intended to replace good old-fashioned manual testing, but it is my hope that it will allow us to provide an ever-increasing quality of service.