Our New Website is Live!

Monday, 11. August 2014 13:59

New Xceptance WebsiteWe proudly announce that Xceptance has a new website. Our 10th anniversary made us look back on where we are coming from, what we have been doing and what experiences we gained throughout the past ten years. It was time to have a new web presence reflect all that!

We took advantage of Bootstrap, Less, Jekyll, Git, Font Awesome, and Jenkins to create a website that primarily wants to help our visitors quickly learn about Xceptance, our services and our product. We wanted it to be modern but plain so that we can communicate what we do in the most comprehensive and user-friendly way possible. No boasting, no bragging, and just a little bit about ourselves. To have it all look nice and work smoothly for the mobile users as well, we used Bootstrap.

Since we’re always looking for new people that want to join us, we added a comprehensive jobs page which lists current open positions in both our offices, Cambridge, MA, USA and Jena, Germany.

Go check it out for yourselves! As always, we appreciate any kind of feedback!

Category: Misc, Software, Xceptance | Comments (0)

An Xceptional Storefront!

Tuesday, 10. June 2014 19:08

Xceptance Logo at the B59The B59, that’s the 16-story office building that accommodates the headquarters of Xceptance Germany, now has a new addition to its front. The red and black neon writing with Xceptance’s name and signature X was put up a week ago and thereby joins the logotypes of the Postbank and Allianz insurance.

The workers who installed the sign definitely had to be free from giddiness, since the sign overlooks the city of Jena from a height of approximately 98 ft. (30m). Several curious bystanders watched the installation process and were able to witness how, piece by piece, the name emerged on the wall.

So now, three years after Xceptance moved to the B59 office space, our flag is finally set. We think it’s been worth the wait!


Category: Xceptance | Comments (0)

We’ve Adopted the Word “Testen”!

Friday, 16. May 2014 18:20

WortpatenschaftThere certainly are things out there that money can’t buy, just like the Beatles once sang. However, you might agree with us that money can do good (things), if managed appropriately.

With the company anniversary in mind we at Xceptance sought to combine both the good deeds and a great company gift. That’s how we found out about the idea of a ‘Wortpatenschaft‘ (engl.: “word sponsorship”), a campaign dedicated to the preservation and promotion of the German language (in cooperation with the German nonprofit association Deutsche Sprache e.V., Dortmund).

People interested in the German language can visit their website to look up their favorite word and, this is the best part, sign up to “adopt” it. For a fixed donation you get to be the sponsor of a word (provided that nobody else has claimed it already), you receive a certificate for the sponsorship via mail and you can also have your name listed on the website next to your word. Their database not only consists of common German vocabulary but also rather quaint expressions or idioms like ‘Kokolores’ (engl.: gibberish) or ‘Mutschekiepchen’ (engl.: ladybug). The library is constantly growing since the platform accepts new suggestions, as long as they are valid German words or sufficiently Germanized expressions. Thankfully we did not have to propose our favorite word, and it also wasn’t taken!

As a QA company we did not have to think twice about which word to choose, it just had to be a term that means a lot to us, that describes our passion best and reflects what we’re good at. In one word: Testen (engl.: testing)! Now we are the proud owners of a pretty certificate, neatly framed and hung up in the hallway of our German office. A link to our company homepage next to the sponsored word also tells people how to find out more about the sponsor.

Category: Misc, Xceptance | Comments (0)

10 Years of Xceptance – The Story

Thursday, 8. May 2014 17:48

Ten years and 230 projects later it’s time to look back at the beginnings of Xceptance. Let us take you on a quick trip down memory lane!

The Story

In the beginning there was a small group of four colleagues who decided to take a chance and try something new. They pooled their resources, knowledge and QA experience and struck out on their own. The beginnings of Xceptance are thus all about passion and commitment and the belief in making software better.

The very first company meetings were held in the living room of one of the founders, lending the enterprise a definite ‘start-up feeling’. The business plan proposed adding just two people in the first five years, but that didn’t quite work out as expected because five years later more than 20 people worked for Xceptance, the majority of whom are still with the company to this day.

The Name

There are several anecdotes about the origins of the company name as well. The name ‘Xceptance’ is based on the term ‘acceptance testing’ which stands for a certain way of testing to make sure the requirements of a contract or specification are met. As obvious as that might sound, this wasn’t the first choice. Names of constellations, stars, and animals were all on the shortlist. (Un)fortunately the domains for those names were all taken, and that’s how ‘acceptance’ became the front-runner. For a fancier version the ‘a’ became an ‘x’; that turned into ‘Xeptance’, then ‘Xcceptance’, until someone suggested that just one ‘c’ might be enough. That is how ‘Xceptance’ was born.

The Office

After graduating from meetings in cafés, kitchens and living rooms, we had a stint in a shared office with a befriended company and then Xceptance moved to its new quarters in the center of Jena. Once again a shared office, but at this point with Demandware.

In those days people at Xceptance had to close ranks; there was just one relatively small office space for almost a dozen employees, but it worked out well and the company kept growing. As a result, people at Xceptance had to wrap up their equipment once again to move to the current location a few blocks away from the old office. The movers had been booked for the next day and everybody expected to spend one last day working in the old office. That plan, however, got monkeywrenched by the internet service provider who cut services at the old office a day early. The lucky Xceptance people had no choice but to pack their essentials themselves and schlep everything over to the new office.

