Xceptance it is!

Wednesday, 2. April 2014 6:00

Acceptance, huh? Be honest, you almost thought we were being serious about this whole name change! But, as convincing as it might have sounded, we’re not going to abandon our fancy company name, ever!

Despite the uncommon spelling we like our quirky label and the way it usually triggers follow-up questions. It is recognizable and fun and, once you got the hang of it, it sticks. We also trust in SEO and the sanity of our customers so that we don’t feel like there’s a reason to worry much about it. Of course there’ll always be the issue with auto-correction, but we think we can handle that. Having said this: Xceptance it is!

Category: Misc | Comments (0)

Xceptance becomes Acceptance

Tuesday, 1. April 2014 0:01

New Logo AcceptanceJust in time for our 10th anniversary, we are pleased to announce that the company is going to change its name from Xceptance to something more tangible and easier to pronounce: Acceptance.

With that, we are reacting to the release of a search engine list containing the different versions of the search term users entered to find Xceptance online. Terms reached from “Xcaptence” to “Ecceptance” and even “Axceptacne”. To us, this list was some kind of a wake-up call because we no longer want to take the risk of losing clients just because of a fancy company name. That’s why we decided to settle for this easier to google, user-friendly name because, after all, a company name should represent the company it stands for. An additional benefit of the new name: the auto-correction of mail and office software will never put a red mark on the company’s name again.

Within the coming week we’ll update the website and all other company-related content with the new name and logo. For our current clients and affiliates there won’t be any changes.

Category: Misc, Things went wrong | Comments (0)

Use XLT with Sauce Labs and BrowserStack

Wednesday, 12. March 2014 18:13

Sauce Labs and BrowserStack – What Are They and Why Use Them?

Sauce Labs and BrowserStack allow you to run automated test cases on different browsers and operating systems. Both provide more than 200 mobile and desktop browsers on different operating systems. The benefit? You can focus on coding instead of having to maintain different devices. You can easily run your test cases written on iOS on an Internet Explorer without actually buying a Windows device; and last not least, you don’t need to worry about drivers or maintenance.

By the way, Internet Explorer even seems to run faster at Sauce Labs than on a desktop machine. Also note that Sauce Labs supports Maven builds.

What You Need

Not much, really. Only a Sauce Lab or BrowserStack account, a Java IDE (e.g., Eclipse), and XLT 4.3.2.

How to Do it

First, import your XLT test suite into the IDE (Eclipse). Then import all .jar files from the XLT lib directory into your project. In the XLT Script Developer options menu, check “Generate JUnit wrapper class for test cases”.

You then need to “Export…” a test case (select “XLT Scripting API” as API) to generate a new wrapper class so that you can place your new code for the WebDriver in it.

Add the statements below to the exported Java code. Here you can choose your browser (Android, Safari, Firefox, Chrome, Internet Explorer):

DesiredCapabilities capabilities = DesiredCapabilities.firefox();

Now set the desired version of the browser:

capabilities.setCapability("version", "19.0");

Set the operating system on which you want the test case to run:

capabilities.setCapability("platform", Platform.LINUX);

Give your test case a name so that you can refer to it later:

capabilities.setCapability("name", "XLT Firefox Test");

Now you can set up a new WebDriver. Replace “xxx” by your user name and “yyy” by your access key for Sauce Labs:

Webdriver driver = new RemoteWebDriver(
    new URL("http://xxx:yyy@ondemand.saucelabs.com:80/wd/hub"), capabilities);

With this piece of code you should be able to run your test cases on the Sauce Lab servers. This also works to for manually written classes. Just use the same WebDriver settings.

For BrowserStack, you can use the following commands:

