Skip to content

Feed aggregator

Announcing Our Winning Testers of the Quarter for Q2 2015!

uTest - Wed, 07/01/2015 - 18:37

First of all, I would like to thank everyone who participated in the voting for this quarter’s awards. We started this quarterly recognition program to give credit to members of our community who have excelled in their roles, and more importantly, added value to other members through the consistency and quality of their work. As […]

The post Announcing Our Winning Testers of the Quarter for Q2 2015! appeared first on Software Testing Blog.

Categories: Companies

End-to-end Hypermedia: Building a React Client

Jimmy Bogard - Wed, 07/01/2015 - 18:06

In the last post, I walked through what is to me the most interesting part of REST – the client. It’s easy to build a server API, but no API is complete without someone actually using that API. This is where most REST examples fall down for me – they show all sorts of pretty pictures of hypermedia-rich JSON from the server, but no real examples of how to consume that API.

I walked through some jQuery code in the last post, but why stop with jQuery? That’s so 2010. Instead, I want to build around React. React is perfect for hypermedia because of its component-oriented nature. A resource’s representation can be broken down into its components, and React components then matched accordingly. But before we get into the client, I’ll need to modify my sample to consume React.

Installing React

As a shortcut, I’m just going to use ReactJS.Net to build React into my existing MVC app. I install the ReactJS.Net NuGet package, and add a script reference to my downloaded react.js library. Normally, I’d go through the whole Bower/npm path, but this seemed like the simplest path to integrate into my sample.

I’m going to create just a blank JSX file for all my React components for this page, and slim down my Index view to the basics:

