Did you get it right? Learn how to be predictable with HP LoadRunner!

Sometimes, work can be difficult without the proper mindset. If you’re tired, angry or frustrated for instance (like Patriots fans this morning) then you’re almost guaranteed to make some careless mistakes. This is true of almost every profession. Software testing in no exception.

So what’s the proper mindset for a software tester? Much has been written on the topic – and it’s critical to your success in the field – so I figured I’d offer a view different points of view.

Here’s one from softwareprojectmanager.com:

A professional tester approaches a product with the attitude that the product is already broken – it has defects and it is their job to discover them. They assume the product or system is inherently flawed and it is their job to ‘illuminate’ the flaws.

This approach is necessary in testing.

Designers and developers approach software with an optimism based on the assumption that the changes they make are the correct solution to a particular problem. But they are just that – assumptions.

Without being proved they are no more correct than guesses. Developers often overlook fundamental ambiguities in requirements in order to complete the project; or they fail to recognise them when they see them. Those ambiguities are then built into the code and represent a defect when compared to the end-user’s needs.

Here’s another view from onestopsoftwaretesting.com:

Pedantic, sceptical, nit-picking to software

Some years ago, we were asked to put a slide together, saying who makes the best testers, and we thought and thought, but eventually, all we could think of was, they’ve got to be pedantic and sceptical and a nitpicker. Now, if you called someone a pedant, a sceptic, and a nitpicker, they’d probably take an instant dislike to you. Most folk would regard such a description as abusive because these are personal attributes that we don’t particularly like in other people, do we? These are the attributes that we should wear, as a tester, when testing the product. When discussing failures with developers however, we must be much more diplomatic. We must trust the developers, but we doubt the product.

Most developers are great people and do their best, and we have to get on with them – we’re part of the same team, but when it comes to the product, we distrust and doubt it. But we don’t say this to their faces. We doubt the quality of everything until we’ve tested it. Nothing works, whatever “works” means, until we’ve tested it.

Impartial, advisory, constructive to developers:

But we are impartial, advisory and constructive to developers. We are not against them, we are on the same team. We have to work with them, not against them. Because it is human nature to take a pride in their work and take criticism of their work personally, bear in mind this quote: ‘tread lightly, because you tread on their dreams’.

Here’s a similar view from kualitatem.com:

All software must possess bugs as the developers are human and you can’t eliminate the error factor from humans. Therefore it’s very important for the tester to think from end user perspective and try to find out all the possible bugs that a user can face. The approach to use Mindset Testing is to treat the software as it’s full of bugs; the developers deployed an application that will crash when end-user will use it and testing its all possible flows. Here begins the work of a tester to find out all these bugs and loopholes that will make this application go crashing.

Don’t take any bug lighter, “Report all bugs you have encounter with”, as you will be responsible for it at the end.  Although sometimes with the mutual understanding of the developers and QA, some bugs are not addressed right away, but still, from QA perspective one should not skip reporting any bug.

What do you think? Is there a proper mindset for testing? If so, what is it? Please share your thoughts in the comment section below.

 

Join us Tuesday, February 21 at 11:00AM (GMT-0500) for a 30 minute demonstration of Nexus 2.0, with Jason van Zyl, Sonatype Founder & CTO. You’ll see all the new features and learn how Nexus 2.0 will help you:

• Avoid downtime by using a highly available architecture
• Improve repository management with enhanced component information
• Standardize on a single repository for .NET, Java, and OSGi

Reserve Your Seat

If you register, you’ll also receive access to the recording after the event. So if something comes up and you can’t make it, you won’t miss out.

New webinar from CloudBees and Codesion - CollabNet Cloud Services:
Tuesday, March 6, 2012 10:00 AM - 11:00 AM PST

At this very moment, software development and deployment practices are shifting monumentally…to the cloud! The cloud provides significant advantages that allow organizations to substantially improve efficiencies and delivery times at a much lower cost, reducing the overall total cost of delivery of applications.

Exploit the cloud? Get even better at Agile? Save time and money?

If any of these concepts pique your interest, you’ll enjoy this new webinar from luminaries at CloudBees and Codesion, the Cloud Services arm of CollabNet.

CloudBees VP of Products Steve Harris, CollabNet VP of Products and Engineering Willie Wang, and CloudBees Solutions Architect Jim Leary will enlighten you on how to easily and cost-effectively…

• Get started developing and deploying applications in the cloud
• Improve and expand your Agile practices using the cloud
• Exploit the cloud to accelerate the development and delivery of quality applications
• Modernize your continuous integration and deployment process and methods

