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 >>>

For testers like me, coding beyond batch/routine like scripting is a bit exotic in the main. In my experience most testers are doing VBScript on you-know-which-tool, maybe some Java on pretty much every tool as it’s the defacto language it seems. There’s a smattering of Python in use but the ardents seem few and far between. Then there’s fan boys like me doing some Ruby stuff all mixed with a smattering of other languages depending on the environment the tester works in.

I guess it’s more like doing testing which involves a bit of coding, instead of coding which involves a bit of testing. It’s great if your role involves you touching code at some point a few days a week. That way you can get your coding skills up and keep them up to. A lot of testers however are looking to start coding so they can develop professionally and of course utilise it for automation, testing, etc.

One problem I found was deciding which language to pick. So, simply put:

Step 1: Pick a language

There’s a multitude to pick from, the TIOBE index (http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html) is said in some circles to be worthless but if you don’t know what’s out there it’s a good start point for reference.

What are you using at your current workplace? What are they developing in? Well there’s your starter for 10. Is there a particular tool you want to get good at, which involves some coding? Bingo, go learn that then.

There are languages that are flipping everywhere. Java, PHP, VBScript, JavaScript, C, C#, C++ and of course the handy ones such as SQL and Perl that have been in utility use forever.

If you can, pick one that’s going to see you able to use it day to day, ideally one that those around you are competent in too. It’s easier to learn that way.

Step 2: Find learning Resources, make a plan

In order to learn you need to find some trusted sources of tuition, I’m assuming you’re doing self-directed study here and not going on a course. Have a look at www.codeyear.com for example, how about http://www.sqlcourse.com or just searching for “Learn [language] online” and see what comes up. There are too many resources to list but plenty to get started.

Create some form of learning plan and set yourself a goal as to how many hours you’re going to spend learning your chosen language. I picked 100 hours after a suggestion on the Software Testing Club. I have a goal but not a how-many-hours-a-week goal, I study when I can. If you can set time aside then great. Regarding a plan, simply list out what topics you want to learn and tick some off or add some more as you go.

Step 3: Share your learning

There’s nothing better than backing yourself up against a wall, putting yourself in a corner, etc. by telling the world you’re going to learn to programme. Head over to http://www.softwaretestingclub.com and start blogging about your plan and progress.

Also, have a look at www.codepad.org where you can paste snippets of code, then post the link in your blogs. Set up your free Github repository over at https://github.com, there’s an easy to follow tutorial there and it’s 3 commands day to day to maintain your library. Don’t forget to use the Wiki you get to document what you’re adding.

Overall…

Just get started, whatever you learn will be of use!

Good luck and I look forward to reading your updates.

Just shy of the end of 2011 I started to do ‘100 Hours of Testing Practice’ prompted by a post from Phil Kirkham over at the Software Testing Club. Find his post here: http://www.softwaretestingclub.com/forum/topics/100-hours-of-testing-practice

First question - does 100 hours feel a lot or a little?

It’s an odd one, if you think about how we do on average 40 hour weeks in work then it’s not a lot. If you think about how much time you get to spend on your hobbies/pass times/interests then it’ll take more than a few weeks to get 100 hours in! In those terms 100 hours is a lot.

Either way, that’s the goal that was proposed and that I’m working too. 100 hours which I’ve not decided to dedicate fully to learning Ruby ‘stuff’. By that I mean the Ruby language of course, as I’ve defined it ‘beyond simple scripting, but also automation, frameworks and tools using Ruby.

I decided a few years ago that Java wasn’t the language for me, I did a formal course with the Open University as part of my degree. It was OK, but didn’t get me excited, far too verbose even if it is admittedly ubiquitous and probably a good language to learn career wise. (never say never and all that…). Ruby got me excited, it seemed very learnable like Python but more widely used.

The Blog Posts

Since Phil’s post was essentially an invitation to participate I decided to do so and share what I’ve been doing over at the STC. Each member has a blog space provided so I’ve been blogging my adventures there.

I’m currently at hour 22 of 100 and will be officially ¼ the way through early next week. So, does it feel a lot in reality? Well, yes actually. It’s taken a good few weeks to get this far and on the way I’ve learned a fair bit. I’ve also uncovered a lot I want to look at too.

