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→
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
Measuring 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.
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.
XLT 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.
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.
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.
By clicking Opt-Out, we will place a non-personalized cookie on your machine that indicates that you don‘t wish to be tracked.