Skip to content

Feed aggregator

Dynamic Testing According to ISO 29119 the Subject of Software Testing Book Excerpt

uTest - Wed, 10/15/2014 - 19:00

As testers, you know that software testing is a critical aspect of the software development process. A new book aims to offer a practi804Hasscal understanding of all the most critical software testing topics and their relationships and interdependencies.

The Guide to Advanced Software Testing (second edition) by Anne Mette Hass, published by Artech House, offers a clear overview of software testing, from the definition of testing and the value and purpose of testing, through the complete testing process with all its activities, techniques and documentation, to the softer aspects of people and teams working with testing.

Practitioners will find numerous examples and exercises presented in each chapter to help ensure a complete understanding of the material. The book supports the ISTQB certification and provides a bridge from this to the ISO 29119 software testing standard in terms of extensive mappings between the two.

The full version of the book is available for £75 (USD $119) from Artech House, but testers will be able to receive an exclusive 20% discount off that list price, plus free shipping, by using promo code EUROSTAR14 at checkout, valid through December 31, 2014.

In the meantime, you can check out our exclusive chapter excerpt right here. This specific sample provided by Artech House clocks in at a generous 30 pages, and its subject matter should be quite familiar to many testers, covering the recent, controversial ISO 29119 testing standard and its associated dynamic testing process.

Categories: Companies

Coverity Scan, Application Security and Open Source

The Kalistick Blog - Wed, 10/15/2014 - 16:44

We have just upgraded the Coverity Scan service to Coverity 7.5. With this upgrade, we’re now enabling Coverity Scan members to utilize Coverity Security Advisor to help them eliminate security defects in Java web applications.

Since Heartbleed, GoToFail bug and recently the shellshock, we have aimed to provide the latest technology that will enable open source projects to be more secure and address the most critical OWASP Top 10 issues. Our analysis algorithms cover about 34 CWE. In addition to XSS and SQli, were able to address CSRF, Hard coded credentials and more. In fact, in our latest Coverity Scan Security Spotlight we found more than 680 OWASP Top issues in open source projects.

The Coverity Scan service is built for open source developers as such you should expect low false positive rate and advanced remediation advice.

There’s a strong need for increased awareness security in open source software.  In a visit to OSCON (the Open Source convention), I was surprised to see the security track was nearly empty. I hope to see more organizations like the Linux Foundation arise, but eventually the open source evangelist community will need to take action to bring awareness to the issue.

In other conference news, at Black Hat in August, the show seemed mostly to be a commercial and an enterprise game. I noticed Codenomicon, (the company that discovered Heartbleed) was talking about open source and security, but I didn’t see many others taking it on. For Scan, we also added a new algorithm that checks for issues like Heartbleed.

On a side note, we have seen a substantial uptick of interest in the OpenSSL project. Since Heartbleed, the project has fixed 221 numbers of defects – with special thanks to Neel Mehta, who took the lead working with the OpenSSL team.

I am still wondering how Open source projects will handle security. When I compare open source with a typical Coverity commercial customer I see a gap. The gap is easily described in budget, people and compliance requirements. Every large company typically has a security application team. This team buys tools mostly oriented toward security auditing, and they also drive compliance requirements such as PCI and others. In more advanced companies these teams are more of enablers to the many developments teams rather than security auditors that provide defects to developers.

However I don’t observe a similar team or some other formal way in which the Open source community tackles security. There are a few forward thinking individuals who are doing a great job like Dave Jones (Linux) , Michael Rash or Neel Mehta for Open SSL but can that scale?

The post Coverity Scan, Application Security and Open Source appeared first on Software Testing Blog.

Categories: Companies

Webinar: Managing ISO 26262 Compliance with TestTrack

The Seapine View - Wed, 10/15/2014 - 16:23

Managing ISO 26262 imgIn today’s cars, many safety features that once were purely mechanical are now carried out by software and electronics. Add in luxury features like navigation systems, automatic parking, and driverless technologies, and the amount of code in a modern vehicle can climb to over 100,000 lines — making compliance with ISO 26262 standards ever more complicated to manage.

Discover how TestTrack can help in our live webinar on October 29 at 1 p.m. ET. Andrew Horner, Seapine Solutions Specialist, will demonstrate TestTrack ability to cover the entire development lifecycle prescribed in ISO 26262.

