As a software tester, an episode such as the one below must be more than familiar to you and, let’s be honest, it has the potential of making the top ten of the most annoying things in our daily work routine:
Pain in the neck: “Hey, I need more email addresses for testing, I just burnt all my own.”
You: “Well, just use a fake one.”
P: “Nah, I can’t, I need the activation emails.”
Y: “Well, then, there are good disposable mailers out there.”
P: “Very clever, but they aren’t protected by authentication and I signed an NDA for that project.”
Y: “Here, use this one.”
P: “But it wants to have a real email to sign me up and I don’t really feel like giving my real email away.”
Granted, it’s a matter of course that committed testers have many email addresses but what’s the use of them when you’re always limited to a certain number, when you can’t quickly change them, or deactivate them when an email service got hold of them? Continue reading XCMailr – An Open Source Test Mail Forwarder→
Today’s article can be seen as a survey reflecting our thoughts on web test automation in general. It basically lists personal experiences that we were able to gain in customer projects or conclusions that we arrived at in recent discussions on this topic.
Are you familiar with someone asking you to do things such as putting all of your clients into the new CRM or inserting 80 new users in a software product x? If so and if your software has no import feature, you probably found yourself copying and pasting all day long. A simple way to save you from this torture is using a UI automation tool like Sikuli Script.
What is Sikuli?
Sikuli automates UI functionalities like mouse, keyboard, and clipboard actions. It works with UI recognition to identify UI components such as buttons, input fields, or menus. To use this kind of recognition, Sikuli compares the actual screen with screenshots from the user. Continue reading Simplify Your Life With a Little UI Automation→
We received a lot of positive feedback on introducing our sample test automation suite for Demandware SiteGenesis. Have a look at the original post containing a video tutorial and all information you will need to get started.
It’s our intention to keep the test automation suite up-to-date, so it covers new and additional features of SiteGenesis. The latest update for version 13.3 of SiteGenesis contains the following improvements:
Support of the new multi-ship feature of SiteGenesis
Better independence of SiteGenesis product data
Stability improvements to make the test suite much more stable with reference to timing issues
Support for testing in Chrome and Firefox remotely without Script Developer
Introducing of ANT support for easier integration into build automation
Today’s article of our WebDrivers series deals with HTTP authentication – a topic that, at first sight, seems to be very specific and of minor relevance. However, in the world of software testing it’s way more important than you’d think. Often you will have an additional testing instance of a website to be tested. These instances are protected from abuse which is why they require credentials before you can access them. See below for an example in Internet Explorer:
This browser dialog appears just once. If you’ve entered the right credentials, you can access the related website as often as you like without further authentication – as long as you don’t reopen the browser. The latter is a critical issue for automated WebDriver testing. Continue reading Web Drivers in XLT: Basic Access Authentication→
Still remember the first post of our article series? It talked about how you can run XLT test cases in different browsers. If you’ve done so already, you might have noticed that the behavior of test cases developed in Script Developer sometimes differs depending on the WebDriver you’ve chosen. This article is meant to help you resolve such issues.
First of all, what’s the reason for these inconsistencies? Web browsers differ in their characteristics, such as site representation or functionality, due to their varying support of web technologies like CSS or HTML. You probably know that there is much more we could list, but the major point is pretty obvious already: using WebDrivers for test case execution calls real browser instances. Logically, you’re faced with the same differences as in real web browsers. It’s impossible to achieve a completely consistent web browser behavior; yet you can design your test case as outlined below to at least reduce the differences.
Have you heard of XLT Script Developer yet? If you have, you’ll probably agree that it’s a convenient tool to record and run automated test cases. However, with it being a Firefox plugin, you’re basically bound to run your test cases in Firefox. Wouldn’t it be nice to reuse Script Developer test cases in multiple browsers? You can actually do so by taking advantage of the WebDriver API that is part of the XLT framework.
You have to work with HP Quality Center (HPQC), but you don’t want to execute all the test cases manually. You automated some tests using XLT Script Developer and like the outcome. You want to use the Script developer much more but you face one last problem: You still have to enter the test results manually into HPQC. This renders some of the test automation advantages useless.
When Google+ brought the community feature online, we immediately knew, that could be it to get testers together and discuss test automation, learn from each other, and share knowledge. Google+ gathered a more technical crowd compared to Facebook and so we will give it a try.
By clicking Opt-Out, we will place a non-personalized cookie on your machine that indicates that you don‘t wish to be tracked.