This is a side benefit, the extent of my ‘view’ on what resources, sites, blogs, books there are has increased. So has my hit list of things to look at!

A little Git!

One other side benefit too is I set up a public Github repository for the scripts I’m creating. Not only is it’s sensible place to put scripts but it’s another tool I’m learning along the way.

Have a look at: https://github.com/MarkCTest/Script-Bucket

Why not join in the fun? Read Phil’s post and get started on your 100 hours, then blog over at STC to keep everyone involved and yourself motivated!

Have fun!

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

I wish I could remember where I first read it because perhaps it deserves attribution.  But many years ago I read about the two world views of physicists and they resonated with me.  One world view is that prescibed by things like General Relativity and Maxwell's Equations.  These have, in some sense a great mathematical beauty to them.  This is the "the universe is made out of marble" viewpoint.  Nice clean fields.  Very solid.  Then there's the other perspective, this is the perspective you have in systems like Quantum Electrodynamics.  There are lots of particles flying all over the place and probabilities.  Lots of statistics.  The universe is a messy organic place.  It might have been tempting to take those people and lock them away or something but darn it if they didn't keep getting great results.  So Marble and Wood.  The highly regular vs. messier put powerful.  I soon started using this analogy in computer science and that's what I'm writing about today.

One place this comes up is when programming with promises, or really any notification system even ad hoc ones.  In the case of a promise the situation is that you have some work that needs to be done "later" after some asynchronous operation has completed:  let's say that you are waiting for some data and when it arrives you're going to validate and extract some values from it, it doesn't much matter.  The natural way to do this with a promise would look something like this:

p.then( () => {do your work} )

or in javascript you might write

p.then( function() { do your work } )

In fact you can keep combining these things, if you have more work that has to be done after the first batch asynchronously completes you might end up writing something like this:

p.then( () => {do your work} ).then( () => {do more work}).then( () => {even more work});

Now the next thing that's going to happen is you're going to put this in a loop for your various 'p' read operations that need to happen and presto magico your application is done.  And you've fallen into the wood trap.

The reason that I try to avoid this pattern is that what's happened now is that on every iteration you're creating delegate objects and new promise objects that connect the various stages for each operation.  But the thing is they're all the same!  Despite the fact that all the objects are being handled identically (typical) we get no savings, we are using the most general dispatch mechanism to dispatch the very same code thereby creating far more garbage than is needed.  Of course each one of these promise chains encourages the next guy to keep doing the same thing.  You could even add stages that merge, select, batch, whatever you need, more stages, more wood.

The hallmark of the wood pattern is that the same chain of dependencies/computations is re-represented in data repeatedly -- achieving no savings for its sameness.  It is the most flexible choice, each datum could be handled seperately in a unique fashion but they probably are not.

How can you make it better?

Well of course a different pattern alltogther might be the right choice, something that looks more like this:

datasource.handler += () => { do your work }

or maybe

w1 = new {worker stage one object }
w2 = new {stage 2 handler};

datasource.handler += w1;
w1.stage2 += w2;

Now this isn't as flexible but it is much more economical.  With one fell swoop we're saying that they are all going to be handled symmetrically and we do not have allocation cost per datum.

Even if that kind of refactoring isn't possible just this simple thing might be very helpful.

var d1 = () => {do your work};
var d2 = () => {do more work};
var d3 = () => {even more work};

p.then(d1).then(d2).then(d3);  // this in your loop

This second form avoids creating a whole new delegate/closure in each loop iteration so in some sense it's at least partly marblized. 

Now of course this kind of transform isn't universally possible but if you start by saying "what are the rules for all my data" and then encoding that then you tend to end up in a place where you have low-to-zero overhead costs for each item and you just do the work.  If you don't you can easily end up in a place where there most flexible pattern is being used in a very regular way, at great cost.

I've often admonished people to use the simplest programming technique that will do the job to get the best performance.  Specifically, don't use virtual methods if non-virtual will do.  Don't use interfaces if virtuals will do.  Don't use delegates if interfaces will do.  This discussion has in some ways been a rehash of that point.  But then I always found that grounding a concept in an example is helpful so hopefully you all found it worth the read.