During the demonstration, Andy will introduce the new TestTrack Automotive project template. All webinar attendees will receive a free copy of this valuable template, which includes:

  • Pre-defined item types for product requirements, system and component specifications, safety goals, and hazard mitigations among others.
  • Built-in calculations for ASIL based on an item’s severity, exposure, and controllability classification.
  • Automated linking between all item types to ensure end-to-end traceability from design to test.
  • Traceability reporting to monitor requirements coverage, analyze the impact of proposed changes, and assess safety integrity levels across systems and components.
  • A flexible workflow that supports multiple development methodologies including V-Model, Waterfall, Agile, and hybrid techniques.

Register today for the Managing ISO 26262 Compliance with TestTrack webinar!

Share on Technorati . . Digg . Reddit . Slashdot . Facebook . StumbleUpon

Categories: Companies

The Ins and Outs of Writing an Effective Mobile Bug Report (Part II)

uTest - Wed, 10/15/2014 - 15:30

Be sure to check out Part I of Daniel Knott’s articleimages on effective mobile bug reports for further context before continuing on.

Here’s the rest of the information you should plan on including in every bug report.

Network Condition and Environment

When filing a mobile bug, it’s important to provide some information about the network condition and the environment in which the bug occurred. This will help to identify the problem more easily and will possibly show some side effects no one has thought of.

  • Bad: “No information” or “Happened on my way to work”
  • Good: “I was connected to a 3G network while I was walking through the city center.”


If your app supports several languages, provide this information in your bug report.

  • Bad: “No information”
  • Good: “I was using the German language version of the app.”

Test Data

This information can already be provided in the steps taken to reproduce, but test data you need to reproduce the bug may be more complex, so it makes sense to provide this information in a separate section. Provide SQL dumps, scripts or the exact data you entered in the input fields.

  • Bad: “No information”
  • Good: “Find the attached SQL script to put the database in the defined state” or “Enter ‘Mobile Testing’ into the search input field.”


Every bug you find needs a severity level. Either your defect management tool will offer you some categories or you have to define them with your team. It is important to give a bug a severity level as it will allow the team to prioritize their bug fixing time so that critical and high priority bugs will be fixed first. If this information is not provided, it takes much more time to find the right bugs that need to be fixed before the release. The default severities are: Critical, High, Medium and Low.

  • Bad: “No information”
  • Good: “Critical” or “Medium”

Bug Category

Besides the severity level, the bug category is also a very useful piece of information. The product owner or the developer can filter by category to get an overview of the current status of bugs per category. For example, if there are lots of UX bugs, this may be an indicator of poor UI and UX or a missing design expert in the team, meaning that the app needs design improvements.

  • Bad: “No information”
  • Good: “Functionality” or “UX” or “Performance”

Screenshot or Video

Whenever you find a bug, try to create screenshots or a video to provide the developer with more information. When providing a screenshot, use an image editing tool to mark the bug in the screenshot (Jing, for instance). A video is also a great way to describe a bug you’ve come across. It is also very useful to give the screenshot or the video a good name or description.

  • Bad: “No screenshots or videos attached” or “Screenshot1.png”
  • Good: “01_InsertSearchTerm.png, 02_SearchResultPageWithError.png”

Log Files

If your app crashes or freezes, connect the device to your computer and read out the log files. In most cases, a stack trace will be shown with a description of the error. This kind of information is extremely useful for developers as they know right away in which class the bug or the error has occurred.

  • Bad: “No information provided when the app crashed.”
  • Good: “Provide the full stack trace in the bug report” or “Attached the log file to the report.”

Tester Who Found the Bug

Write down your name or the name of the tester who found the bug. Developers or product owners may have some questions about the reported bug and they would of course like to directly get in touch with the tester who found the issue. In most cases, this is automatically done by the defect management system where each user has his or her own account. If not, make sure you add your e-mail address and/or phone number.

  • Bad: “No information”
  • Good: “Daniel Knott,”

Other Things to Remember When Writing Bug Reports

As you have seen, there is a lot of information that should be included in a bug report. There are three other points you should keep in mind when writing them.

Don’t get personal. When filing a bug report, describe the software misbehavior rather than the developer’s mindset or the quality of his or her work. Don’t use offensive or emotionally charged words as those kinds of bugs will be ignored by the developer…and you’ll end up with bad blood within the team.

It’s not you. It’s not your fault that the bug occurred. It is the software that’s broken and you and your colleagues need to fix it.