If you want to spend more time writing awesome code and less time managing your environment, register for this webinar.

Willie Wang
CollabNet VP of Products and Engineering
Jim Leary
CloudBees Solutions ArchitectSteve Harris
CloudBees Senior VP of Products

Testing usually means looking for bugs in software. But to Sport Evac, it means ensuring everyone gets out of a stadium safely in an emergency situation. The software was designed by the National Center for Sports Safety and Security and tests every scenario imaginable to help security personnel and first responders at big sporting events prepare for an emergency. But, as it turns out, testing is testing whether you’re testing the latest mobile app or an evacuation strategy for the big game. The goal is to find as many of the nasty bugs as you can before everything goes live. FoxNews has more on Sport Evac:

The Sport Evac program trains teams for those “what if” scenarios, by creating virtual 3D stadiums drawn from actual blueprints and packing them with up to 70,000 animated human avatars designed to respond to threats as unpredictably as their human counterparts.

It’s advanced technology fans won’t see on game day — but tech that behind the scenes makes watching the big game safer.

Evacuation in the event of an emergency is a critical challenge, and rehearsing the how to move around tens of thousands of people isn’t realistic. So sports security planners turn to computers to make sure it all goes smoothly.  …

The virtual stadium allows them to simulate how fans will respond in those first few critical minutes after an attack. Stadium and team security can use the virtual stadium to practice moving players and fans to safety and to run exercises with local first responders. …

As with any test, the ability to scale to meet different demands is key to success. Only testing for the “best case scenario” isn’t very effective.

Sport Evac isn’t the only evacuation software program, but others have struggled to meet the scaling challenge of sporting events. Other simulations also failed to include the wide range of human behavior variations and the multitude of factors that may disrupt the best-laid aid plans.

All sorts of curve balls can appear in a threat: parking gridlock, for example, making an orderly exit disorderly, or the elderly having a hard time with a crushing crowd.

Sport Evac allows security teams to test the robustness of their planning against the full range of possible factors — fans fighting against the stream to retrieve forgotten wallets and handbags, spilled beer creating too-slick floors, emergency lights failing and so on.

Not only did the makers of Sport Evac create and test desktop software, they are also working on a mobile app version of the software for stadium employees and first responders to use on-site. This app sounds like a perfect candidate for some in-the-wild testing because any sports fan can tell you that the middle of a sold-out stadium isn’t the best place to get a signal. Plus, this is the last app you want to crash, freeze, load slow or glitch at the exact moment you need it most.

A smartphone app, known as Sport Evac Lite, will become available as well, so security staff and ushers can see where fans and cars could bottleneck.

Read the full article at FoxNews >>>

Two weeks ago, all Scala projects required a little bit of extra configuration to point to a custom repository for Scala artifacts hosted at scala-tools.org. Today, Scala artifacts are now available directly from Central. The contents of scala-tools.org are now integrated into the Sonatype OSS repository hosting service, and other projects have started to publish artifacts Central.

The Scala community will see immediate benefits from this move. There are no more extra repositories to configure. It just got incrementally easier to use Scala. If you are new to Scala, you don’t need to reconfigure your repository manager to proxy another remote repository. The community will benefit from Sonatype’s continued investment in the infrastructure that runs Central: a cluster of machines in both the US and the EU continuously monitored by a dynamic DNS server that can reroute traffic instantly in the event of downtime.

How did this happen? Joshua Suereth, David Bernard, and Derek Chen-Becker provided the bulk of the administrative work, and they recently decided to decommision this server and transition repository hosting to the free Sonatype OSS service. Here’s the announcement by Joshua Suereth to the user forums on scala-lang.org on January 17th:

Scala-tools.org is going down and not accepting any new OSS projects. For those of us who wish to continue release software, I recommend migrating over to Sonatype. They put a few (good practice) limitations on contributions, but scala-tools.org would have done the same before long anyway. The benefit of Sonatype hosting is that your projects will make it onto the maven-central repository and benefit from the myriads of mirrors. Here’s the link for how to get started contacting Sonatype: http://nexus.sonatype.org/oss-repository-hosting.html Publishing Your Scala Project to Central via Sonatype OSS

If you maintain a project that previously published to the scala-tools.org repository, here are three resources that provide guidance for Scala developers looking to publish Scala artifacts to Central:

• Publishing artifacts to Sonatype instruction written by Joshua Suereth on publishing to Sonatype OSS
• Publishing SBT Projects to Sonatype OSS from Cake Solution’s Specs2 Spring Project
• PublishToSonatype.scala some Scala code from Paul Phillips to automate the process of publishing artifacts to Sonatype’s OSS