P.S. I'm putting the "wood" programming technique in a bad light here but it has its place.  And that doesn't mean I'm down on "wood" physics.  I happen to think QED is every bit as cool as cool as relativity :)

j-hawk is a Java based open source framework which can be incorporated in your application for performance testing. The idea is you have to define *module and its tasks (means method) inside your application and register the same with j-Hawk. j-Hawk executes the modules and generates a graphical performance report which can be analyzed to find performance bottleneck of your application.

Package Changes Analyzer (PkgDiff) is a tool for analyzing changes in Linux software packages (RPM, DEB, TAR.GZ, etc). The tool is intended for Linux maintainers who are interested in ensuring compatibility of old and new versions of packages.

Tarantula is the test management Tool for agile projects. It has modern web user interface and many advanced features for efficient testing. Tarantula manages requirements, test set planning, case execution and reporting. Dashboard gives project managers a realtime view to current status of testing. Integrates with Jira, Bugzilla and Doors.

I recently joined the British Computer Society I also joined the BCS Configuration Management Group, and I’m now on the committee. To me it’s important to understand the place of CM on...

Visit The Build Doctor for the full article.

This video explains automatic client-side profiling of performance issue with Selenium 2 (part 1) and answers questions about the presentation (part 2). Slides of the presentation

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!

By James Whittaker

This will be my last post on this blog. Tomorrow is my last day at Google. It was a great ride and a great pleasure to work alongside such brilliant engineers. I will hand over this blog to another test director and then find a new place for whatever blogging I do in the future.

Follow me on Twitter (@docjamesw) if you are interested in where I land and to find my next blog outlet.

Peace.

I haven’t worked this hard in years. Sorry for the delay in posting anything. Accurev just attempted to make a corporate version of git. I think most of the enhancements that they’ve...

Visit The Build Doctor for the full article.

I will be talking about MVC and it’s environnement today at the OttawaCommunity.net in… Ottawa.

For those who attended, or about to attend, here are the slides that are going to be used:

The Slides

This video describes the six mechanisms in Visual Studio 2010 that enable more effective collaboration between developers and testers. These mechanisms include tools to create actionable bugs, debug historical events, and automate functional testing. Effective collaboration between developers and testers is paramount and can make the difference between shipping quality applications on time, or slipping because bugs are found late. Download video in other formats

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.

“As we were saying, up-front testing really isn’t testing at all. It is really up-front design through the analysis of our tests. Can we take this testing even further? When XP came out and suggested doing unit tests, many of us realized that if we combined a series of unit tests together, we could get the equivalent of automated acceptance testing.” “By the way, there may be certain arguments for not writing and maintaining a set of automated tests. We don’t think we would agree with them, or at least, in ...

AdaCore, provider of Ada tools and expertise for the mission-critical, safety-critical, and security-critical software communities, today announced the immediate availability of the GNATtest unit test harness generator for Ada. The GNATtest tool helps automate the essential, but tedious and error-prone, processes for developing and managing the large number of test cases that accompany the verification of large software systems. The task of writing and managing unit tests and their invocation framework is critical to the development of high-reliability software, but it is repetitive and cumbersome for large projects, and error-prone when ...

The Sonar team is proud to announce the release of Sonar 2.13. This new version includes 60 improvements, bug-fixes and also some new features that we believe are worth stopping your daily work for a couple of minutes to check out : ability to create manual reviews / violations anywhere in the code, ability to create action plans and an extended search engine.

Extended search engine

The search engine will now return not only projects but also modules, package and files. A picture is worth a thousand words :

Add a review on any piece of code

Whenever a quality defect is detected “manually”, the person who detected it has the ability to inject a violation directly into Sonar:

The related violation is then displayed within the source code and will be accounted for in metrics after the next analysis of the project:

Action plans

Action plans can be created to group reviews together.

An action plan can be associated to each violation

And then it is possible to review progress in a widget of a dashboard

Hotpots 2.0

The previous release allowed to use hotspot widgets in its own dashboards (see Sonar 2.12 in screenshots). It’s now possible to customize, rename or even delete the default dashboard named “Hotspots”.

Time now to give a try to the new version and to read the installation or upgrade guides.