Keep it simple. Try to write your bug report in such a way that someone with no idea about the project or the app is able to understand the problem. If the bug report is that easy, every developer within the team will be able to fix it and non-technical colleagues can understand the problem and will value your work.

If you want to read more about mobile testing, my book Hands-On Mobile App Testing covers this in depth.

Daniel Knott has been in software development and testing since 2008, working for companies including IBM, Accenture, XING and AOE. He is currently Daniel Knotta Software Test Manager at AOE GmbH where he is responsible for test management and automation in mobile and Web projects. He is also a frequent speaker at various Agile conferences, and has just released his book, Hands-On Mobile App Testing. You can find him over at his blog or on Twitter @dnlkntt.

Categories: Companies

Data mining improves food contamination identification

Kloctalk - Klocwork - Wed, 10/15/2014 - 15:00

It often seems that there are no limits to the applications of data mining technology. Every day, organizations discover new ways of leveraging these tools to discover new insight and improve their capabilities.

One of the latest, and most beneficial, uses of data mining technology concerns foodborne diseases. As Food Processing recently highlighted, IBM scientists and  the German Federal Institute for Risk Assessment's Department of Biological Safety worked together to develop a means of using data mining to better combat food contamination outbreaks.

A serious problem
The news source pointed out that foodborne illness is a serious problem around the world. One out of every six Americans is likely to be stricken by food-related illness each year. This leads to more than 125,000 hospitalizations and approximately 3,000 deaths annually. The U.S. economy takes an $80 billion hit each year as  a result of these illnesses in the form of both health care costs and lost productivity.

To combat these problems, it is essential for government agencies to identify the source of the foodborne disease as quickly as possible, as this is the best way of minimizing the damage. However, as the news source pointed out, this is a very challenging task. Increasingly complex, interconnected supply chains have the effect of vastly increasing the number of potentially affected individuals when an outbreak occurs, as it takes longer to effectively determine the cause of the illness.

Data mining improvements
Food Processing reported that IBM and the Department of Biological Safety worked together to develop a data mining tool that leverages new algorithms, visualization and statistical analysis techniques to gain insight from vast troves of grocery retailers' data. With these new resources in place, agencies can identify likely affected food products after as little as 10 outbreak cases have been reported.

"Predictive analytics based on location, content and context are driving our ability to quickly discover hidden patterns and relationships from diverse public health and retail data," said James Kaufman, manager of public health research for IBM Research, the news source noted.

The data mining tool examines billions of items sold in supermarkets each week. This information is crossed with public health data to provide government officials with a potential model of the distribution of suspect foods in a given area. For such performance, automated scanning and advanced contextualization are key, the news source explained.

Models of success
To prove the viability of their data mining solution, the Department of Biological Safety and IBM conducted a demonstration of their solution's effectiveness, Food Processing reported. In this example, the scientists simulated a 60,000-case foodborne disease outbreak caused by 500 products. The scientists then used their data mining solution, along with actual food sales data from Germany, to identify the origin of the illness.

"This research illustrates an approach to create significant improvements without the need for any regulatory changes," said Dr. Bernd Appel, head of the Department of Biological Safety, the news source noted. "This can be achieved by combining innovative software technology with already existing data and the willingness to share this information in crisis situations between private and public sector organizations."

The right tools
This effort highlighted the potential benefits offered by data mining technology – along with the need for high-quality algorithms. Without embeddable, high-performance algorithms, many data mining projects simply cannot maximize their effectiveness. For organizations to fully take advantage of this technology, they must pursue algorithms that are customizable, sophisticated and appropriate for their specific industries.

Categories: Companies

8 Lessons I learned from building a Test team

The Social Tester - Wed, 10/15/2014 - 14:20

Building a successful test team is hard work. I’ve outlined 8 lessons I learned from growing a successful test team in an article titled “The Blazingly Simple Guide To Growing A Test Team”. It has been published in the October edition of Testing Trapeze.   The article sits along great articles from Erin Donnell, Richard … Read More →

The post 8 Lessons I learned from building a Test team appeared first on The Social Tester.

Categories: Blogs

Anaheim, California, home to Disneyland and, yes you guessed it, STARWEST!

HP LoadRunner and Performance Center Blog - Wed, 10/15/2014 - 08:56