DesiredCapabilities caps = DesiredCapabilities.firefox();
caps.setCapability("browser", "FireFox");
caps.setCapability("browser_version", "22.0");
caps.setCapability("os", "Windows");
caps.setCapability("os_version", "7");
caps.setCapability("browserstack.debug", "true");
driver = new RemoteWebDriver( 
    new URL("http://" + USERNAME + ":" + 
        AUTOMATE_KEY + "@hub.browserstack.com/wd/hub”, caps);

Some Final Notes

Selenium works best with Chrome and Firefox. Other browsers, like Internet Explorer or Safari, may fail on test cases that, in fact, do successfully run in Chrome or Firefox. Some websites have a different layout for mobile than for desktop. So you probably can’t use your default tests. If you want to write tests for mobile devices with XLT Script Developer, install user agent changer and change your user agent to iPhone 3.

Sauce Labs provides a detailed tutorial which describes all functions of the service, like parallel testing and other cool stuff. We definitely recommend you read it in case you have any questions.

Category: Automation, Java, Software Development, Testing, XLT | Comments (1)

Why do women make good software testers?

Wednesday, 5. March 2014 21:04

The answer to this question is fairly simple: women make good software testers if they’re good at testing. And so do men. There would be no reason to go into this any further if it weren’t for the occasional blog posts that pop out here and there, carrying headlines like ‘Are women better testers than men?’ or ‘Is software testing women’s work?’ (if you don’t believe that, go ahead and ask Google!). We are aware that this is a tricky topic, and bringing it up usually seems to imply that sexism and discrimination are just around the corner. But instead of jumping right at it and listing possible skills that may or may not make women better testers (who hasn’t heard of ‘multi-tasking’, ‘emotional intelligence’ or ‘an eye for detail’?), we’d rather tell you about our own experiences.

At Xceptance we just think our team is great the way it is. There are women and there are men, and everyone contributes to the company’s success in their own way. Our employees do a great job listening to customer requests, they passionately discuss appropriate testing strategies and they sometimes make phone calls while simultaneously updating browser versions on testing devices and formatting the latest bug report. Some of our employees love snowboarding in their free time while others like cooking and crafts, and we can assure you that there is nothing gender-related about all that. So if there are more women than men in software testing, that’s great! But it doesn’t mean anything besides those bare statistics.

Image by kevinshine under CC-BY-2.0Of course now you could ask: if gender doesn’t matter, why make a blog post of it? Admittedly, that is a good question. But with all those articles out there about women in software testing and the accompanying stereotypes we just felt like we’d have to take a stand and outline our own opinion. We’re not big fans of the ‘you say it best when you say nothing at all’ attitude, so we figured we could as well go for it. And with all of the above being said, there’s just one thing we have to confess: every year on March 8th all of our female employees receive a chocolate treat in honor of International Women’s Day.

Photo by kevinshine under CC-BY-2.0.

Category: Misc, Testing | Comments (0)

Another Six Things You Should Never Say to a Software Tester

Wednesday, 19. February 2014 17:20

Inspired by this UTest article 6 Things You Should Never Say to a Software Tester, we came up with additional six comments a software tester does not really like to hear:

But it works on my development machine!

We don’t doubt that, really. But a sandbox is called a sandbox for a reason. It’s a playground, a simulation of reality, with its own rules and regulations. Kids fight about sand castles first before moving on to arguing about real estate in the grown-up world, so please throw away your shovel for a second and join us in the real world!

You broke it.

“No, I didn’t!” – “Yes, you did!” – “NO, I DID NOT!” and so on… That was me and my friend in kindergarten, at the age of 4. The toy was in pieces and none of us could (or would) recall whose fault it was. And it didn’t really matter at this point. The more important question was how to hide the broken thing from the teacher to avoid any unpleasant consequences. Once we had figured that out, we were done with the argument and started working together. A good example for how you can learn from past mistakes.

Your test report says you executed all of the test cases, so there won’t be any new bugs from now on, right?

“You’ve eaten all the pasta, that means you’ll never be hungry again, right?” – If you think this is an absurd example, read the third statement again. See the analogy?

You’re testing e-commerce sites? Oh, so you’re basically shopping online all day long?

Yes. And no. I don’t need 100 luxury bathrobes embroidered with profanities, and I also don’t want them. I also don’t have a second home in Hawaii and I know that entering incomplete billing information won’t take me to the next step in checkout. And yet I simulated all these scenarios while testing. Testing an e-commerce site is different from ordinary online shopping, especially since the term “ordinary online shopping” has yet to be defined. Am I the grandmother who just got an iPad for Christmas and is now looking for bargains? Am I the hipster who is annoyed by all the promotions that are thrown at him while he just wants to get his shopping done? Is the website prepared for the most challenging checkout attempts? It is our job to find that out, and it has little to do with “online shopping”. Though I did try to pay my last purchase at the farmer’s market with a test credit card, but that’s another story…

I see your point, but it’s not a requirement.

So it’s not a requirement that the password field should be cleared out after submitting the form? Instead of treating the documentation as a bible, we’d appreciate the use of common sense more often. We know that there’s the tight schedule and the even tighter budget and that those things don’t allow for many extras. But, believe us, a password that floats around unattended on a page is not an extra, but it can hit you hard when it comes back to you later.

This is no longer a bug, please see the updated requirements.

This is even worse if it comes along with the previous statement. It should not be an acceptable solution to turn a defect into a requirement. If it happens and the alleged bug turns into a butterfly, that is if the requirements change, please! let! the! testers! know! We don’t like to spend our time hunting fake bugs, therefore we need to know about any updates as soon as possible. And yes, this also includes design changes!

What else comes to your mind?

Category: Links, Software Development, Testing | Comments (0)

XLT 4.3.2 is available

Friday, 7. February 2014 23:36

Xceptance has released version 4.3.2 of its load testing and test automation product Xceptance LoadTest. This is an improvement and bug fix release. More information about this release can be found in the release notes.

Script Developer

  • Improvement: Support for Firefox 27.
  • Improvement: Usability improvement when sorting test data entries or module parameters.
  • Improvement: Native platform line endings are used when exporting Java code now.
  • Improvement: Script migration errors are now written to the log panel instead of to messages boxes.
  • Fix: No error message anymore when two scripts have the same name but are located in different packages.

Result Browser

  • Fix: Query parameters were incorrectly parsed because the fragment (#…) was included.

Framework

  • Fix: WebDriver features were not exposed when WebDrivers were reused.

EC2-AMIs with Java 7

  • eu-west-1 : ami-3650a641
  • us-east-1 : ami-d33a01ba
  • us-west-1 : ami-5ef4c91b
  • us-west-2 : ami-ce97f4fe
  • ap-southeast-2 : ami-fd0c92c7

Category: XLT | Comments (0)

TestSuite-NoCoding – Load Testing with CSV Files

Monday, 20. January 2014 9:36

Our test suite on GitHubWe 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.

Introduction

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.

It lets you define a test by editing a CSV file. You can start by replaying prerecorded URLs; later on, you can spice up your definitions by adding validations, random data, data from data providers, or data from previous pages.

Features

  • Reads test definitions from CSV files
  • Supports data validation
  • Allows two modes to run tests
    • DOM mode, that is you can use xpath to verify and get data (HtmlUnit parses the responses into a DOM)
    • Lightweight mode which means no DOM overhead, just plain HTTP and HTTPS traffic, and very low resource consumption
  • Cookie handling is automatic
  • Static content can be handled automatically or specified manually
  • Does not disable any XLT features

Documentation

You will find the documentation on the GitHub page as part of the README. Additional documentation is provided as part of the test suite itself, because we added a set of example test cases and their respective CSV files that run against the famous Pebble example (part of the XLT download).

So make sure you check out the main example CSV: tauthor.csv. Its header presents most of the possible features, while the CSV line show you how to grab data from the returned data and pass it to the next request as part of the parameters.

In case you only want to test something simple that does not require data to be passed from one request to another, you can go with just these lines:

URL
http://justahost.org/
http://justahost.org/foobar
http://justahost.org/foo/bar
http://justahost.org/send?foo=bar

Get it and fork it

Our test suite is available on GitHub under the Apache License V2.0. So feel free to use, modify, or share it. We appreciate your feedback as much as any code or pieces of documentation you would like to share.

Happy load testing!

Category: Automation, Open Source, Testing, XLT | Comments (0)

Xceptance Releases XLT 4.3

Thursday, 9. January 2014 18:23

Xceptance released version 4.3 of its load testing and test automation product Xceptance LoadTest. It features a wide range of improvements and new functionality.

As always, this update is free of charge for every user. You can use XLT freely for your daily automation work, regression testing, and performance validation. If you are an eligible Open Source project, you can get a full XLT license for your load and performance testing needs for free as well.

Script Developer

Enjoy more automation with less clicking. The new information panel summarizes the specifics of the currently selected item, so you do not need to open it anymore. Additionally, the new log panel lists all executed commands and their respective parameters.

If an element is styled with the CSS property text-transform, then the element’s text on the screen may have different character casing from what is defined in the page’s DOM tree. The WebDriver specification mandates to return the text as shown on the screen. Script Developer will now record text with the the character casing that appears on the screen and it will also take the CSS property text-transform into account when replaying text assertions.

Reporting

The XLT load test reports have been improved by adding more charts and data details, such as overall statistics for all timers. Arrival rate charts have been added to visualize the load development over time and make sure the desired load factor was reached.

Charts can now optionally be configured to be logarithmic. A capping can be added to hide larger spikes, which usually make charts hard to read, without removing the important information altogether.

The new networking section summarizes all general network-related statistics and charts on a separate page.

The error and event page has been redesigned and includes a new error chart that contains separate graphs for all transactions/actions/requests so that the temporal distribution of transaction/action/request errors is displayed in one chart. A new error summary table groups all errors by their error message to help you see which types of errors occurred and how many of them.

Load and Performance Testing

The master controller features two new commands to validate the availability of agents and  display their current configuration. A new command line option permits the skipping of result downloads when XLT is used as a load generator only.

Framework Extensions

A set of new commands is available in Script Developer and in the framework: commands such as assertAttribute, assertStyle, assertClass, assertEval, and their matching store and wait equivalents.

XLT can now send and receive IDs as part of the request to ease the correlation of server-side logs and test results. XLT may send a randomly generated alphanumeric ID as request header or extract such an ID from an arbitrary response header.

When dealing with different test environments, different load profiles, and/or different test data at the same time, managing different combinations of configuration settings can be challenging. The new property file include feature makes it easier now to predefine aspects and reuse them later in different configurations without copying and pasting.

When a test case reads a certain setting from the configuration, the framework uses a fallback strategy when doing the property look-up. This strategy performs an additional look-up step now, based on the transaction name (the short name to which the full class name is mapped). This additional step lets you parameterize different transactions differently, even if they are mapped to the same class and therefore share the same code.

The webdriver that will be used when executing functional tests can now be configured via properties. This allows greater flexibility and hardcoding is not necessary anymore.

When XLT executes XML script test cases with a WebDriver instance that is capable of taking screenshots, it can take a screenshot after each action, if desired.

Result Browser

New Result Browser UIA new look matches the overall styling of reports. Also, the navigation bar can now be resized, requests are color coded to visualize the content type, and the first page is displayed automatically. URLs are now active links, so you can click them easily.

If needed, the content of a response can be beautified for certain content types (HTML, JavaScript, JSON, CSS). This includes formatting and syntax highlighting.

Misc

  • XLT is shipped with an empty test suite project that can be used as a template for your own projects.
  • HtmlUnit has been upgraded to version 2.12.
  • WebDriver/Selenium has been upgraded to version 2.39.0.
  • EC2 admin console permits setting a tag name now.

Amazon Machine Images

The Amazon Machine Images (AMI) listed below are available for public use. Using these images is free of charge, but require that you own an Amazon Web Services (AWS) account. Please make sure that your EC2 security group permits communication on port tcp/8500. AMIs with Java 6 are no longer provided.

  • eu-west-1 : ami-ceae46b9
  • us-east-1 : ami-2510394c
  • us-west-1 : ami-e4ccfca1
  • us-west-2 : ami-9ebadeae
  • ap-southeast-2 : ami-617be45b

If you need XLT-AMIs in Tokyo, Singapore, or Sao Paulo, please let us know.

Purchase Licenses and Support Online

Licenses and support can be conveniently ordered through our XLT Self Service Center. You can instantly download licenses and purchase support right when it is needed. All your invoices and previous licenses (when purchased online) are accessible at any time.

We will notify you before your license or support runs out, so that you will never miss that again. This enables you to continue your daily automation and load testing work without interruption. Please note that we do not renew your contracts automatically, so no strings attached.

Visa and MasterCard are accepted. All credit card data is processed and secured by Wirecard.

Where to get it

More information about this release, the Quick Start Guide, and the Manual can be found in the release area. The full XLT 4.3.0 package can be downloaded here.

This upgrade is free of charge for everyone.

Category: XLT | Comments (0)

Link: The critical rendering path

Friday, 3. January 2014 16:25

pagespeed-renderingpath

If you care about web page speed, that is the information you have to memorize first.

The most important concept in pagespeed is the critical rendering path. This is true because understanding this concept can help you do a very wonderful thing… Make a large webpage with many resources load faster than a small webpage with few resources.

Since most webpages have many different components, it is not always possible to just remove everything to make a page load faster. If you have ever wondered “What else can I do to make my pages fast?” or “How does Google expect pages to load in one second?” then this concept is for you.

Continue reading: http://www.feedthebot.com/pagespeed/critical-render-path.html

Category: Links, Performance | Comments (0)

Tutorial: Git – The Incomplete Introduction

Tuesday, 1. October 2013 18:29

Software Testing is part of software development. So you need a form of revision control for your source aka test code, and documents. You also need it to be able to review code, compare the history of code… or maybe simply to help others to master it.

We recently started our migration from Subversion to Git. Not because we have been unsatisfied with SVN, mostly because we want to use what our customers use. Additionally we want to profit from the different functionality Git offers, such as local commits and cheap branching.

But Git is different and just changing the tool does not change anything, it might even turns things worse. Because you cannot run Git like SVN. Well, you can, but that still requires you to know the basics of Git to understand what it will do to your work and how a typical workflow looks like. The commands are different too.

So we created this tutorial to get used to Git, understand, and learn it. It starts slow with the basics, explains some terms and concepts, and later picks up speed when it talks about rebasing and merging. Everything is explained with commands you can execute quickly in your own test project. Command line rulez!

Not everything is explained of course. Basically what you don’t need to know to master Git has been intentionally left out. Google it or immerse in the official documentation, if you need to know.

So enjoy the tutorial, use it, copy it, share it. The entire presentation is licensed under Creative Commons by Attribution Share-Alike. Our way of saying “Thank you” to the Git open source community.

You can download the Libreoffice document if you want to modify it, take things out, or simply go with a different style: GIT-the-incomplete-overview.odp. Fonts are embedded, so that hopefully works ok.

If you prefer the easy way aka the PDF, you can download it right here as well: GIT-the-incomplete-overview.pdf.

Category: Misc, Open Source, Software Development | Comments (0)