<div id="content"></div>
@section scripts{
    <script src="@Url.Content("~/Scripts/react-0.13.3.js")"></script>
    <script src="@Url.Content("~/Scripts/InstructorInfo.jsx")"></script>
        var href = Url.Action("Index", "Instructor", new {httproute = ""});
            React.createElement(InstructorsInfo, {href: '@href'}),

All of the div placeholders are removed except one, for content. I pull in the React library and my custom React components. The ReactJS.Net package takes my JSX file and transpiles it into Javascript (as well as builds the needed files for in-browser debugging). Finally, I render my base React component, passing in the root URL for kicking off the initial request for instructors, and the DOM element in which to render the React component into.

Once I’ve got the basic React library up and running, it’s time to figure out how we would like to componentize our page.

Slicing our Page

If we look at the page we want to create, we need to take this page and create React components from the parts we find. Here’s our page from before:

Looking at this, I see three individual tables populated with collection+json data. I’m thinking I create one overall component composed of three individual items. Inside the table, I can break things up into the table, rows, header, cells and links:

I might need a few more, but this is a good start. Next, we can start building our React components.

React Components

First up is our overall component that contains our three tables of collection+json data. Since I have an understanding of what’s getting returned on the server side, I’m going to make an assumption that I’m building out three tables, and I can navigate links to drill down to more. Additionally, this component will be responsible for making the initial AJAX call and keeping the overall state. State is important in React, and I’ve decided to keep the parent component responsible for the resource state rather than each table. My InstructorInfo component is:

class InstructorsInfo extends React.Component {
  constructor(props) {
    this.state = {
      instructors: { },
      courses: { },
      students: { }
    this._handleSelect = this._handleSelect.bind(this);
  componentDidMount() {
      .done(data => this.setState({ instructors: data }));
  _handleSelect(e) {
      .done(data => {
        var state = e.rel === "courses"
          ? { students: {}}
          : {};

        state[e.rel] = data;

  render() {
    return (
        <CollectionJsonTable data={this.state.instructors}
          onSelect={this._handleSelect} />
        <CollectionJsonTable data={}
          onSelect={this._handleSelect} />
        <CollectionJsonTable data={this.state.students}
          onSelect={this._handleSelect} />

I’m using ES6 here, which makes building React components a bit nicer to work with. I first declare my React component, extending from React.Component. Next, in my constructor, I set up the initial state, a object with empty values for the instructors/courses/students state. Finally, I set up the binding for a callback function to bind to the React component as opposed to the function itself.

In the componentDidMount function, I perform the initial AJAX call and set the instructors collection state based on the data that gets back. The URL I use to make the initial call is based on the “href” of my components properties.

The _handleSelect function is the callback of the clicked link way down on one of the tables. I wanted to have the parent component manage fetching new collections instead of a child component figuring out what to do. That method makes the AJAX call based on the “href” passed in from the collection+json data, gets the state back and updates the relevant state based on the “rel” of the link. To make things easy, I matched up the state’s property names to the rel’s I knew about.

Finally, the render function just has a div with my three CollectionJsonTable components, binding up the data and select functions. Let’s look at that component next:

class CollectionJsonTable extends React.Component {
  render() {
    if (! {
      return <div></div>;
    if (!{
      return <p>No items found.</p>;

    var containsLinks = _(
      .some(item => item.links && item.links.length);

    var rows = _(
      .map((item, idx) => <CollectionJsonTableRow

    return (
      <table className="table">
          containsLinks={containsLinks} />

This one is not quite as interesting. It only has the render method, and the first part is just to manage either no data or empty data. Since my data can conditionally have links, I found it easier to inform child components whether or not links exist (through the lodash code), rather than every component having to re-figure this out.

To build up each row, I map the collection+json items to CollectionJsonTableRow components, setting up the necessary props (the item, containsLinks, onSelect and key items). In React, there’s no event aggregator so I have to pass down a callback function to the lowest component via properties all the way down. Finally, since I’m building a collection of components, it’s best practice to put some sort of key on these items so that React knows how to re-render correctly.

The final rendered component is a table with a CollectionJsonTableHeader and the rows. Let’s look at that header next:

class CollectionJsonTableHeader extends React.Component {
  render() {
    var headerCells = _([0].data)
      .map((datum, idx) => <th key={idx}>{datum.prompt}</th>)

    if (this.props.containsLinks) {
      headerCells.push(<th key="links"></th>);

    return (

This component also only has a render method. I map the data items from the first item in the collection, producing header cells based on the prompt from the collection+json data. If the collection contains links, I’ll add an empty header cell on the end. Finally, I render the header with the header cells in a row.

With the header done, I can circle back to the CollectionJsonTableRow:

class CollectionJsonTableRow extends React.Component {
  render() {
    var dataCells = _(
      .map((datum, idx) => <td key={idx}>{datum.value}</td>)

    if (this.props.containsLinks) {
        onSelect={this.props.onSelect} />);

    return (

The row’s responsibility is just to build up the collection of cells, plus the optional CollectionJsonTableLinkCell. As before, I have to pass down the callback for the link clicks. Similar to the header cells, I fill in the data value (instead of the prompt). Next up is our link cell:

class CollectionJsonTableLinkCell extends React.Component {
  render() {
    var links = _(this.props.links)
      .map((link, idx) => <CollectionJsonTableLink
        onSelect={this.props.onSelect} />)

    return (

This one isn’t so interesting, it just loops through the links, building out a CollectionJsonTableLink component, filling in the link object, key, and callback. Finally, our CollectionJsonTableLink component:

class CollectionJsonTableLink extends React.Component {
  constructor(props) {
    this._handleClick = this._handleClick.bind(this);
  _handleClick(e) {
      href :,
  render() {
    return (
      <a href='#' rel={} onClick={this._handleClick}>
CollectionJsonTableLink.propTypes = {
  onSelect: React.PropTypes.func.isRequired

The link clicks are the most interesting part here. I didn’t want my link itself to have the behavior of what to do on click, so I call my “onSelect” prop in the click event from my link. The _handleClick method calls the onSelect method, passing in the href/rel from the collection+json link object. In my render method, I just output a normal anchor tag, with the rel and prompt from the link object, and the onClick event bound to the _handleClick method. Finally, I indicate that the onSelect prop is required, so that I don’t have to check for its existence when the link is clicked.

With all these components, I’ve got a working example:

I found working with hypermedia and React to be a far nicer experience than just raw jQuery. I could reason about individual components at the same level as the hypermedia controls, matching what I was building much more effectively to the resource representation returned. I still have to have some sort of knowledge of how I’m going to navigate the links and what to do, but that logic is all encapsulated in my topmost component.

Each of the sub-components aren’t tied to my overall logic and can be re-used as much as I want across my application, allowing me to use collection+json extensively and not worry about having to parse the result again and again. I’ve got a component that can effectively render a nice table based on a collection+json representation.

Next, we’ll kick things up a notch and build out a React.Native implementation, pushing the limit of hypermedia with a dynamic native mobile client.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Categories: Blogs

It worked on my machine – Communication Trap

Sauce Labs - Wed, 07/01/2015 - 18:00

“I don’t see it on my machine!” said every developer ever. Every QA professional I have talked to in my career has heard this at least once.

But why?

Have we asked what’s in a bug?

The answer can either be what gets your team on the road to efficiency, or it can become a kink in the delivery hose. Let’s discuss how your QA can help the team deliver faster by providing a consistent language to keep everyone on target.

Don’t Let The Bad Bugs Bite…

Over the last decade, I have seen issues that have almost no noted content in them (seriously, some have just declared something to the tune of “This feature is… not working”). Then there are tickets that are the golden standard, that have all the information you could possibly want (and probably some with more than you need that turn out to be a few bugs in themselves).

But what happens when you don’t have a common way to report a ticket, and why is it important?

I just came across an issue recently that seemed to have some steps to reproduce, but the setup was not included. Try as I might, I could not replicate the bug. The only way that I could come close to the reported result did not match the steps provided, and I could only guess that the setup I created was what the reporter had done. I will let you guess how long this issue took. Hint: It wasn’t a few hours.

Or perhaps you have an offshore team. I’ve seen many, many instances when someone reports a bug that just doesn’t have enough information in it. If the engineer cannot figure out exactly what the issue is, and has to place it on hold, back to the reporter, the engineer waits another night while the person on the other side of the world hopefully notices the ticket is back in his or her queue for more details. That is another full day that the bug exists, delaying when the root cause can be identified and the issue fixed.

Depending on the makeup of your team, and whether you are in an automated or manual setup — you need to consider how the issue will be verified. The person testing the fix (or writing the automated test to ensure the issue does not occur again) may not be the one who reported it. (Again, more time is spent figuring out how to test if the fix is correct.)

The bottom line? The back and forth that occurs from a poorly reported bug is costly in terms of time and resources.

Cut The Chit Chat

Having a uniform language/template will help reduce uncertainty across the board, and reduce the time a bug is spent unresolved. But what should be included in a bug report to cut out this back and forth, and keep the team on track?  There are several other things you may want to consider adding, but these are some of the top things I like to see from a tester:

  • Summary/Title: This should be succinct yet descriptive. I almost try to make these sound like a user story <user> <can/cannot><do x action> in <y feature>. When I sit in a triage meeting, can I tell what the issue is just by reading the summary?
  • Environment: every now and then we come across bugs that are very specific to the OS, database type, browser, etc.  Without listing this information, it’s all too easy to say ‘Can’t reproduce’, only to have a client find it in the field.
  • Build: Hopefully you are testing on the latest build, but if for some reason you have servers that are updated at different rates than others, you need to pinpoint when exactly the bug was found.
  • Devices: if you’re doing any type of mobile testing, what type of device were you using? What version? If you found a bug on the web app, do you see it on the mobile app too? Which one? Android or iOS?
  • Priority: The priorities are all relatively standard across the field — Critical, High, Medium and Low. Have criteria defined up front so everyone is on the same page as to what constitutes each selection.
  • Steps to reproduce: Not just ‘When I did this, it broke.’  Really break it down, from login and data setup to every click you make.
  • Expected Result vs. Actual Result: What were you expecting, and why?  What happened instead?
  • Requirements and Wireframes: This helps to point to why testing occurred, and why someone wrote up a bug and linked it back to the originating artifact, though hopefully you are on the same page upfront, before development begins. Sometimes things slip through and perhaps an engineer has a different understanding of a feature than the tester. Being able to point back to why you think an element is a bug is helpful, and gets you all on the same page.

Of course, there are people other than your traditional testers writing bugs, and it is essential to use your QA to drive conformity. Perhaps your UX team is performing audits, or you have bug bashes where people from other departments are invited to test the system and find bugs, or you have someone new to the team that simply needs training. Having a template will ensure clarity and reduce inefficiencies, regardless of who enters the ticket.

Utilize QA to promote consistency, get bugs out of purgatory, and drive faster delivery.


Categories: Companies

Code Dx Code Analysis Tool on Bitnami

Software Testing Magazine - Wed, 07/01/2015 - 17:40
Code Dx, Inc., a provider of a robust suite of fast and affordable tools that help software developers and security analysts find, prioritize and visualize software vulnerabilities, today announced the availability of its code analysis tool on Bitnami, a marketplace that makes it simple to find popular server applications and development environments and deploy them in just a few clicks. Code Dx is now standardizing deployment with Bitnami installation technology for Linux, Windows and Mac OS X. After one quick installation, users are able to automatically configure and run Code Dx ...
Categories: Communities

Keynote Adds Appium to Support Mobile Testing

Software Testing Magazine - Wed, 07/01/2015 - 17:29
Keynote has announced the integration of Keynote Mobile Testing with Appium, an open source framework designed to help automate the testing of native and web iOS and Android mobile applications. The new integration will allow organizations to improve the quality of apps by enabling efficient collaboration between quality assurance (QA) practitioners doing end-to-end testing and developers automating unit tests. By integrating Keynote Mobile Testing with Appium, developers and QA professionals can pair a high-fidelity interactive mobile testing environment with a common automated scripting test framework and run tests across real devices ...
Categories: Communities

NeoSense 1.1 Launched

Software Testing Magazine - Wed, 07/01/2015 - 17:04
Neotys has announced NeoSense 1.1, an enhanced version of its synthetic monitoring solution for application performance and availability. The release of NeoSense 1.1 adds powerful new capabilities for web and mobile applications to quickly create realistic monitoring profiles even for complex business apps using the latest technologies. The solution enables you to generate synthetic users in production and actively monitor the performance and availability of critical business transactions within recorded user paths to detect and automatically alert you of any issues before they become problems for real users. NeoSense 1.1 Key Enhancements Greater ...
Categories: Communities

Should Every Tester Learn To Program?

Gurock Software Blog - Wed, 07/01/2015 - 16:51

This is a guest posting by Simon Knight. Simon Knight works with teams of all shapes and sizes as a test lead, manager & facilitator, helping to deliver great software by building quality into every stage of the development process.


Sometimes, I like to think of my teammates as a kind of band of adventuring heroes. Usually, I don’t mention this to them, in case they start looking at me funny. But when I gaze across the room at the product owner, if I squint and use my imagination a bit, I can see a bit of Elf in her. Probably she’s handy with a bow and arrow. If she was a World of Warcraft character, I reckon she’d be a Hunter class; great at long range thinking and decision making.

Sitting next to me I have a Warrior class programmer. Master of the weapons of his trade. Capable of slaying a tricky line of code with a single blow. Myself I think of more as a kind of Shaman. I get to call on elemental powers, unleashing the primordial forces of skilled testing to support the team and help them deliver a great product.

Mostly I’m happy enough doing my thing. I’ve levelled up quite a bit. My spells have power and the team appreciate them. Every so often though, I’ll watch my warrior buddy slicing and dicing code and think, it would be great to carve a few lines myself. I’m not going to be a full time code warrior, so I don’t need a broadsword or a battle-axe, or anything heavyweight. My weapon of choice probably wouldn’t be an Oathkeeper. I’d prefer something with a bit more Sting.

Context Is King

There’s some solid arguments for learning a bit of programming swordplay. Being able to slice beneath the surface of the application code means you can better understand what’s going wrong, and why. Your bug reports will be better informed and the additional information you provide to developers when raising defects means shorter feedback loops.

Of course the software you’re working with comes in many shapes and sizes. And you don’t have to interact with it in the way the developers intended. If you’re working on a web application for example, operating the software while keeping a browser dev tools window open will provide you with a view of the client-side code and resources. Running your software through a proxy can help you to see what requests are being sent and received. Being alert to application behaviour by way of a logging or monitoring tool can help you see even further down the stack.

The nature of the software your team is working on is ultimately going to determine what tools (or weapons) will serve you best. Testing a web site is going to be very different to testing a native application, or a piece of embedded software. There’s a common thread though. Whatever kind of software you’re testing, the engine beneath it, the thing that makes it all hang together, is code. The software behaves the way it does because that’s the way the developers have programmed it to.

So given that, as a software tester, your job is to test software that’s driven by code – it makes sense to learn how to understand how code works, right? Well, you’d think. But it turns out, there’s some debate about this very subject. Not everyone agrees that testers should learn to write code.

“There’s some debate about this very subject. Not everyone agrees that testers should learn to write code.” – Simon Knight Tweet this quote


What’s All The Controversy?

If you follow some of the testing voices by way of their blogs and other social media, you may have come across arguments against learning to code like these:

  • Being able to code will make you think more like a computer and less like a person.
  • If you know how to code you’ll spend more time doing that and less time testing.
  • Learning to code comes at the expense of learning other, equally or more important skills.
  • Developers are better at programming anyway. Testers should focus on testing and let the developers write the code.

You’ll also see arguments in favour of learning to code, like these:

  • You’ll be better able to speak the language of your developers.
  • You’ll have a better understanding of the complexities and accompanying risks of development.
  • You’ll empathise with your teammates better when you understand the coding problems they face on a daily basis.

With all of this controversy around the subject, you could be forgiven for wanting to sit on the fence. But there’s more:

Anyone who is serious about a career in testing would do well to pick up at least one programming language. – Elisabeth Hendrickson

Back in 2010 Elisabeth Hendrickson carried out some market research and observed that 80% of the advertised testing roles they looked at seemed to require some kind of programming experience.

More recently, Rob Lambert speaking as a hiring manager notes that although there might once have been an argument for less technical testers who focused more on the big picture business scenarios, there are now plenty of testers who can write compelling test scenarios and develop the code to execute them as checks too.

It’s no longer enough to be a tester who doesn’t code, because when you apply for a job you may be up against a tester similar to you who can code. – Rob Lambert

If we take those last two points as arguably the most compelling reasons for learning a programming language or two, you’d think that life would become a bit clearer. You just need to make a decision about what programming language to learn and get on with it, right?

Wrong. Turns out, even that’s not straightforward.

What Does Learning To Code Mean Anyway?


Figuring out where to start learning anything can be tough. There’s so many choices! Should you go to college? Do an online course? Read some blog posts? Buy a book?

Learning a programming language can be particularly difficult. Before you start studying, how do you even know which language to choose? Figuring out answers to the questions below may help to narrow down your options:

What kind of work are you doing?
The software you test and the platforms it needs to work on may have a bearing on the kind of programming language it will be useful for you to know. If you’re working mostly on the client side of a web application, learning some Javascript might be more useful than learning some Java.

What does your code need to do?
Having a specific purpose or task that your code will be used for, in addition to being a great motivational tool for learning it in the first place, can be used to steer your decision about which language to actually learn. If you just need to create some data, a scripting language or some variety of SQL may be sufficient. If you need to develop a tool that’s intended to be a bit longer term, something more heavyweight like C# or Java may be required.

Where will your code be run?
Does your code need to work in a browser? On the server? On a desktop? In Windows, OS X and Linux? On a mobile device? The platform on which your code needs to be developed and run (or run against) should be a consideration.

What is everyone else using?
If you’re working on a team or project and everyone else is using C#, developing your scripts and tools in Ruby may not be the best idea. In addition to not wanting to upset folk, you want to take advantage of all of the experience and knowledge that’s around you, right? Find out what the preferred language of your colleagues is, and why. Then ask them for their advice and support in getting started with that language. Most often, they’ll be happy to provide it.

What skills is the market looking for?
Scanning job advertisements will provide a good indication of what skills are hot in the marketplace right now (as Elisabeth demonstrated back in 2010). You need to balance the ebb and flow of fashionable skills with longer term trends though.

Learning to Program


If you’ve chosen a programming language to get started with, you’ve cleared the first hurdle. It’s time to start developing those skills! The strategies below will help you on your way.

Talk to someone else who writes code
You’re probably already in one of the best places to learn programming; amongst developers! Go out of your way to talk to them and get them sharing their knowledge. Ask them to show you how their code works. Even better – sit with them as it’s being done. This way, you can add value by sharing your testing ideas while the code is still being written.

Look for examples of the same code in lots of languages
If you decide to read a book or some blog posts that provide typical examples, don’t just read code for the language you’ve decided to learn. Look at example code for other languages as well. Try to understand both the differences and the similarities so you can start to understand underlying patterns and principles.

Write some of your own code
Writing your own code will add depth to your understanding that simply can’t be achieved just by reading somebody else’s. And programming isn’t just about writing the code in any event. You have to setup your environment, familiarise yourself with the tools and carry out various other tasks along the way. There’s really no substitute for learning by actually doing the work.

Make changes and test them
Once you’ve gotten started with actually working through some examples, and hopefully got them working, start to make some changes. Apply your exploratory testing skills. Formulate a hypothesis, make a small adjustment, then observe the result. Look for ways to improve and optimise your code.

Learn to understand the compiler and debug your code
While you make changes you’ll probably experience some compilation or execution failures. The console will report an error of some kind, but do you understand what the error message means? Learning to search for reports of the same problem will be invaluable at this stage of your learning curve. Consider adding some logging to your code so that problems can be traced and pinpointed more accurately.

Look for things to do with your code
As your confidence grows and useful examples to learn from start to thin out, it’s time to start looking for ways to implement your learning at work. Mechanical activities that have to be repeated often are great candidates for code or scripted execution. But what about smaller, more ad-hoc tasks like data creation, extraction or manipulation? Try to think about ways you could carry out day-to-day tasks by writing simple scripts.

Store, share and re-use your code
As your portfolio of scripts and code grows, you’ll need somewhere to keep it all so you can refer to and re-use it. If you haven’t already done so, investigate some version control tools and code repositories. Git and Github are very popular (though other options are of course available) and Github makes it very easy to store and share your code with others.

Read someone else’s code
If you’re already working on a software project, why not download the source code and read through it? Many developers try to follow a test-driven approach to development, so unit tests are a great place to start. Some development tools will also let you step through the code as it’s being executed, which is a great way to see how it works in action.

Work on code somebody else wrote
Open source projects are a good way to start putting your new found skills to the test. Some of the software you use on a day to day basis is probably open source. Next time you use a tool, think about ways in which it might be improved? Join the mailing list for the development group or search the web for features under development and bugs that have been logged. Try to fix a problem in the source code or find some other way to contribute.

Practice, practice, practice!
If you want to get really good then you’ve got to keep putting in the work. It may not take ten thousand hours, but you should certainly expect to put in a significant amount of effort to become anything near competent. And even then, practice isn’t necessarily the same thing as experience. Professional developers solve all kinds of engineering problems on a daily basis. If you’re serious about learning to program, try to get some experience with production code. In these days of cross-functional teams, it shouldn’t be too hard.

Is Learning to Program Really Worth All The Effort?


There are many routes you could take towards becoming a highly skilled tester who is able to add significant value to the projects and teams on which you work. Leveling up your coding swordplay is just one of them. And one will that require significant time and effort.

So is it really worth it? Some people say that just learning to read code is enough.

“I advocate learning to read code over coding. Coding well can take a significant investment in time and practice.” – Alan Parkinson

Others argue that learning about programming (James Bach) or learning about IT (Patrick Prill) may be more valuable. These are all perfectly valid arguments, but learning about programming and IT is analogous to learning about swordplay and hand-to-hand combat.

Learning to read code would be like learning to read and predict an opponents movements in a fight. Useful skills to be sure. But not quite the same thing as being able to fight back.

The way that you learn how to handle a sword is by picking one up. Feeling the weight. Learning to swing, thrust and parry. Sparring against a real, live opponent once you’ve learned some moves. Learning to program is the same.

Reading a book or watching a few training video’s really won’t cut it. You need to sit at the keyboard and practice your moves, over and over. As you do so, your programming skills will start to emerge, and your understanding of what professional development looks like below the surface will grow.

This guide should get you started, but if you have some strategies that you’ve found particularly helpful in levelling up your programming skills, we’d love to hear about them in the comments section below.

PS: Have you found this article useful? We will have more relevant testing & QA related articles soon on topics like building a great testing team, improving your testing career or leveling up your testing skills. Make sure to subscribe below via email and follow-us on Twitter!

Photo credit: book and sign photos by Francois Schnell: here and here.
Categories: Companies

Are you ready for Black Friday? [What does performance disaster mean for you?]

HP LoadRunner and Performance Center Blog - Wed, 07/01/2015 - 05:38

Iblack-friday.jpgt used to be Black Friday was just for retailers...not anymore, it is now rolling across all industries and verticals, all customers are starting to expect some sort of offer / sale. As this has increased, so has the expectations for the performance of the digital commerce platform, the web site or mobile app related to end user experience, and of course the backend systems to be able to handle this increased load. Is your platform ready for Black Friday 2015, if not, what does performance disaster mean for you? Cloud Testing

Categories: Companies

What is the "Dark Side" of your apps?

HP LoadRunner and Performance Center Blog - Wed, 07/01/2015 - 05:33


We’re sure that you are very proud of the awesome app that you just developed but are you aware of its dark side? You’ve spent countless of hours creating your application and the last thing you want to do is to let your end users experience the dark side of your app first-hand.

Categories: Companies

GTAC 2015: Call for Proposals & Attendance

Google Testing Blog - Tue, 06/30/2015 - 23:11
Posted by Anthony Vallone on behalf of the GTAC Committee

The GTAC (Google Test Automation Conference) 2015 application process is now open for presentation proposals and attendance. GTAC will be held at the Google Cambridge office (near Boston, Massachusetts, USA) on November 10th - 11th, 2015.

GTAC will be streamed live on YouTube again this year, so even if you can’t attend in person, you’ll be able to watch the conference remotely. We will post the live stream information as we get closer to the event, and recordings will be posted afterward.

Presentations are targeted at student, academic, and experienced engineers working on test automation. Full presentations are 30 minutes and lightning talks are 10 minutes. Speakers should be prepared for a question and answer session following their presentation.

For presentation proposals and/or attendance, complete this form. We will be selecting about 25 talks and 200 attendees for the event. The selection process is not first come first serve (no need to rush your application), and we select a diverse group of engineers from various locations, company sizes, and technical backgrounds (academic, industry expert, junior engineer, etc).

The due date for both presentation and attendance applications is August 10th, 2015.

There are no registration fees, but speakers and attendees must arrange and pay for their own travel and accommodations.

More information
You can find more details at

Categories: Blogs

Anarchy In Arkham; Multi-Platform Testing Is a Bare Minimum For Gaming

uTest - Tue, 06/30/2015 - 21:36

One of the endearing traits of the video game sector is that when it identifies an ongoing revenue stream, it makes sure that it milks that cash cow to death. Irrespective of the genre  – sports, fantasy, action, shooters, massively-multiplayer-online-first-person-shooter, fantasy-fighting, role-playing, strategy to name just a few – developers and publishers now want to […]

The post Anarchy In Arkham; Multi-Platform Testing Is a Bare Minimum For Gaming appeared first on Software Testing Blog.

Categories: Companies

The Rules I Live By

Testlio - Community of testers - Tue, 06/30/2015 - 17:01


  1. Sleep enough.

Make sure you are getting the rest you need. So you can work hard at the things that really matter, with the people that really matter. That source of energy allows you to not only welcome a challenge but overcome it.


  1. Tell the ones you love that you love them. Over and over and over again.

There isn’t a person in the world that doesn’t enjoy hearing the words “I love you” or “You matter to me”. When someone matters so much, let them know. You never know when it will be too late to tell someone what they mean to you. Why not do it now, and tomorrow, and the next day.


  1. Show appreciation everywhere you can. Even the seemingly small places.

Gratitude. Be grateful for the things you have. Count your blessings. When a person can truly appreciate the things they already have, they open themselves up to all other incredible experiences life has to offer. Express appreciation and gratitude with the slightest touch, a smile to a stranger, a kind word, an honest compliment, or a tiny act of caring.


  1. Eat healthy, but not too healthy.

Take care of your body, its the only one you get. But allowing yourself to indulge every once in a while is also a requirement. You only get one body but you also only have one life.


  1. Cookies are good for the soul.

There’s nothing more that needs to be said with this one. This rule is undebatable.


  1. Be true to you.

Authenticity is a gift. Be who you are at your core. Always, no matter what, especially when it’s not the easy thing to do. Stand up for the ideas and people that matter. It can be extremely difficult to take a stance on something you believe when it seems everyone else is going in the opposite direction. But these moments allow your true character to shine through. These moments are your chance to prove what kind of person you are and what kind of person you want to be. Be someone that inspires others.


  1. Laugh

Laugh as often as possible, too often, and so hard that you throw your head back and almost pee in your pants.


  1. Listen

Listen with full attention. Show that you care. Show that you want to connect. Listen, not only for your turn to speak, but to understand.


  1. Learn

Exercise your mind in every way imaginative. Explore it. Challenge it.

Engage in a constant quest for knowledge and truth. Keep your mind active, curious, and hungry.


  1. Lead with Compassion

Be a sense of comfort for as many people as you can in your lifetime. Everyone is going through something.


Connect with Michelle here

The post The Rules I Live By appeared first on Testlio.

Categories: Companies

Fighting Technical Debt: Memory Leak Detection in Production

Thanks to our friends from Prep Sportswear who let me share their memory leak detection story with you. It is a story about “fighting technical debt” in software that matured over the years with initial developer’s no longer on board to optimize/fix their code mistakes. Check out their online store and browse through their pages […]

The post Fighting Technical Debt: Memory Leak Detection in Production appeared first on Dynatrace APM Blog.

Categories: Companies

Free Web Load Testing Services

Software Testing Magazine - Tue, 06/30/2015 - 09:00
The software development trend that shifts the target platform from the desktop to web, cloud and mobile applications has fostered the development of load testing services on the web. It is an obvious option to use web-based load testing tools for applications that can be accessed by web users. This article presents the free offers from commercial web load testing services providers. We have considered in this article only the tools that provides a load testing service that we define as the ability to simulate the access by multiple users on ...
Categories: Communities

As Jenkins Grows Up, We Invite Our Business Partners To Grow With Us.

As I am writing this post, CloudBees reached a milestone in the number of employees. I think the milestone hit many of us by surprise. “Really,” we thought. “So soon?” But if you look back over the past couple of quarters, it’s pretty apparent that our internal growth was inevitable.  
The number of Jenkins deployments is rapidly rising. At last measure, there are more than 100,000 active installations of Jenkins running. And, as enterprise companies deploy more and more Jenkins, the need for enterprise-grade solutions are accelerating at a very similar rate. A recent blogby CloudBees CEO Sacha Labourey discusses how organizations are transforming their use of Jenkins as a Continuous Integration (CI) tool to using it as a platform to bring enterprise-wide Continuous Delivery (CD). And as our customers have matured their deployments, so have the solutions and offerings from CloudBees, including the most recent launch of CloudBees Jenkins Platform.
The fact is… we are growing. And as we grow, our partners- resellers, services providers, training partners and technology partners- will all play an increasingly critical role delivering the enterprise-scale Jenkins solutions and complimentary tools and platforms our joint customers are seeking.  
Which is why we are committed to equipping our partners with the skills, resources and tools to help you get the most from the opportunity that Jenkins offers. Next month, CloudBees will announce new developments in our Partner Program to meet the needs of our growing partner ecosystem and to help all maximize the vast opportunities Jenkins presents. All current or potential partners- including global resellers, service providers and training partners are invited to attend our informational webinar on July 16 at 11 am ET. This presentation will provide an overview of the latest product developments and expanded opportunities available to partners to help grow your business through enterprise-scale Jenkins solutions.
We look forward to sharing these exciting developments with you next month and working with you to uncover new opportunities, deliver the latest in Jenkins innovations and solutions to our joint customers, and expand your business.

Durga SammetaGlobal Alliances and Channels

Durga is Senior Director of Global Alliances and Channels and is based in San Jose.

Categories: Companies

Book Review: Managing Humans - Mon, 06/29/2015 - 21:31

I remember hearing about Managing Humans several years ago but I only got around to buying it and getting through reading it.

Managing Humans

It is written by the well-known Michael Lopp otherwise known as Rands, who blogs at Rands and Repose.

The title is a clever take on working in software development and Rands shares his experiences working as a technical manager in various companies through his very unique perspective and writing style. If you follow his blog, you can see it shine through in the way that he tells stories, the way that he creates names around stereotypes and situations you might find yourself in the role of a Technical Manager.

He offers lots of useful advice that covers a wide variety of topics such as tips for interviewing, resigning, making meetings more effective, dealing with specific types of characters that are useful regardless of whether or not you are a Technical Manager or not.

He also covers a wider breath of topics such as handling conflict, tips for hiring, motivation and managing upwards (the last particularly necessary in large corporations). I felt like some of the topics felt outside the topic of “Managing Humans” and the intended target audience of a Technical Manager such as tips for resigning (yourself, not handling it from your team) and joining a start up.

His stories describe the people he has worked with and situations he has worked in. A lot of it will probably resonate very well with you if you have worked, or work in large software development firm or a “Borland” of our time.

The book is easy to digest in chunks, and with clear titles, is easy to pick up at different intervals or going back for future reference. The book is less about a single message, than a series of essays that offer another valuable insight into working with people in the software industry.

Categories: Blogs

EventFiringWebDriver, WebDriverEventListener, and AbstarctWebDriverEventListener

Testing tools Blog - Mayank Srivastava - Mon, 06/29/2015 - 17:36
Before getting into the sample code, lets have a look on EventFiringWebDriver, WebDriverEventListener, and AbstarctWebDriverEventListener descriptions. EventFiringWebDriver is a class and wrapper around an arbitrary webdriver instance which supports registering of a WebDriverEventListener. WebDriverEventListener is interface which includes list of abstract events methods and all should be implemented if we are implementing it. AbstarctWebDriverEventListener is abstract class which […]
Categories: Blogs

Moving Away from Legacy Code with BDD

Testing TV - Mon, 06/29/2015 - 17:28
Greenfield projects are awesome – you can develop highest quality application using best practices on the market. But what if your bread actually is Legacy projects? Does it mean that you need to descend into darkness of QA absence? Does it mean that you can’t use Agile or modern communication practices like BDD? This talk […]
Categories: Blogs

One Mock Too Far

Software Testing Magazine - Mon, 06/29/2015 - 17:23
Tests should save our money and time. How is it that they often become the stumbling block and slow down the work? They fail every time you try to do some refactoring and are difficult to maintain ultimately increasing the cost of software maintenance. If you have such problems it means that you may have gone a “one mock too far ” – testing the wrong things, and you using mock in the wrong places. During my talk I will give examples how to test different types of code wisely so ...
Categories: Communities

Defining Your Role as a Tester

uTest - Mon, 06/29/2015 - 16:57

Recently, I have found myself focusing less on the quality of an organization’s products from a tester’s perspective. At this point, I find myself more and more in the role of helping organizations see the larger picture: How are they set up? What causes conflicts? How does the structure of the organization help build better quality? […]

The post Defining Your Role as a Tester appeared first on Software Testing Blog.

Categories: Companies

Knowledge Sharing

SpiraTest is the most powerful and affordable test management solution on the market today