Starwest.pngAre you ready for the most comprehensive event for software testers and quality assurance professionals alike? We are headed to STARWEST Anaheim and are looking forward to meeting with you to talk testing and quality assurance.


Keep reading to find out where we will be and how you can connect with us.

Categories: Companies


HP LoadRunner and Performance Center Blog - Tue, 10/14/2014 - 19:48

We interrupt this broadcast (or blog) for important breaking news!


StormRunner Load has arrived coming on the wings of a cloud near you.  As you know StormRunner Load extends our industry-standard LoadRunner and Performance Center load testing technology with a 100 percent service offering to help ensure that web and mobile apps are able to handle just about any load...



Keep reading to learn how you can take advantage of the Storm!

Categories: Companies

The Ins and Outs of Writing an Effective Mobile Bug Report (Part I)

uTest - Tue, 10/14/2014 - 19:05

If you find a bug within a mobile app, you need to report it in order to get it fixed. Filing mobile bug reports requires some additional information 250x250xbug_report1-250x250.png.pagespeed.ic_.H3eXAv82fDthat the developers need in order to reproduce and fix the bug.

But what is important when filing a mobile bug? What should a bug report look like? Before I answer those two questions, I want to raise another one: “Why even send a bug report?”

Bug reports are very important for the product owner, product manager and the developers. Firstly, a bug report tells the developers and the product owner about issues they were not aware of. Reports also help identify possible new features no one has thought of, and, last but not least, they provide useful information about how a customer may use the software. All of this information can be used to improve the software.

Whenever you find something strange or if something behaves differently or looks weird, don’t hesitate to file a bug report.

Now onto the question of what a bug should look like and what’s important when filing it. It should contain as much information as possible in order to identify, reproduce and fix the bug. Having said that, your report should only include information that’s important to handling the bug, so try to avoid adding any useless information. Additionally, only describe one error per bug. Don’t combine, group or create containers for bugs. It’s likely that not all of the bugs will be fixed at the same time, so refrain from combining or grouping them.

Here’s the information you should plan on including in every bug report.

Bug ID

A bug must have an unique identifier like a number or a combination of characters or numbers. If you’re using a defect management tool, the tool will handle the bug IDs for you. If not, think about a unique ID system for your project.

  • Bad: 123 is a unique ID, but you might have several projects where the ID is the same.
  • Good: AppXYZ-123 is good because you’re combining an ID with a project abbreviation and a number.


Create a short but meaningful description in order to provide the developer with a quick overview of what went wrong without going into detail. You should, for example, include error codes or the part of the application where the bug occurred.

  • Bad: “The app crashed,” “White page,” “Saw an error,” “Bug”
  • Good: “Error Code 542 on detail message view,” “Timeout, when sending a search request.”

Steps to Reproduce

This is one of the most important points. Provide the exact steps together with the input data on how to reproduce the bug. If you are able to provide this kind of information, the bug will be very easy to fix in most cases.

  • Bad: “I tried to execute a search.”
  • Good: “Start the app and enter ‘Mobile Testing’ into the search input field. Press the search button and you’ll see the error code 783 on the search result page header.”

Expected Result

In this section, you should describe what you expected to happen when the bug occurred.

  • Bad: “It should work,” “I didn’t expect it to crash.”
  • Good: “I expected to see a search results page with a scrollable list of 20 entries.”

Actual Result

What happened when the bug occurred? Write down the actual result — what went wrong or the error that was returned.

  • Bad: “It just won’t work.”
  • Good: “The search results page was empty” or “I got the error code 567 on the search result page.”


If you’ve found a way to continue using the app by avoiding the bug, explain your steps. Those steps are important to know since the workaround could cause other problems or indicate a way in which the app should not be used. On the other hand, a workaround can be very useful for the customer support team in order to help customers solve the current problem until the bug gets fixed.

  • Bad: “I found a workaround.”
  • Good: “If you put the device into landscape mode, the search button is enabled and the user can search again.”


If you found a reproducible bug, that’s fine, but does it occur every time? If it happens every time, that’s great, as this should be an easy fix for the developer. But if the bug only occurs 20 percent of the time for instance, it is much harder to find a solution for that. Make sure you provide this information, however, as it is very useful for the developer and will prevent the bug from being closed with the comment “can’t be reproduced.”

  • Bad: “Sometimes”
  • Good: “The bug occurs 2 out of 10 times.”

Operating System, Mobile Platform and Mobile Device