CloudBees is proud to be sponsoring the 7th Annual Philly Emerging Tech Conference, April 10 & 11th in Philadelphia. If you're in the vicinity, check out this popular conference, hosted by our friends at Chariot Solutions. It sells out most years, so don't wait to sign up for this 2-day, 5-track technology extravaganza.

The Emerging Tech Conference (a.k.a. Emerging Technologies for the Enterprise) covers topics ranging from Java EE in the cloud to the Play Framework to cross-platform mobile development to NoSQL to HTML5 to functional programming patterns. Check out the full session list here and the list of expert presenters here.

The Early Bird rate of $375 per person is available through February 15. If you can take advantage of the group discount -- 4 colleagues or friends, not necessarily from the same company –- register at the same time and the price drops to $281.25 per person.

Sessions covering a wide array of technologies complement the Java and JVM-based focus. In addition to keynote speakers Chad Fowler (VP Engineering, LivingSocial) and Alex Payne (CTO, Simple Finance), the conference features Yukihiro Matsumoto (creator of the Ruby Programming Language); Douglas Crockford (Senior JavaScript Architect, Yahoo); Yehuda Katz (Ember.js and jQuery core developer); Elika Etemad (W3C CSS Working Group); James Shore (author of The Art of Agile Development); and many others. Keep an eye on the site, because more speakers and session abstracts will be added over the next few weeks.

Register and attend!

Introduction

Setting up Git can be intimidating, especially for those that are trying a version control system for the first time or moving from Subversion. It used to be the case that Git was a huge hassle to install and use on Windows. However, nowadays it's super easy to use Git on Windows either through Git Bash, if you're a fan of the command line, or if you prefer a graphical interface, through programs like TortoiseGit. Below we'll show you how to set everything up and connect it with Assembla.

Note: Below is a condensed version that doesnt show EVERY screenshot along the way. For the long version, click here.

Table of Contents

1. Download and Install Git for Windows
2. Download and Install TortoiseGit (Optional but recommended for first timers)
3. Generate SSH keys
4. Link SSH key with Assembla

Prerequisites

1. Assembla Git repository - sign up if you haven't already, it's totally free for standalone Git hosting.
2. A strong desire to install Git on Windows.
3. That's it, let's go!

1. Download and Install Git for Windows

To get things started, you'll need to download and install Git for Windows. You can download it here. If you're unsure of which one to choose, just go with the full installer. After downloading, run the installer.

 
If you have PuTTY/TortoiseSVN installed, you may see this screen, otherwise just ignore this. Regardless, use OpenSSH to make things easy. 
 

Download and Install TortoiseGit

This step is optional. If you are comfortable using the command line for interacting with Git, you do not need to install TortoiseGit.

Next up, let's download and install TortoiseGit.
 

We'll need to configure TortoiseGit - to do this, right click anywhere on your Desktop, select "TortoiseGit" and then "Settings."


Find "Git" and then click on "Config" from the menu on the left. Then fill in your Name and Email, making sure to use the same email that you used to sign up for Assembla.

Don't forget to click OK when you're done.
 


Great, now TortoiseGit is all set! Generate SSH keys

There's two ways to generate SSH keys:
  1. If you installed TortoiseGit, use the method directly below. 2. If you only installed Git on Windows and are not using TortiseGit, jump to the "Git Bash SSH Keys" section.

TortoiseGit SSH Keys

SSH creates a secure connection from your computer to Assembla, making sure that you are who you claim to be so that only authorized persons can commit to your repository. Assembla needs to know your public SSH key to make the secure connection, so let's fire up Puttygen to generate an SSH key pair.

Start -> Programs -> TortoiseGit -> Puttygen


In Puttygen, first click on the "Generate" button.


Next, you'll move your mouse around the big gray area under the progress bar to generate randomness for super security.


Once the key is generated, you should copy it onto your clipboard. You'll use this later to authenticate with Assembla.


Afterwards, choose a memorable password and confirm it. Don't forget your password!


Lastly, click on the "Save private key" button and save your private key somewhere you'll remember.

Git Bash SSH Keys If you did not install TortoiseGit, you're at the right place! If you did install TortoiseGit, follow the steps above and skip this section.

• Start up Git Bash: Start -> All Programs -> Git -> Git Bash
• On the command prompt, type in the following command substituting with the email you used to sign up for Assembla.
• When it asks you for the file, just hit Enter.
• Please note that you should definitely enter a passphrase; when you type, nothing will show up. This is normal, don't worry about it.

