We continue to share cool things with the community of software testers and developers. Today we are announcing the availability of our no coding test suite for XLT under the Apache License v2.0.
You want to fire just a couple of URLs to load test your application? You have to investigate the performance problems of a feature and you need accurate measurements as well as a lot of load generated? You like XLT and its capabilities, but you don’t have the time to compile a sophisticated test suite from scratch? Whatever your motivation, our new test suite for XLT is the solution you are looking for. Continue reading TestSuite-NoCoding – Load Testing with CSV Files→
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→
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→
When discussing possible load test setups with our clients, we usually need to refer to these key terms: visits, sessions, requests, hits, page impressions, and page views. Actually, we don’t need to discuss all of them, but some are occasionally brought up by the customer, some are requested by us, depending on the context (and complex enough to be discussed in a separate article). Continue reading Terms explained: Visits, Page views, Sessions, Requests, Hits→
Many projects have their closed or “won’t fix” bugs commented with remarks such as:
“Won’t happen on live system”, or
“This is just a data issue”.
Both the development of new features and data maintenance may be accomplished in different environments. For testers, it’s thus difficult to decide on the cause for a certain issue: is a required text missing because pages aren’t implemented the right way or is it simply not there because the corresponding product data aren’t available in this particular test system? Very often testers work on development systems without having access to latest data. The following is a typical scenario:
Testers report a bug.
The development resolves this bug as content-related and won’t fix.
Testers report further bugs of that sort.
The development gets irritated: “We’ve told them that these are content issues!”
The relationship between testers and developers might really go downhill from there, seriously threatening the project’s success: the credibility of the test team is damaged, developers don’t take reported bugs seriously anymore, testers get overly cautious and stop reporting content-related problems…
Inevitably, potential bugs don’t get reported and reported bugs never get retested before the project goes live. This is even more true in poorly managed projects because no one really feels responsible to solve this problem.
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.
By clicking Opt-Out, we will place a non-personalized cookie on your machine that indicates that you don‘t wish to be tracked.