The same applies to the operating system, the mobile platform and the mobile device. Write down the operating system, mobile platform and device on which the bug occurred.

  • Bad: “On Android” or “On iOS”
  • Good: “Android, Version 4.1.2 Google Nexus 4″ or “iOS, Version 6.1 iPhone 4S”

Mobile Device-Specific Information

Mobile devices have lots of interfaces and sensors that could have an impact on your app. The battery could also affect the app you’re testing. Write down all of this information in your bug report.

  • Bad: “No information”
  • Good: “GPS sensor activated, changed the orientation from landscape to portrait mode” or “Used the device in a sunny place” or “Battery state was 15%” or “Battery state was 100%.”

Browser Version

If your app is a mobile web app and you found an issue, it’s very important to note down the browser version where you found the bug, as it may only occur in certain versions.

  • Bad: “Google Chrome” or “Mozilla Firefox”
  • Good: “Google Chrome Version 45.35626″ or “Mozilla Firefox 27.6.”

Software Build Version

Another really useful piece of information is the current build version of the app where the bug occurred. Maybe you found the issue in version 1.2, but there is already a newer version available where the bug has been fixed. This will prevent the developer from wasting time by trying to reproduce a bug that’s already been fixed.

  • Bad: “No information”
  • Good: “App build version 1.2.3″

Check out Part II of this article right here.

Daniel Knott has been in software development and testing since 2008, working for companies including IBM, Accenture, XING and AOE. He is currently Daniel Knotta Software Test Manager at AOE GmbH where he is responsible for test management and automation in mobile and Web projects. He is also a frequent speaker at various Agile conferences, and has just released his book, Hands-On Mobile App Testing. You can find him over at his blog or on Twitter @dnlkntt.

Categories: Companies

Next Generation Testing Singapore, Singapore, 30 October 2014

Software Testing Magazine - Tue, 10/14/2014 - 18:17
Next Generation Testing Conference in Singapore is an event with software testing thought leaders and great presentation covering emerging technologies like, Big Data Testing or Cloud Testing. In the agenda of Next Generation Testing Singapore you can find topics like “Testing Compliance Against Accessibility Guidelines”, “Mobile Test Automation Pick the Right Tool”, “Agile Testing – Test Automation and Continuous Delivery”, “What CIO Expects From Quality and Testing Team”. Web site: Location for 2014 conference: UE Convention Centre, 4 Changi Business Park, Avenue 1, Singapore – 486016
Categories: Communities

Fifty Quick Ideas To Improve Your User Stories – Now Available

Gojko Adzic - Tue, 10/14/2014 - 17:18

web 750x750 gradient-01 The final version of my latest book, Fifty Quick Ideas To Improve Your User Stories, is now available on the Kindle store, and the print version will be available on Amazon soon.

This book will help you write better stories, spot and fix common issues, split stories so that they are smaller but still valuable, and deal with difficult stuff like crosscutting concerns, long-term effects and non-functional requirements. Above all, this book will help you achieve the promise of agile and iterative delivery: to ensure that the right stuff gets delivered through productive discussions between delivery team members and business stakeholders.

For the next seven days, the book will be sold on the Kindle store at half the normal price. To grab it at that huge discount, head over to the Kindle store (the price will double on 22nd October). Here are the quick links: UK DE FR ES IT JP CN BR CA MX AU IN

Categories: Blogs

Reflecting on the Perform Global User Conference

Another wonderful Perform Conference! Great American purchased the Dynatrace Software in December of 2012, and we made our first appearance at the Perform Conference 9 months later (2013).  We had no idea what to expect last October, but walked away impressed at the work that had been put into the Conference and with the value […]

The post Reflecting on the Perform Global User Conference appeared first on Compuware APM Blog.

Categories: Companies

TestTrack Web Challenge Part 2: Writing Test Cases

The Seapine View - Tue, 10/14/2014 - 12:30
Test Case Writing

Can this be done? I definitely asked myself this question when I started the challenge of only using the web client to accomplish my work. The web client has an existing testing portal, and I can access both test cases and test runs. But, it doesn’t have the luxury of allowing me to open multiple windows at once. How can I write a new test case while consulting existing test cases and reviewing the functional requirement I am writing the test case from on the web client? I started asking around about this dilemma and a manager gave me a tip that would forever change my test case writing. To sum up that tip in one word: Reports.