ssh-keygen -t rsa -C "me@email.com"

Use Notepad to open up the .ssh/id_rsa.pub file you just generated and copy the all of the contents of that file.

Link Your SSH key with Assembla Open up your Assembla profile which is where you'll paste the public key you just copied from the previous step. 
 
Click "Add Key" after you've pasted the key into the box. You should see something like the following picture below. If so, congratulations, you're done with this section!
  Create Something! Now the fun begins! Click here to learn how to clone your git repository, add files, commit, and push.  
Stuck? Need help? If you encounter difficulty with any of this, don't hesitate to contact Assembla support.

Every once and awhile, when there’s nothing topical to blog about, I decide to go back in time and focus on a software testing classic. Today is one of those days.

With that in mind, I wanted to draw your attention to Classic Testing Mistakes by Brian Marick. Whether you’re a tester or manager, experienced veteran or wide-eyed newbie, this 25-page article outlines some of the most classic testing mishaps and offers valuable tips on how to avoid them.

So what are some classic testing mistakes? One would be not reading this document in its entirety. As for the others, here are a few clips I found interesting. Note the bold titles are mine, everything in italics in Brian’s.

Mistake: Testers Not Responsible for Usability
If usability problems are not considered valid bugs, your project defines the testing task too narrowly. Testers are restricted to checking whether the product does what was intended, not whether what was intended is useful. Customers do not care about the distinction, and testers shouldn’t either.

Mistake: Misunderstanding the Role of “QA”
A first major mistake people make is thinking that the testing team is responsible for assuring quality. This role, often assigned to the first testing team in an organization, makes it the last defense, the barrier between the development team (accused of producing bad quality) and the customer (who must be protected from them). It’s characterized by a testing team (often called the “Quality Assurance Group”) that has formal authority to prevent shipment of the product. That in itself is a disheartening task: the testing team can’t improve quality, only enforce a minimal level. Worse, that authority is usually more apparent than real.

Mistake: Bad Timing on Load Testing
Putting stress and load testing off to the last minute is common, but it leaves you little time to do anything substantive when you discover your product doesn’t scale up to more than 12 users.

Mistake: Relying on Beta Testing
Beware of an overreliance on beta testing. Beta testing seems to give you test cases representative of customer use – because the test cases are customer use. Also, bugs reported by customers are by definition those important to customers. However, there are several problems:

1. The customers probably aren’t that representative. In the common high-tech marketing model4, beta users, especially those of the “put it on your web site and they will download” sort, are the early adopters, those who like to tinker with new technologies. They are not the pragmatists, those who want to wait until the technology is proven and safe to adopt.

Mistake: Having Programmers Test
Using testing as a transitional job for new programmers is one of the two classic mistaken ways to staff a testing organization. It has some virtues. One is that you really can keep bad hires away from the code. A bozo in testing is often less dangerous than a bozo in development. Another is that the developer may learn something about testing that will be useful later. (In my case, it founded a career.) And it’s a way for the new hire to learn the product while still doing some useful work.

Mistake: Testers Not Domain Experts
Be especially careful to avoid the trap of testers who are not domain experts. Too often, the tester of an accounting package knows little about accounting. Consequently, she finds bugs that are unimportant to accountants and misses ones that are. Further, she writes bug reports that make serious bugs seem irrelevant. A programmer may not see past the unrepresentative test to the underlying important problem.

Mistake: Poor Bug Reporting
It’s not enough to find a failure; you must also report it. Unfortunately, poor bug reporting is a classic mistake.

Mistake: Unrealistic Expectations
Whatever approach you take, don’t fall into the trap of expecting regression tests to find a high proportion of new bugs. Regression tests discover that new or changed code breaks what used to work. While that happens more often than any of us would like, most bugs are in the product’s new or intentionally changed behavior. Those bugs have to be caught by new tests.

What other common testing mistakes have you experienced? Please share in the comment section.

Overview
Jenkins is a highly extensible platform and, in some cases, plugins are the foundation for further plugins.

One such example is the plugin for static code analysis. This plugin provides the necessary foundation for reporting and presenting of static analysis produced from building jobs, but does not in and of itself do any analysis. That is the responsibility of additional plugins which analyze files in the build workspace, such as source code and, if appropriate, the results of building that source code.

For example, there is the FindBugs plugin, that runs FindBugs which looks for bugs in Java code. FindBugs is an excellent utility for identifying problems in Java code. Combine FindBugs with Jenkins and those problems can be easily viewed, monitored and tracked over builds.