The People

Eighty percent of the employees who started in the first three years are still with us. They’ve led Xceptance to today’s success, and their loyalty means a lot to us. But we also would not be where we are now without all our more recent hires. They ensure that the company’s head and heart are constantly in motion, always developing, never resting. Plus we’re always looking for talents with what we call the tester gene. Check our open positions in Germany and the US. We’re looking forward to meeting you!

The Tool

In the beginning of Xceptance, we did not have a performance testing tool. If a customer needed testing, we had to buy or license one. At that point, we were still a startup ourselves and we worked for startups, so money was short and all the good tools were just too expensive. So we decided to start our own tool chain, called ‘Yart’ back then, for ‘Yet Another Regression Tool’. Once this little hack proved to be useful and promising, we created a product development department around it and a little later XLT (which stands for Xceptance LoadTest) surfaced as our product offering.

Today XLT is a player in the test automation and performance testing space with many unique features, great flexibility, and results you can trust.

The Facts

  • 2004: Xceptance GmbH founded in Jena
  • 2006: Xceptance Inc. founded in the U.S.
  • 2007: Release of XLT 2.0
  • 2008: Release of XLT 3.0, Xceptance joins the blogging society
  • 2009: 5th anniversary of Xceptance Germany
  • 2011: Release of XLT 4.0, 5th anniversary of Xceptance Inc., Move to our current office in Jena
  • 2014: Release of XLT 4.3, 10th anniversary of Xceptance in Germany

As you can see, Xceptance has come a long way to offer you the best testing services possible! Ten years are an entire decade, but to us it feels like time just flew by and it was only yesterday that the business plan was first drafted. We hope to continue our hard work and we’d like to thank you, our clients and partners, for your confidence and support.

We’re looking forward to the next 10 years (at least)!

Category: Misc | Comments (0)

SQE training week in Boston

Friday, 25. April 2014 15:02

SQE Training TableAt Xceptance we think that “you live and you learn”, so we were eager to read about an upcoming training week by SQE in Boston (March 24-28). The various tracks had promising headlines like ‘How to Break Software: Robustness Testing Unleashed’ or “Testing Under Pressure” but we decided to pick our favorites and chose “Exploring Usability Testing” and “Mobile Application Testing”.

The usability training was scheduled for just one day, the mobile training for two. We knew that it would be tricky to fit an overview of usability testing in just one day of training, and it turned out the instructor was well aware of these concerns.

However, first came the Mobile Application Testing. We were a class of about 12 people, most of whom came in groups of two and worked for the same company. Our presenter introduced himself as a software security specialist, followed by the usual round of introductions of the participants. The majority of us already had a good knowledge of software testing in general, so we skipped that part and went further into our main topic. We were asked to open a site on our mobile devices that we had only opened from our laptop or PC so far, and to compare the sites and share the results with the class. This brought up some interesting and surprising insights; clearly there are companies out there that need mobile QA!

One of the next tasks we were given was to make up our own app, including the purpose and components. We used those apps in the course of the day for other tasks as well, so this was a key exercise. Our instructor gave us a lot of other exercises that day and the next, together with more information about mobile testing platforms, testing strategies, techniques and tools. Among the topics we learned about were approaches to mobile testing in general, and all the things you wouldn’t think of when testing desktop sites but that can make a difference for mobile applications, such as shaking the device, checking the impact of different networks, and varying screen resolutions among devices. We also discussed mobile testing platforms like SauceLabs and discussed the pros and cons of emulators and desktop browsers for mobile testing. All in all these two days of training were a valuable experience and provided new and useful ideas of how to tackle mobile application testing.

The usability class was a similar size, and all the other students came in groups of 2 or 3 from very large, well-known companies. In fact, as we introduced ourselves, it turned out the instructor had worked with every one of them, so only Xceptance was a new name to him. As already pointed out, one day was really too short, but the instructor did a remarkably good job of pulling out the highlights so that those participants new to the topic could walk away with a better idea of what “usability” is, while also touching on more in-depth aspects and providing us with additional resources so we could continue learning after the day was over.

First of all we talked about what “usability” even means; a helpful trio of “-bilities” comes from the ISO 9126 Quality Standard: learnability, understandability, and operability (since revised somewhat in the new ISO 25010, but still useful). But that’s only part of the battle: those are somewhat subjective impressions, and one person’s “understandable” could easily be another’s “incomprehensible”. Determining who a product’s users are, what they do with it, and in what context they do it is also critical. With those user types in mind, scenario-based testing based on “typical, real usage scenarios” help uncover the disconnects between what a product’s users need or expect it to do and what it actually does.

A discussion of usability heuristics, based on Jakob Nielsen’s work, followed; these are a very handy scaffold to build tests around. Finally, the instructor gave us an overview of how to organize and carry out a usability test, with some videos of actual tests he had done. The course material provided gave more information on other major areas, such as mobile, accessibility and safety testing as they relate to usability, but we didn’t have time to discuss any of these during the training itself. But as short as the class was, getting new ideas about how to describe, categorize, and prioritize usability issues was a valuable experience, and will help in advocating for bugs in future projects!

Category: Testing, Testing Culture | Comments (1)

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 | 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” and save your test cases.

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

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: Testing, Testing Culture | 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: Testing, Testing Culture | Comments (0)