Web Drivers in XLT: Basic Access Authentication

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.

HTTP Authentification IE
HTTP Authentication IE
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

Release Xceptance LoadTest 4.2.8

XLT_transparentWe just released a minor XLT update that brings you an improvement and a fix.

  • Script Developer: Mouse events dispatched by SD use target element coordinates now.
  • Load Test Environment: The result target directory can now be specified on the mastercontroller command line.

As always, this release update is free of charge and you can download it here: XLT Release 4.2.8. Do not forget to sign up to our release email list. To purchase licenses and support, please visit the XLT Portal.

XLT is free for up to five virtual users for load and performance testing. Regression testing usage is always free of charge.

Terms explained: Visits, Page views, Sessions, Requests, Hits

Terms explained: Visits, Page views, Sessions, Requests, Hits
Image © Juja Schneider

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

Blog Performance – We Kicked it up a Notch

Usually, we just  measure the performance of our customer’s applications and talk about it, but from time to time we have to set an example ourselves.

In the last couple of weeks, we increasingly felt that our blog isn’t loading fast enough to deliver a satisfying experience. You know that when you can feel it, it might be too late already. Additionally, SEO is about content and performance and our blog is an important marketing tool for us.

That’s why we went on a quest for improving the performance of our company’s WordPress-based blog. Our motto: “Don’t just complain about the lack of performance, do something about it!”

Step 0 – Measuring

Our initial blog performanceMeasuring is believing and so we started with this WebPageTest result. As you can see, the initial performance is bad, a lot of content is not properly cached, and rendering started after 2.6 sec. Time for some serious tuning.

Step 1 – Reading

Tuning requires you to know what to tune. Thus, we read the famous Best Practises for Speeding Up Your Web Site by Yahoo. A similar article by Google can be found here. If you deal with web site performance in any way, you should read this. We consider it mandatory for performance and web testers.

Continue reading Blog Performance – We Kicked it up a Notch

This is Just a Data Issue


Image © Juja Schneider

Many projects have their closed or “won’t fix” bugs commented with remarks such as:

  • “Content-related issue”,
  • “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:

  1. Testers report a bug.
  2. The development resolves this bug as content-related and won’t fix.
  3. Testers report further bugs of that sort.
  4. The development gets irritated: “We’ve told them that these are content issues!”
  5. 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.

Continue reading This is Just a Data Issue

WebDrivers in XLT: Test Case Design that Compensates for Inconsistencies across WebDrivers

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.

Time: Enlarging time properties can prevent timing problems with dynamically loaded content, like iframes or page content added with JavaScript. Script Developer lets you set an ‘Implicit Wait Timeout’. It allows to specify how long the test should wait for a command to fail while trying to find elements.

Continue reading WebDrivers in XLT: Test Case Design that Compensates for Inconsistencies across WebDrivers

Release Xceptance LoadTest 4.2.7

XLT LogoXLT 4.2.7 has been released. It delivers improvements as well as defect fixes. We recommend to upgrade as soon as possible to stay up to date.

Script Developer

  • Fix: Obsolete entries from the base url drop down can be removed now.
  • Improvement: With special characters in the link name, the Script Developer sometimes recorded an XPath locator instead of the more appropriate link locator.

Load Test Environment

  • Fix: Custom samplers stopped working for the rest of the load test when an exception was thrown. Now the sampler continues to run.
  • Fix: The Mastercontroller used a previously entered comment when the current comment was left empty.
  • Improvement: The Mastercontroller returns non-zero exit code for all error conditions now.

Framework

  • Fix: HtmlUnit did not sent the basic HTTP authentication header for follow-up requests correctly, only when challenged again.

Of course, we are providing a set of fresh Amazon Machines Images as well. You can find all information on our product page. Make sure you stay informed by subscribing to our XLT release email list.