However, this blog entry will focus on two other static analysis plugins: the Task Scanner plugin; and the Warnings plugin.

Stable Release Versions
The latest release of the Task Scanner plugin is 4.26 and was released in December 2011. It has no known issues. The latest release of the Warnings plugin is 3.27 and was released in January 2012; it has known issues.

Requirements for Plugin-Use
Jenkins 1.409 or newer and the utility plugin "analysis-core" (called "Static Analysis Utilities").

How to UseThe Task Scanner plugin will scan the workspace for files and check if lines in those files contain certain strings or tags.
I created a job on Jenkins to build Jenkins and configured the Task Scanner for the job as follows:


after building, the results can be viewed by clicking on the "Open Tasks" link on the left hand side of the screen:


We can observe that the Jenkins code base has 15 high priority tasks ("FIXME"), 330 normal priority tasks ("TODO") and 425 low priority tasks ("@deprecated"). It is not surprising that there are so many @deprecated tasks, Jenkins has maintained backwards compatibility for a long time.

Given a particular task, it is possible to drill down and view the source:



The (Compiler) Warnings plugin can scan, using selected parsers, the build console log and workspace files and report compiler warnings. There are many parsers, if Cobol is your language of choice (or not as the case is highly likely to be) there is a parser for that.

In this case, I have configured the previous Jenkins job to scan for compiler warnings in the console log:


To ensure that such warnings are generated by the Java compiler, I need to tweak the Jenkins pom file:
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.3.2</version>
<configuration>
<showDeprecation>true</showDeprecation>
<showWarnings>true</showWarnings>
<source>1.5</source>
<target>1.5</target>
</configuration>
</plugin>After building, a summary of the results can viewed from the build status page:


The plugin detected 213 warnings. Notice that the status of the open tasks from the Task Scanner plugin are also displayed.

A summary of the warnings can be viewed by clicking on the "Compiler Warnings" link on the left hand side:



Looks like some classes in the Jenkins core module could be cleaned up to use non-deprecated features. Drilling down we can see where certain deprecated features are used. For example:



As presented these plugins are rather useful to track tasks and warnings in source code. They are quick to set up, even for a large project such as Jenkins.

Finally, the results of both the tasks and compiler warnings can be combined with the Static Analysis Collector plugin. Combine it with the DashBoard View plugin and a summary can be presented:


How to Use the Plugins on DEV@cloud/RUN@cloud?All plugins previously mentioned are available to install on a DEV@cloud Jenkins instance on CloudBees' Platform as a Service (PaaS) and they may be used in the same manner as with any other Jenkins deployment.
Relevant Documentation

• Static code analysis page
• Task Scanner plugin page
• Warnings plugin page
• Static analysis collector pageCollector plugin
• DashBoard view page

--Paul Sandoz, DeveloperCloudBeeswww.cloudbees.com

The increasing adoption of mobile applications as part of a company’s online services leads to the question whether we need to monitor like other parts of our IT infrastructure. As they are part of our shipped application services we need to ensure they are working properly. However, not every application must be monitored the same [...]

Selenium Tutorial for Beginners Selenium is an open source technology for automating browser-based applications. Selenium is easy to get started with for simple functional testing of a Web application. I can usually take a beginner with some light testing experience and teach them Selenium in a 2 day course. A few years ago I wrote a fast and easy tutorial Building Selenium Tests For Web Applications tutorial for beginners.



The Selenium Tutorial for Beginners has the following chapters:

• Selenium Tutorial 1: Write Your First Functional Selenium Test
• Selenium Tutorial 2: Write Your First Functional Selenium Test of an Ajax application
• Selenium Tutorial 3: Choosing between Selenium 1 and Selenium 2
• Selenium Tutorial 4: Install and Configure Selenium RC, Grid
• Selenium Tutorial 5: Use Record/Playback Tools Instead of Writing Test Code
• Selenium Tutorial 6: Repurpose Selenium Tests To Be Load and Performance Tests
• Selenium Tutorial 7: Repurpose Selenium Tests To Be Production Service Monitors
• Selenium Tutorial 8: Analyze the Selenium Test Logged Results To Identify Functional Issues and Performance Bottlenecks
• Selenium Tutorial 9: Debugging Selenium Tests
• Selenium Tutorial 10: Testing Flex/Flash Applications Using Selenium
• Selenium Tutorial 11: Using Selenium In Agile Software Development Methodology
• Selenium Tutorial 12: Run Selenium tests from HP Quality Center, HP Test Director, Hudson, Jenkins, Bamboo
• Selenium Tutorial 13: Alternative To Selenium