“Ok, ok, ok, you’ve lost me now. I thought we were talking about writing test cases. And I can’t create reports on the web, can I?”, you must be asking yourself. Well I know, I thought the same thing! Here is where the web client’s power is realized. Yes, it’s true. I can’t view two windows at the same time in edit mode unless I use additional licenses and have multiple sessions open. But is this really needed? No.

Let me explain. I took a step back and looked at my process of writing test cases. Yes, I use several windows to do this. However, I only edit one item at a time. The requirement I am looking at is just a reference and the same goes for the test case I am comparing it to. I may copy and paste text from another item, but I am usually only editing one item at a time. Here is where the reports come in. Every item type has a reporting option on the Actions menu.


Specifically, I’ve found the <Item>DetailReport, <item>SummaryReport, and Requirement Document (for a full Specification Document Report) to be very helpful. I can generate reports for items I am going to compare and then I can generate the new test case from the requirement in my active TestTrack web session. When adding information and steps to the new test case, I can simply reference and even copy from the reports I generated. The reports can be additional tabs on my browser window or they can be a separate browser window that I reference on a second monitor.


This new method of writing test cases using the web client has worked so well, I’ve been able to use it for the past 150 test cases I’ve written without any issues related to time or lack of functionality! So the next time you find yourself settling down to write test cases, consider using this new method with the web client. I’m certain you will be surprised by the amount of functionality available.

Stay tuned for my next blog post regarding TestTrack Web navigation, as part 3 of the ‘TestTrack Web Challenge’! Are you ready?

Share on Technorati . . Digg . Reddit . Slashdot . Facebook . StumbleUpon

Categories: Companies

imbus AG - New European Service Partner

Ranorex - Tue, 10/14/2014 - 11:53
As we have rapidly grown our presence and customer base in Europe, we have also seen an increasing demand for Ranorex consulting and implementation services. To help meet this demand, we have the pleasure of announcing that we have partnered with imbus AG.

imbus AG
is one of Germany’s leading specialists for software quality assurance and test. With more than 230 employees at four locations, imbus supports companies and IT-users in verifying and validating complex and demanding software systems, as well as in the optimization of their software development processes.

For more information about imbus AG, please visit

Categories: Companies

Appium Wins A Bossie Award From InfoWorld

Sauce Labs - Tue, 10/14/2014 - 00:36

Thanks to InfoWorld for naming Appium as the mobile testing framework of choice in the category of the Best Open Source Application Development Tools in this year’s Bossie Awards!  Sauce Labs is proud to sponsor the development and maintenance of this world class open source project. Cheers to our Ecosystems team and to the external committers who have helped drive its success. For more about Appium, read below.


Appium is an open source test automation framework for use with native, mobile Web, and hybrid mobile apps. It uses Node.js and drives iOS and Android apps via the WebDriver JSON wire protocol. There are already Appium clients written in languages like Ruby, Python, Java, JavaScript, PHP, C#, and RobotFramework.

Appium is at its heart a Node.js Web server that exposes a REST API. It receives connections from a client, listens for commands, executes those commands on a mobile device, and responds with an HTTP response representing the result of the command execution. If you don’t want to fuss with Node.js, you can install GUI-driven Appium servers on Windows and OS X.

– Martin Heller

The Bossy Awards showcase InfoWorld’s picks of the year among languages, frameworks, libraries, and all the other tools that programmers use. To learn who else won, click here.

Categories: Companies

My Weekend with the Goat Simulator App

uTest - Mon, 10/13/2014 - 21:18

We often talk about the newest and hottest mobile apps at the uTest Community Management desk. Recently, I was curious if I was missing out on any top apps that I didn’t already have on my Samsung Galaxy S4. I am surrounded by a sea of iPhone users so I am used to not getting in on the latest apps until (much, much) later. Of course, I have the requisite social media, weather, and news apps installed but what is really hot for the Android app market these days? I checked out the top paid apps in the Google Play store and, to my surprise, the one odd app that stuck out is the Goat Simulator at #9 on the Top 10 list. Screenshot_2014-10-10-19-10-05

Per the app’s description: “Gameplay-wise, Goat Simulator is all about causing as much destruction as you possibly can as a goat. It has been compared to an old-school skating game, except instead of being a skater, you’re a goat, and instead of doing tricks, you wreck stuff. When it comes to goats, not even the sky is the limit, as you can probably just bug through it and crash the game. Disclaimer: Goat Simulator is a completely stupid game and, to be honest, you should probably spend your money on something else, such as a hula hoop, a pile of bricks, or maybe pool your money together with your friends and buy a real goat.”

