Sauce Labs Now Supports Android, iOS and Mobile Apps
Honda recalls 44,000 Fit Sports due to software flaw
An issue with the automaker’s Vehicle Stability Assist system software has led to the recall of nearly 44,000 2012-2013 Honda Fit Sport cars. Vehicle Stability Assist is Honda’s name for electronic stability control, a feature that has been mandated in all light-duty vehicles by the National Highway Traffic Safety Administration since 2011. Honda discovered during compliance tests that Fit Sports equipped with certain tires did not meet U.S. Federal Motor Vehicle Safety Standards.
A total of 43,782 2012-2013 Fit Sports are being recalled, Automotive.com reported. According to an email Honda spokesman Chris Martin sent to the New York Times, the Fit Sport’s stability control was programmed to fit the handling specifications of Bridgestone Turanza tires. However, some models were equipped with Dunlop SP tires, and the system did not react quickly enough to stabilize these cars appropriately. As a result, the yaw rate – the gyroscopic force that can affect the vehicle’s direction – exceeds federal safety standards, the LA Times noted.
Electronic stability control systems draw on sensor data and embedded software to attempt to detect and minimize the loss of control. If the direction the car is moving does not match what the driver is doing with the steering wheel, the system can apply the brake on individual wheels to try to correct the slide. The NHTSA has estimated that once all cars have the feature, as many as 5,300 to 9,600 lives could be saved each year.
Honda is planning to mail out notices to owners, who can have their VSA software updated by Honda dealers. The company has said that there have been no accidents or injuries reported due to the flaw. Nonetheless, such a large recall can serve as a reminder that precision and careful attention to detail is necessary in automotive software to meet coding standards. Using tools such as static analysis software, carmakers can work to harden the embedded software security in their vehicles and mitigate potential errors.
Software news brought to you by Klocwork Inc., dedicated to helping software developers create better code with every keystroke.
Saga patterns: wrap up
Posts in this series:
NServiceBus sagas are a simple yet flexible tool to achieve a variety of end goals. Whether it’s orchestration, choreography, business activity monitoring, or just other long-running business transaction variants, the uses of an NServiceBus saga are pretty much endless.
When choosing to go with a centralized workflow, we also saw that there is a cost to centralization with the introduction of a bottleneck. With the routing slip pattern, we can include instructions with our message in a header so that each recipient only needs to reference the attached instructions. In a routing slip, flow is linear, but there’s nothing stopping us from including more advanced instructions for state machines, compensations and so on.
I tend to think of the NServiceBus saga as more of a facility, than a specific pattern, because it doesn’t force us to go in any one direction. Rather than assume a specific role or function for a saga, I like to keep things a bit more flexible, and choose one of the many conversation/messaging patterns available for each given scenario.
In the end, sagas are a useful tool (and one that can be over-used, not every workflow deserves central management), but a nice one to have. Every time I introduce NServiceBus sagas to folks that spent time with other messaging tools, whether it’s big orchestration with ESBs or bare-metal messaging tools, the simplicity and code-centric nature of NServiceBus sagas either excites or depresses, depending on the possibility of switching or introducing new tools.
Post Footer automatically generated by Add Post Footer Plugin for wordpress.
The Development Methodology Wars are Nearing an End
Over the years, we’ve thrown a considerable amount of nouns, verbs and adjectives at the topic of development methodologies. We’ve focused mainly on that of agile and waterfall, as they are not only the most popular, but they are (in my opinion) the two most polarizing approaches.
We’ve examined and listened to arguments in favor of one versus the another – agile is more fluid and responsive, waterfall is more practical, agile people are flakes, waterfall people are dinosaurs, etc. etc. etc. We tried to be neutral, giving equal weight to the arguments of both sides. Our aim was to educate you – dear reader – in the hopes that we could help you make the right decision when it came to choosing a methodology.
What a waste of time that was! Well, only if you believe that the war of methodologies are over - an idea that was raised in a recent article on PCadvisor.com, and one that I felt was worthy of further consideration. Here’s the gist:
The wars over development methodologies — agile, XP (extreme programming), waterfall, and so on — are fast giving way to a more fluid and flexible approach to producing and refining a product. Telerik’s Semeniuk is one of many in the modern development world who sees development methodologies not as dogmas to be followed to the letter, but toolkits to be raided for what’s useful. Confining a development team to one methodology is becoming a thing of the past.
In other words, if you are a methodology fundamentalist – that is to say you never waver from the playbook – then you are likely missing out on a number of tactics that can improve the development (and testing) process. Case in point:
Some, however, caution that agile can’t simply be sprayed onto an existing development process. A former program manager who has declined to be named but has five years of experience as a Scrum master has time and again seen agile used in development, but with no corresponding changes in other facets of bringing software to market.
“There’s no intermittent QA; instead, there’s old-school ‘toss it over the wall to QA’-style QA,” he says. “Instead of regular releases, they’re using agile to get a release out, then having the schedule disrupted by support.” In his purview, there has been a battle between traditional software releases and agile, with a lot of people simply using agile merely to drive old-school models.
So what now? On the one hand, you can continue to stick to the rigid rules of the methodology of your choice. Or you can accept the notion that every methodology has something of value, and to borrow those elements as they are needed.
What are your thoughts? Do you believe the methodology wars are coming to an end?
Please sound off in the comments section below.
Announcing iOS and Android App Testing on Sauce
Today we are very excited to announce the general availability of Appium on Sauce! Appium is the open source cross-platform mobile automation platform for native mobile, hybrid, and mobile web apps, and it runs on iOS (iPhone and iPad) and Android devices and emulators.
Appium represents a huge step forward in the fight to make mobile automation a first-class citizen in mobile development. We’ve been running our iOS-based private beta for Appium on Sauce for a while, and have made many improvements while supporting the development of the Appium open source community. Since then, Android support has matured to the point where we are now offering it in our cloud alongside iPhone and iPad. Soon enough, we’ll be releasing the ability to run your Appium tests not only on our cloud of emulators and simulators, but also on real devices (stay tuned for more on that later!).
If you want to get started with Appium right now, simply visit the Appium on Sauce tutorial. And check out the Appium iPhone demo below.
If you’re interested in what Appium’s all about, read on.
After contributing thousands of lines of code to the open-source project and helping to breathe fire into what has become a very active community (see our issue tracker, our discussion group, or join us in #appium on freenode), it’s clear to us that Appium’s philosophy is compelling to a wide array of developers, test engineers, and QA professionals. Appium’s philosophy can be stated pretty succinctly in the form of four principles:
- Test the same app you submit to the marketplace. (You shouldn’t have to recompile your app with a 3rd-party library to test it.)
- Write your tests in any language, using any framework. (You shouldn’t have to learn a new language.)
- Use a standard automation specification and API. (Don’t re-invent the automation model wheel.)
- Build a large and thriving open-source community effort. (Say no to vendorware and skunkworks.)
Based on the huge amount of energy we’ve been receiving from the growth of the open source community, I’d say these principles are withstanding scrutiny.
While Appium on its own is a leap forward in mobile automation, allowing true cross-platform testing and scaling across the different dimensions of apps and devices (simulator vs. real devices, iOS vs. Android, native vs. hybrid), it is especially powerful when combined with Sauce Labs. Sauce’s value has historically been most apparent in freeing web developers and testers from managing their own test and reporting infrastructure. With Appium, this instant scalability is available to mobile-focused teams as well. Only on Sauce can you run your mobile tests across platforms in massive parallel, opening up a world of potential for continuous integration and QA in general. Continuous deployment for mobile apps, anyone? It’s possible, and with Appium on Sauce it can become the standard.
Writing Appium tests is as easy as writing the Selenium WebDriver tests you may be familiar with or may be already running on Sauce. You can write them in any language (Python, Java, PHP, Ruby, Node.js, C#, Go, Haskell, etc…) or test framework (RSpec, PHPUnit, JUnit, Nose, Mocha, Vows, Cucumber, Capybara, etc…). And of course, they come with the same great reporting (screenshots, videos, and command logs) as browser-based test sessions.
I’ll leave you with an example test, running a notes application on Android (taken from this example):
import os
from selenium import webdriver
desired_caps = {}
desired_caps['device'] = 'Android'
desired_caps['browserName'] = ''
desired_caps['version'] = '4.2'
desired_caps['app'] = 'http://appium.s3.amazonaws.com/NotesList.apk'
desired_caps['app-package'] = 'com.example.android.notepad'
desired_caps['app-activity'] = 'NotesList'
SAUCE_USERNAME = os.environ.get('SAUCE_USERNAME')
SAUCE_ACCESS_KEY = os.environ.get('SAUCE_ACCESS_KEY')
driver = webdriver.Remote('http://%s:%s@ondemand.saucelabs.com:80/wd/hub' % (SAUCE_USERNAME, SAUCE_ACCESS_KEY), desired_caps)
el = driver.find_element_by_name("New note")
el.click()
el = driver.find_element_by_tag_name("textfield")
el.send_keys("This is a new note!")
el = driver.find_element_by_name("Save")
el.click()
els = driver.find_elements_by_tag_name("text")
assert els[2].text == "This is a new note!"
els[2].click()
driver.quit()
You can also take a look at an iPhone example test.
Want to run Appium on Sauce right away? Simply create a Sauce account and you’ll be good to go. If you’re already a Sauce user or customer, you have access to Appium testing capability without any further steps.
Once you’re ready to start writing your Appium tests, take a look at the Appium on Sauce tutorial to get started. And don’t forget to let us know how things are going for you in your quest to total mobile automation.
Happy native app testing from all of us at Sauce!
Automated Testing is Not Agile Testing
Conference appearances, 2013
Visit The Build Doctor for the full article.
CollabNet and UC4 Announce Joint Enterprise DevOps Platform
Are developers ready to embrace Android as a gaming platform?
Android is the most widely used mobile operating system, giving developers looking to reach a large audience a strong incentive to release apps for the Google Play Store. Despite the operating system’s popularity, however, many game developers remain ambivalent about Android, according to recent reports. Among the issues cited are high piracy rates, a less enthusiastic user community and compatibility issues stemming from the large array of Android devices.To embrace the increasingly popular OS, programmers may need new development tools.
Mixed prospects with Android audiences
Despite a substantial lead in terms of market share, Android is generally seen as inferior to iOS for game options. In a column for Wired last fall, developer Owen Faraday called Android a “desolate wasteland” for games, noting that many of the top mobile games are or started out as iOS exclusives, with Android ports considered an afterthought. Android users have been shown to spend less than their iOS counterparts on apps, making them a less appealing market for studios charging premium prices.
Additionally, piracy rates for Android are substantial. Sports Interactive, which produces popular soccer simulation “Football Manager,” told Eurogamer last year that nine out of 10 copies of the game were pirated, and other studios have reported similar figures, TechHive noted.
Nicholas Vining, chief technical officer of Gaslamp Games, told TechHive recently that some of the companies he used to work with have reported making as little as 1 percent as much money on Android as on iOS. Telltale Games, which made last year’s popular, award-winning “Walking Dead” adventure game, recently explained that piracy, disparate hardware specs and the lack of a central Android app store had discouraged the studio from porting to Android.
Others told TechHive that Android users were their best audience, however. For Robot Invader, the studio behind popular mobile game “Wind-up Knight,” Android users are a bigger source of revenue than iOS users, largely due to a greater volume of downloads. Spacetime Studios CEO Gary Gattis, whose company makes the “Legends” mobile massively multiplayer franchise, reported a similar phenomenon.
“On a day-to-day basis, we actually make more from the Google Play Store than we do the Apple App store,” he told TechHive. “That being said, the average revenue per iOS user is certainly higher, but we just have that many more Android users.”
Dealing with fragmentation
One of the primary challenges with Android game development is that the platform is simply seen as more difficult to develop for than iOS. The vast Android ecosystem – one analysis pegged the total number of distinct devices at 3,997, according to TechHive – means that ensuring compatibility across all devices is essentially impossible, particularly for small, independent studios.
Adjusting specifications for the different screen sizes, screen resolutions and OS versions is generally not worth the effort, particularly when compared to developing for the more standardized iOS environment with users who are willing to spend more. The same features that make Android appealing for hardware makers are a challenge to software developers, Chris Schwass, of independent studio Campfire Creations, told Wired. Gaslamp’s Vining agreed, explaining that hardware issues can reflect poorly on software developers.
“If your name is on a software product, you are judged by how that software product runs on the consumer’s hardware – and it’s your fault, as a developer, if the game fails to run on some cell phone or tablet that Samsung only manufactured, for six months, for sale in certain parts of Hungary,” he told TechHive.
With Android’s market dominance, many are confident that the development environment will improve. For now, though, programmers are saddled with screen size issues and other compatibility challenges created by device fragmentation. As they look to navigate these challenges and avoid errors in their games, tools such as static analysis software can help catch inconsistencies and eliminate bugs.
Software news brought to you by Klocwork Inc., dedicated to helping software developers create better code with every keystroke.
uTest on What Makes a Killer App
How do you make a ‘killer’ application? This was the question uTest’s CMO, Matt Johnston, addressed yesterday on NBC’s Press: Here in the San Francisco Bay Area.
For those unaware, Press: Here is a Sunday morning roundtable discussion show featuring the top names in Silicon Valley’s tech industry. Yesterday, Press: Here host, Scott McGrew, along with Fortune writer, Michal Lev-Ram, and eWEEK editor, Chris Preimesberger, asked Matt about uTest’s expert-sourcing model, the apps economy and the factors that make an app stand out and succeed. Check out the video here:
Something Cool with Hosted Repositories at Assembla is Happening
We announced our latest feature Server Side Hooks the other day. But before we even did that, something very cool happened, we got our first hook submitted by a contributor outside of Assembla. Thanks so much Jakub. Now users with Subversion repositories can install this hook and check their PHP code syntax.

We could never have had the time to think of creating nor actually implementing a solution for checking PHP code, because we would want to check all sorts of style of code and the scope would grow. Now users can scratch their own itch with minimal effort on our part.
For those of you still not sure what I am talking about: We are allowing customers to write their own Server Side Hooks and install them on our Servers, that’s right, you can extend Assembla’s cloud repository offering.
Thanks again and keep those hooks coming.
Testing Android Apps with Robotium and JBehave
Software Testing in an Agile World
A Smattering of Selenium #148
Gotta start this up again…
JFrog Launches Artifactory 3.0
Time to Show Mom Some Love – Was the User Experience Warm and Fuzzy?
What software security lessons can companies learn from open source projects?
Open source software projects have long been celebrated for their role in driving innovation, their low cost to users, their potential for customization and more. At the same time, many people remain skeptical of the security of such projects, assuming that the total accessibility of the code makes it easier for attackers to find weaknesses or even actively implant malicious changes to the code base themselves.
However, many experts suggest that open source can be safer than closed projects because it incorporates more code review and developers can resolve issues more quickly. Some have suggested that it would benefit large projects such as Oracle’s Java to go open source and leverage their user communities to improve security.
Why open source works for security
Although many people tend to think of open source projects as using a collaborative, amateur-driven environment similar to Wikipedia that allows anyone to make changes, this type of ad hoc tinkering is not a common approach, a recent SC Magazine article noted. Open source projects tend to be large undertakings mostly managed by professionals working for companies that make money from the software in some way, and new additions are generally submitted to peer code review before they are entered.
Paul Wander, co-founder of open source web development company Inviqa, told the publication that security ultimately comes down to the quality of a piece of software, and the ambition and scope of open source projects generally means that they are high quality undertakings being handled by talented engineers. Lamar Bailey, director of security research and development at nCircle, agreed, adding that large communities create particularly strong projects due to having more expert eyes looking over the code for issues.
“Popular open source software packages with hundreds of contributors reviewing and modifying the code are more likely to be secure because some of the contributors are probably security-savvy, so the likelihood that they will find and fix security issues is high,” Bailey told SC Magazine. “Less popular open source software with fewer contributors may not undergo the same scrutiny and may be more likely to contain easily exploitable vulnerabilities.”
Another quality of open source projects is that their large user communities drive rapid evolution of the software, and security issues are addressed more quickly, Rafael Laguna, CEO of software company Open X-Change, told SC. Although quality can vary according to how robust the user community is and how many people are actively contributing, open source projects generally involve similar resources to closed ones and augment security by bringing in more eyes.
“If the same people with the same skills, using the same processes, were to produce software under both a proprietary model and an open source model, the results would likely be the same,” Laguna said. “Open source projects, however, can have the advantage of a peer review from a large community of knowledgeable supporters, and this cannot be understated.”
Drawing on open methodologies
In a recent post, InfoWorld columnist Simon Phipps suggested that Oracle could benefit from bringing in a larger user community to help address the widespread security issues in Java. Phipps noted that the company’s current approach to security barely involves even trusted partners, making it difficult for changes to be validated or integrated into other products before they are released. Although Oracle has a very talented security staff, its approach means that the burden of finding, fixing and testing errors falls on this group alone. The company could be one in particular to benefit from bringing in additional labor, as much of its work is in paying off a long-time “technical debt” in Java that comes from before Oracle owned it.
“Proprietary projects are often forced to be solely feature-focused, prioritizing customer needs and marketing schedules over the gruntwork of keeping the code clean,” Phipps wrote. “Open source projects with a large and healthy community are in a much better position to bypass the problem of technical debt, as community members will often pour enthusiasm and expertise into resolving the backlog.”
While going open source does not make sense for many companies, adopting the same mindset of constant review that involves a large network of collaborators and expert eyes can be valuable for strengthening code, catching errors and eliminating technical debt. Instead of relying on a large user community, smaller or more sensitive products can enlist third-party code review tools and services.
Software news brought to you by Klocwork Inc., dedicated to helping software developers create better code with every keystroke.
Perspectives on Testing
Welcome to Seapine’s Perspectives on Testing. Every week I’m going to look at articles, blog posts, tweets, and other testing and quality content, and provide some perspective on the news or commentary. Enjoy, and I look forward to hearing your feedback.
Agile Point of ViewIan Mitchell talks about whether or not estimation should be an integral part of Agile development processes. This is a great overview on how to begin to estimate the amount of work required by user stories.
Cameron Laird says that managing technical debt during your Agile development effort will result in applications that are more business-ready.
Testing PhilosophyThere has been a heated debate in the testing community on the reality and value of best practices. This was started by Rex Black, who has been espousing the value of certain best practices. While others have taken to Twitter to object, James Christie has written down his thoughts on the fallacy of best practices in a blog post. Christie follows that up with a second post on whether best practices actually provide protection for those seeking to build and deploy quality software.
Further, the debate on best practices is really an outgrowth of an even more heated discussion by the same participants on the value behind testing certification, most especially that offered by the ISTQB. While James Bach has been leading the charge against ISTQB certification on Twitter, Keith Klain has written a blog post outlining his objections to the claims made by the organization about the value of certified testers.
The EuroSTAR conference has done a great job of summarizing the debate on certifications, citing multiple blog posts. It also notes that the time has come to separate the entire topic of certification from that of the value of testing courses.
Scott Barber notes in this video he recorded at STPCon in April that business executives see software testing as an expensive practice that doesn’t contribute to business goals. He looks at ways that testers can be better contributors to the business. If you watch one professional video on YouTube a year, this should be the one.
Huib Schoots is looking for nominations for the top 10 best books for testers. Make your recommendations here.
I’ve enrolled in another MOOC, this one on software testing. Check it out on Udacity to see if it might meet your needs.
Seapine ViewSeapine is sponsoring a free webinar with Software Quality Associates (SQA) to show how testing teams can dramatically improve productivity by adding predictive metrics to your measurement portfolio. This will be held on May 16, and is available for sign-up now. Read more about it here.
Interesting ReadI confess that I don’t have anywhere near enough of a physics background to understand the concept of a quantum Internet, but it looks like US scientists at the Los Alamos Labs have created and are using just such a network designed for completely secure communications. Will this concept be available for general use in the near future?
Share on Technorati . del.icio.us . Digg . Reddit . Slashdot . Facebook . StumbleUpon4 Tips for Replaying Remote Desktop Protocol (RDP) scripts in LoadRunner
LoadRunner scripts that use the Remote Desktop Protocol (RDP) don’t always replay smoothly. My colleague Kert (Yang Luo) from the LoadRunner R&D team has collected some tips that will save you time and effort, and help you ensure that your RDP scripts run correctly. Continue reading to learn more.
Performance testing solutions for the New Style of IT: HP LoadRunner 11.52 is now available
Last week at the StarEast Testing Conference in Orlando, FL we made some pretty big announcements. We released new versions of our flagship quality and testing software products. We are calling the whole initiative “The new style of IT”.
This new way of thinking about IT is impacting LoadRunner as well. Keep reading to find out the highlights of LoadRunner 11.52 and why I am as excited about the launch as a kid getting a new toy.