A community of supporting open source projects - including my own PushToTest TestMaker - enables you to apply your Selenium tests as functional tests for smoke testing, regression testing, and integration tests, load and performance tests, and production service monitors. These techniques and tools make it easy to run Selenium tests from test management platforms, including HP Quality Center, HP Test Director, Zephyr, TestLink, QMetry, from automated Continuous Integration (CI) tests, including Hudson, Jenkins, Cruise Control, and Bamboo.

I wrote a Selenium tutorial for beginners to make it easy to get started and take advantage of the advanced topics. Download TestMaker Community to get the Selenium tutorial for beginners and immediately build and run your first Selenium tests. It is entirely open source and free!

There were many updates to our blog in January. Here is our monthly recap:

How I Use Surround SCM: Working Directory Differences –Learn more about enhanced working directory differences in Surround SCM 2012, and how they help one user remember to add new files to Surround.

Using Separate Configurations for Surround SCM Mainline Branches – Learn how to get more granular control over your mainline branches in Surround SCM 2012.

Naked Agile Helps Students Understand What Becoming Agile Really Means—The first of a three part series, this entry answers the question, “What is Agile anyway?”

Video: Calculating Risk Scores in TestTrack—This video demonstrates how to set up risk calculation fields in TestTrack 2012.

The All-New 2012 Seapine.com—Seapine’s redesigned web site includes new content and reworked site navigation to make everything easy to find. Check out the new layout and features!

Webinar: What’s New in Seapine ALM 2012—Join us on February 7 to see some of the over 100 new features and enhancements in  Seapine ALM 2012. There will be time to ask questions and learn more about specific features during the one-hour webinar. Register today!

Share on Technorati . del.icio.us . Digg . Reddit . Slashdot . Facebook . StumbleUpon

If you’ve worked in the software industry, chances are you’ve encountered words and phrases that you did not understand. I certainly have. So to help make sure we’re all on the same page (that means common understanding), I’ve decided to start a running thread of some of the more common slang terms that apply to software testing. Of course, this list will be woefully inadequate without your input, so please add your slang terms in the comment section below.

Here’s a few off the top of my head, as well as some that I found in this Quora thread:

• Dogfooding: When a company tests its own software internally before releasing to beta
• Low hanging fruit: Easy tasks that can be completed in short order
• WAG: Wild ass guess
• SWAG: Scientific wild ass guess
• Staging: A development enviroment; one level before production
• Automagically: Describes something that occurs in software that is either too complicated to explain, or the person describing the process really has no clue how it works
• Quick and Dirty: A quick and simple solution to an otherwise complicated problem
• Showstopper: A bug that makes software unusable
• Brown-bagger: A very embarrassing bug found soon after release
• Whack-a-mole: The practice of repeatedly getting rid of a bug, only to have it continually reappear
• Drink the Kool-Aid: Lacking objectivity
• Heavy lifting: Difficult and challenging work
• SoLoMo: Social, location and mobile – testing components of many mobile apps
• Burndown: a chart that is a graphical representation of work left to do versus time
• FUBAR: F#@cked up beyond all recognition
• PEBKAC: Problem exists between keyboard and chair (good one John Montgomery)
• RTFM: Read the F#$cking manual
• Fast-track: To speed up a process

Like I said, I’m certain that I’ve left out 99.99% of all the great testing slang terms. So please, pick up the slack (help me out) in the comment section below.

 

Hello Testers!     

We have prepared a new give-away for you! Help us build our Google+ page, so that we can reach out to you with you, start conversations, and share everything interesting you post. Add us to your circles. And let the fun begin.

To make things more interesting we are gifting one SQE Live Virtual Training, worth $599, to one of you who circles and shares the page before the end of February 2012. The SQE Live Virtual Training is a two day (3-hours per day) experience that will take you on a journey of your choosing: Performance, Load, and Stress Testing; Visual Models for Testing; Essential Test Management and Planning; Agile Test Automation; or any one of the others.

What you need to do? 3 simple steps:

STEP 1: Circle us on Google+
STEP 2: +1 our page 
STEP 3: Share with your friends

And speaking of trainings, what is the next topic you want to invest your time in? Leave us a comment!

The winner will be announced here on our blog on March 2rd. 

And then - on our Google+ page.

See you there!

We are excited to announce that we will be releasing an Android mobile test automation plug-in in the next few months.