I appreciate the developer’s humor, especially since they list the top key feature as “you can be a goat.” I can’t say I’ve always dreamed of being a goat, but here was my shot. Ryan, our beloved blog and forums guru, practically ordered me to buy the app (cost: $4.99), play it over the weekend, and report back on Monday. A check of the app on Applause Analytics showed a satisfaction score of 77 and noted that it is the app’s strongest attribute. Okay, game on. Goat-sim-screenshot

The Goat Simulator app played as expected. You are a first person goat whose job is to run people down, kick objects across long distances, and generally be a menace to society. (If we’ve ever met, then you know I am capable of such things – no app needed.) I was waiting to encounter the supposed millions of bugs that the developer mentions but, sadly, I did not. I stopped playing the game on Saturday when I realized I had given one too many hours of my life to being a virtual goat and that it was time to take a shower and rejoin civilization.

However, I was still wondering: What odd, strange, or unique apps do you have installed on your phone? And what’s the oddest app that you’ve paid for? Let’s chat about it in the forums.

Happy goating!

Categories: Companies

Beautiful Builds

Testing TV - Mon, 10/13/2014 - 20:11
This presentation covers useful patterns for solving common problems that you might come across while building your automated build process: slow builds, unmaintainable scripts, dependencies between multiple components and versions. Video producer: More about this topic on
Categories: Blogs

Fast IT - a bridge to Continuous Delivery

Assembla - Mon, 10/13/2014 - 20:06

Are you interested in moving your organization to continuous delivery so you can be FAST and COMPETITIVE?  Do you want to catch up with competitor like Amazon that upgrade frequently and relentlessly? This video explains how the Fast IT layer can help you do it.


The Fast IT idea separates the "Fast" projects from the "Core" projects using an API, index, or other access method. This allows the Fast teams to move forward with their own type of planning, governance, and testing, which may not be compatible with the mission of the "Core" team.


Fast projects are often small projects like Web sites and mobile apps.  However, you may find that you need to take on a bigger challenge. For example, consider an ecommerce business that competes with Amazon.  Ecommerce is not a small project.  It is central to your future.  Reliability is important because your ecommerce business brings in a lot of sales, which feed into the Core fulfillment systems.  So the "Core" teams that run your operations will not allow you to release changes without a long testing process.  We have to allow them to fulfill their misison, but we also have to take them out of the front-end release process.

A modern front-end system is likely to be similar to Amazon's "matrix of services" or MAXOS.  The system is divided into many Web services, which are maintained by teams that each run continuous delivery. In Amazon's case, they have thousands of these services and they release a change somewhere about once every 11 seconds.

We can use our API tactic to add the new MAXOS layer.  The Core systems become a stable Web service that is part of the "matrix." Then, we start adding the new front-end services on top.  Over time, we can recruit more people out of the Core layer and build the Fast/MAXOS layer.


Categories: Companies

Create verify steps on-the-fly during real-browser recording in 6.4 release

Web Performance Center Reports - Mon, 10/13/2014 - 16:05
Verifying elements and text on the page is an important part of every testcase. Web Performance Tester makes this easy by adding verify steps directly from the browser while recording the testcase. The Verify option in the browsers pop-up menu provides a list of the most common verifications: In addition to verifying the page title and URL, there are three categories of verifications supported: For any element, you can verify: text of the element element exists element is visible element is clickable For any field (text input, button, checkbox, etc) you can verify: field value field is (or not) selected By selecting text on the page, you can verify … Continue reading »Related Posts:
Categories: Companies

6 Common Mistakes When Setting Up a QA Department

Software Testing Magazine - Mon, 10/13/2014 - 15:58
As software development companies grow, it becomes more important to have a formal quality assurance (QA) process. In this article, Veronika Olshevskaya discusses six mistakes that you might do when you setup your QA department and suggests solutions to avoid making them. Author: Veronika Olshevskaya, QA Globo Consulting, You have decided that your company is mature enough and it is the right time to create a QA department. Let me add up front that by QA I don’t mean software testing. Testing is important, but it is different from QA. I ...
Categories: Communities

Knowledge Sharing

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