This new plug-in will enable you to record your mobile tests on a real Android device and edit the recorded steps in the Ranorex Recorder, the same way you would do with any Desktop or Web application. The powerful recognition of the Android app's UI elements will enable you to play the tests on any Android device.

An easy-to-use Wizard will guide you through the process of deploying your Android app to the device, in order to start your first recording.

You will be able to record and execute tests over both Wi-Fi and USB connections. Testing over Wi-Fi enables you to easily run your tests from one Ranorex Studio on multiple Android devices.

Coming Up: Testing of SAP GUIBased on the flexible plug-in mechanism, the Ranorex tool set functionality grows constantly. We would like to introduce a new plug-in, which will enable test automation of SAP GUI controls. This new plug-in will be available online for download in the next few months.

While we've touched upon client side caching in our series on Web performance, we haven't discussed how client caching has grown more rich and useful over the years. In the initial days of the Web and the HTTP/1.0 protocol, caching was mostly limited to a handful of headers, including Expires, If-Modified-Since, and Pragma: no-cache. Since then, client caching has evolved to embrace greater granularity. Some new technologies even permit the deployment of offline-aware, browser-based applications.

Browser Request Caching

The most common and oldest type of client-side caching on the client is browser request caching. Built into the HTTP protocol standard, browser request caching allows the server to control how often the browser requests new copies of files from the server. We discussed the major aspects of browser request caching in part 1 of our series. Over time, Webmasters have taken to using different headers to improve caching on their site, including:

Pragma: no-cache. This old directive is used mostly by HTTP/1.0 servers, and instructs a client that a specific response's contents should never be cached. It is used for highly dynamic content that is apt to change from request to request.

Expires. Supported since HTTP/1.0, this header specifies an explicit expiration date for cached content. It can be superseded by the value of the Cache-Control header. For example, if Cache-Control: no-cache is sent in a response, this will take precedence over any value of the Expires header.

If-Modified-Since: Since the HTTP/1.0 protocol, clients have been able to use this header to request that the server only send data if the resource has been changed since the specified date. If there have been no changed, the server returns an HTTP 304 Not Modified response.

Last-Modified. This HTTP/1.0 and 1.1 header designates when the resource was most recently changed. Browsers usually supply this value as the value of the If-Modified-Since header.

Cache-Control. This core directive, introduced in the HTTP/1.1 standard, specifies whether a response's contents can be cached, and if so, for how long. The header "Cache-Control: no-cache" obsoletes the "Pragma: no-cache" header of the HTTP/1.0 protocol.

ETag. The ETag ("entity tag") header is a hash value that is specific to a given version of a resource. It can be used by the client in conjunction with the If-Match, If-None-Match, and If-Range headers to decide whether it should generate a new request for the latest version of a resource. The format of entity tags themselves is defined in section 3.11 of RFC2616.

Note that this header and the Last-Modified header are exclusive; servers should set one or the other. The ETag header is new with the HTTP/1.1 protocol standard.

For modern applications, the good folks at Google recommend setting one of either Cache-Control or Expires, and one of either Last-Modified or ETag.

 

Javascript/AJAX Caching

With the advent of JavaScript and AJAX, more Web applications are downloading data dynamically. JavaScript developers can use the XmlHttpRequest object to fetch data in XML (or other) format, and display it in real time without forcing a refresh of the entire page. This presents opportunities for finer-grained caching based on the nature of the data displayed within the page.

AJAX applications can still use all of the browser request caching mechanisms discussed above. The resource requested by the XmlHttpRequest object will be stored in the browser's file cache just as other HTTP objects are. A given AJAX application can go further and make refresh calls to the XmlHttpRequest object using programmatic rules. In his article "An AJAX Caching Strategy", Bruce Perry shows how he uses a custom CacheDecider object that he wrote in JavaScript to determine when to update an AJAX display of oil, gasoline, and propane prices.

 

HTML5 Caching

Developers creating HTML5 applications can create fully offline-aware applications using the HTML5 ApplicationCache interface. The Application Cache uses a cache manifest file to specify which files in an HTML5 application can be used offline, and which files require a network connection. The manifest may also specify a list of fallback files for network resources when the user is offline. For example, instead of fetching the file /get-data.php when disconnected, the manifest can instruct the browser to display the file /offline.html instead. This manifest is referenced in the HTML element of an HTML5 app:

<html manifest="manifest.appcache">
...
</html>

 

Conclusion

Web performance optimization is very important, and today's Web application development team can boost site performance and improve its site's load testing scores by selecting from a variety of client side caching techniques. An effective client side caching strategy can reduce load times by several factors. The most recent innovations in client side caching, such as the HTML5 Application Cache, enable an application to run (though perhaps in a more limited form) even without a network connection present.

The 2012 San Francisco Selenium Meetups kicked off last week with a great talk by Denali Lumma (@denalilumma), who is the QA Lead at Okta.

Okta, an on-demand identity & access management service for cloud/SaaS applications, is notable for that fact that they manage to keep 1,000 Selenium Tests 100% blue – and they don’t use any manual testers. To get an inside look at how they accomplish this impressive feat, take a look at the video below.

For more info about the San Francisco Selenium Meetups and to join the group, visit our meetup.com page. And for help with starting a Selenium Meetup in your own city, check out my blog post on the subject :-)

When a website is placed under heavy load, it can fail in a wide variety of ways. The site may become unresponsive or return an HTTP status code indicating an error (500). Or it might return a web page that is mostly complete (the headers, footers and navigation are all present) but is missing a critical part that was related to the failure. If the load test scenarios (testcases) do not validate page content well enough to catch these problems, the results could be misleading. I.e. the system could be failing but the results indicate success. In the process of helping … Continue reading »

Over the course of the past few years, I’ve interacted with hundreds of people when talking about build tools and repository management.   It continues to surprise me how many people don’t realize where these artifacts come from.   When you run a build and these JARs just show up alongside all of their dependencies, it’s like magic to most people.     If you know how it works, it’s very obvious to you that running a repository manager is the right thing to do.  This post is a reminder to everyone using build tools that rely on Central: take time to proxy Central with a repository manager.

“Wait, that’s how Central works?”

There’s something so automatic about dependency management in Maven that it often takes people a few months to understand exactly where those JAR files are coming from. In an 8 hour Maven class, I get to dependencies in the third hour, and after describing Central, what it is was like before Central, how metadata is stored in a repository alongside binaries, transitive dependencies, etc…. it all falls into place, and people realize that this simple thing they’ve grown accustomed to is only easy because of a ten year effort to refine the model, the creation of a support structure for source forges at places like Oracle and Google, and a constant investment in infrastructure.

On the one hand, it’s a great success that Central is, for the most part, an invisible utility that supports developers.  On the other hand, it’s the kind of thing that people can start to take for granted very easily.

For example, a few months ago I spoke to someone who worked in an environment disconnected from the internet for security reasons.   This individual was talking about how limiting it was to have to download JARs from open source projects manually and assemble them in a project.   His words were: “It’s like programming Java in 2001 again.”

How can you help?

Imagine millions of developer spread all over the world: different time zones, different applications, but they all hit the same service: Central.    Some regions have more developers than others so we certainly see peaks in usage throughout the day, but in general, Central’s serving thousands of files throughout the world at any given time during the day.

Maybe someone just installed Maven for the first time, or maybe they blew away a local repository, with numbers like these we see a world that has a constant appetite for artifacts.   It isn’t a problem for Central, and I’m not writing this because Central is falling down on the job. Central can handle it, but it certainly isn’t the most efficient way to support millions developers.  It isn’t a good use of network bandwidth, and it isn’t a good use of energy to constantly cart around the same static JARs over and over and over again when the solution is so easy.

If everyone who used a build tool that interacted with Central adopted a repository manager such as Nexus we’d have a faster, more responsive system.   Central’s maintainers would be focused less on addressing the occasional runaway build and could spend more time and resource on increasing availability and functionality of this essential service.

Broken Builds

The other factor playing into this is that Maven builds only download releases once.   It isn’t like these build tools are repeatedly returning to Central to download release artifacts over and over again.

Well… actually… that isn’t true, we’ve seen some installations of Hudson configured to delete a local repository before every build placing a high load on Central.   Imagine a build that downloads 50 MB of dependencies running once every 5 minutes.  That’s one build consuming ~14 GB a day never mind the time wasted downloading static artifacts. While these broken builds are the exception, they do still show up from time to time.  Central can handle the load, but imagine 1000 of these broken builds running continuously and you can see the challenge.

A Simple Reminder: Please Proxy Central

We’re constantly watching the performance of the system and making sure it stays up and running for an entire world of developers.  If you use a build tool that hits Central whether it is Buildr or Maven or Gradle or Ivy, you can help us by running a Nexus instance.

Even if all of your builds work perfect, running a local Nexus instance helps preserve Central as a public, free resource and it will lead to faster, more responsive builds.