Over the last 2 weeks I have be fortunate enough to pair with Simon Cropp for about 8 hours on my open source project ApprovalTests.  Simon has taught me a lot about running a better open source project, this blog is an attempt to share some of that for those not fortunate enough to be able to pair with Simon themselves.

Think about your 'brand'Often I am writing ApprovalTests because I use ApprovalTests myself. I am happy that others find it useful as well and believe in sharing and open source, so I also make it an open source project. However, all of my thinking goes into after a programmer has it on their computer. However, there is a lot of things that happen before someone has ApprovalTests on their computer. Most of what I am about to talk about is specific to this area of open source. In the 8 hours we paired, we spent surprising little time actually programming C#.

It works on my computerI believe this is particularly harder with .Net than other languages. There were many things that I just assumed everyone had because I never thought I did a special installed for them. Some of these were libraries that were put in my Global Assembly Cache (GAC)  by VisualStudio (2010) but not by (2012). That means adding .dll's which means configuring git.
Git and binary filesI really wish then was a simple header to all files indicating that they are a binary or text file. There isn't. This becomes an issue with git, so if you are checking in binary files, you need to set your .gitattributes to include them. For example,  I added the following to my .gitattributes:
#Binary*.dll  binary*.exe  binary*.png  binary*.tif  binary*.tiff binary*.snk  binary*.ttf  binary
If you don't do this as soon as someone clones your repo, there will already be changes.
Removing Cruft I'm pretty good about cleaning my code, but what about my project in general? All though references you don't use anymore? That Silverlight experiment? Even dll's that are in your project but no longer referenced by your project. All of that makes it harder for someone else to clone and play with your source.
ConsistencyThis project started before nuget, so there were dll's that were added directly that now should be added by nuget. It's hard to remember the advantage of consistency in a project, especially as it is not bothering you. This is a double edged sword with pairing. On the one hand it's easy to code because you have your environment setup plus already know the tricks. On the other hand, it masks trouble that a lone programmer will have with your source.
Version Numbers and Signed CodeThis is a long post, but the short version is that in the end I followed JSON.net's model for version numbers. This means that while the nuget version number will increase, the version number for ApprovalTests will now remain at 1.22 for all time. Because I sign ApprovalTests, this allows me better compatibility with other software.
Version Numbers & Simple Builds
An other problem was getting a single place for the version numbers. This required a bit of awesome hacking on Simon's part.  Here's the high level view

1. create a solution level file for the version number
2. add it to packages via link (there is a drop down on add)
3. Manually change your .csproj file to move it into your properties folder
   Properties\VersionInfo.cs
4. Use this when creating your nuget with the -Version flag

If any of this was confusing checkout these files from my project: VersionInfo.cs , ApprovalTests.csproj, ApprovalTests.CSharp.nuspec, CreateNuget.cmd
1 .dll per NugetHaving more than one dll file in a nuget package is a bit counter productive since you now can't use only 1 of them. In my case I had 2, so now I have two nuget packages: ApprovalTests & ApprovalUtilities. Of course, ApprovalTest depends on ApprovalUtilities, but you can now use the Utilities on it's own, as originally intended.

Think long termOn the Internet things live forever. Whenever possible link to a domain you control that can move with you. When I started everything was on sourceforge, now I have moved to github and links I have posted will be broken because of that. That history that creeps into your project isn't just in you code. Your brand is the full experience. Blogs, videos, stackoverflow questions, packages, repos, code, api's. Try to make it still work 5 years from now.
More to come...This blog is already getting pretty long, and there is still much more Simon as got me thinking about. Here's my current todo list:

1. Continuous Integration Server - I'm a big believer in this on regular projects but it seemed like overkill when I was the only committer. I just had to remember to always run my tests. But there is an other advantage here. I keeps me aware of at least 2 machines, meaning it will be easier to think of other people who clone the repo.
2. Website - On top of moving the website to github, and using a static website generator like jekyll. I am also aware of needing to structure my website to guide people to Understanding the Code, Using the Code, and Browsing the Code. A very nice example of this in the NancyFx Page.
3. Documentation - This includes what goes in the blog vs into a wiki. The main difference being that wiki should be relevant next year, while a blog is relevant NOW and not so important next year.

Again, a super big thanks for all the help Simon has given me. I have paired with more than 50 people across the globe and all of them have been very helpful to me. Simon had a particular gift for understanding the branding of an open source project and was very patience working with me to improve ApprovalTests.

Conference season is in full swing, and we’re having a ton of fun attending conferences all around the world. Up next for us is JSConf next week from 5/29-31 in Amelia Island, FL. It’s JSConf’s 5th Year Family Reunion, and we’re excited to be participating! Adam will be doing an Appium workshop, and Seabass, Santi, and Ashley will be attending as well, so come by to get your mobile app set up and get testing with Appium! We’ll be live tweeting and blogging the conference, so even if you can’t be there, you’ll have a view into the action.

Definitely looking forward to some time on the beach!

There’s a lot to like about the technology space. Mainly, the innovative products and services that seem impossible just a short time ago. There’s also a lot to dislike about the technology space. Mainly, anyone that disagrees with you.

I’m talking of course about the tech rivalries that dominate the headlines, comments sections, and now, even television ads. But which rivalry is the most heated? I felt the only reasonably way to decide this was to put it up for a vote:

Note: There is a poll embedded within this post, please visit the site to participate in this post's poll.

Written by Tom Lounibos

February’s announcement of Dell’s move to go private got me thinking. The deal, put together by Michael Dell and Silver Lake Partners, is potentially worth $24.5 billion or more depending what type of impact disgruntled investor and take-over czar Carl Icahn has on its negotiations.

In the meantime, BMC has announced and closed a deal with two private equity firms worth $46.25/share in cash or $6.9 billion.

Who will be the next tech company to close the curtain on public investors … Compuware, CA or even HP? And why the move to go private?

GigaOM tells us that cloud is the disruptive force at work:

As more companies evaluate the economics of putting workloads on massive webscale infrastructure — outside their walls — they will buy far fewer servers and routers themselves. And as more corporate applications are delivered via software-as-a-service models there are fewer huge upfront software licensing deals. Instead payments are spread out across a year or three. There is also pressure on the massive enterprise service and maintenance fees favored by companies like Oracle.

“There’s a seismic shift afoot with enterprise software vendors as they move from traditional pricing and distribution models to OpEx, SaaS and cloud models. This means a financial disruption for many of them, not just BMC Software,” said Dana Gardner, principal analyst with Inter-Arbor Solutions and GigaOM PRO analyst.

Seismic shifts in tech seem to be a continuous exercise. This particular shift, driven by an ever-growing mobile / social world, is of such an EPIC proportion that even industry veterans have never seen one like it before. Disruption is being experienced at every layer (User, Device, Network, Infrastructure) of the technology stack. This means that these are not good times for the incumbents (public vendors) whose technology and business models are showing their age. They will need to evolve or die, and evolution is best done in private. Innovation can be a messy business for even the most confident investors. It has many highs and lows, which makes it difficult to be watched by a glaring public eye. And so going private has become the new black in tech.

Nor is it just Dell and BMC. Other companies such as Compuware, HP, IBM, Oracle and Microsoft have angry shareholders who are unwilling to face the fact (or do not yet grasp) that the evolving product set and buying pattern means that profitability models are shifting, too.

Nor is it just tech. Berkshire Hathaway and 3G Capital are spending $23 billion to acquire HJ Heinz Co. in what is thought to be the largest acquisition in food industry history. Best Buy and Barnes and Noble have been mentioned in the press as considering going private.

What does this shift to private mean for all the newly minted private tech companies that dream of someday going public? Time will tell, but one thing I’m sure of in tech is that those who innovate faster typically win!

First, thanks for your thoughts, prayers and concerns after the tornado this week. I helped a friend go through the rubble of her former home on Monday. It was amazing to see her positive attitude. As we arrived at the debris, she said, "Welcome to my humble abode."

While there, she was interviewed by a Brazilian TV crew who also remarked to me how impressed they were with her attitude. Yes, that is inspiring, and many others here are also holding up well even in trying times.


 Also, thanks for those of you responded to the test professional survey last week. I ended up with 100 responses. I need a while longer to write the article (and perhaps white paper) on this, but I thought you might want to see some early results.



I am working on the article and should have it by next week. To me, the early impressions are that (at least to those that responded) the majority of testers see themselves as professionals and it is important to have that view. Management may not see testers as professionals as much, but there is still a significant percentage of managers that do find importance in the view of a test professional as opposed to some other view. I think this has some larger, and very good, implications for those of us in the field of software testing.

More to come soon. Of course, I would love to get your thoughts on these findings.

For those in the U.S., have a great Memorial Day. Remember those who have given their lives for our freedom. Remember those who are rebuilding in Oklahoma.

Thanks as always for being the best at what you do!

Randy

Great conversations, insightful panels and keynotes, rows of innovative mobile brands… and J.Lo.

That’s pretty much what CTIA’s 2013 show entailed this week in Las Vegas. Here’s a look at a few things we loved about CTIA 2013:

• Sessions: It was easy to love the sessions this year. Day 1 started off with the “Apps Summit” featuring the latest trends in mobile and a lot of talk around development and design. All the sessions were great, especially “Making Commerce Mobile: Strategy and Trends of Mobile Commerce” led by Sharon Wienbar, member of the uTest board and partner at Scale Venture Partners. The panel was also led by Jake Ward, co-founder and executive director at Application Developer Alliance, and others. The session looked at the latest trends in mobile technology, as well as the challenges brought on by device fragmentation and the ever changing mobile landscape. Another favorite was on day two, and was led by Michael Facemire, Forrester Analyst. The session titled “Technology Solutions for Today’s Mobile App Development Challenges” addressed the variety in mobile technology, time-to-market demands, UX requirements and how to overcome all of these challenges.
• E-Tech Awards: A big highlight of CTIA was the 2013 E-Tech Awards. Attendees voted and an online panel of highly-respected industry experts, reporters and analysts ultimately judged the submissions on “innovation, functionality, technological importance, implementation and overall ‘wow’ factor,” according to the CTIA blog. We’re thrilled that uTest’s Labs’ app analytics tool, Applause, took home 3rd place in the Enterprise Solution – General Business category. Congratulations to Ericsson’s Connected Vehicle Cloud and GPS Dashboard LLC’s “Check in” App for Salesforce.com, which took first and second place – and to all the nominees!
• Cool Brands: The Sands Expo Center was packed this week, with never-ending rows of new and upcoming mobile apps, development tools and countless other types of brands in the mobile space. We had a great time chatting with folks near our booth in the Mobile Apps Pavilion such as Kodak Developer, CallSnap and Speakerfy, as well as all the hundreds of attendees who stopped by our booth to talk about the importance of in-the-wild testing.

So what was the absolute best part about CTIA 2013?

Maybe you won big on the black jack table, or took a gondola ride through the Venetian – but for us it was the continued power of mobile. Every developer, QA Manager, or business exec we talked to, and every keynote or session we sat in on, was further validation of how mobile continues to be the driving force behind brands of all industries and sizes. Businesses know that their app is their brand and source of revenue – and they also know just how important app quality is. We love that.

So there you have it. A big thanks to CTIA for putting on a great show. See you next time, Las Vegas!

A few weeks ago, on his jaunt around the US, Dylan gave a nice lightning talk on Appium at RailsConf in Portland. It was awesome, and he did a jig onstage! Check out the slides for a quick and dirty look into Appium.

Testing Native iOS Apps with Appium from Sauce Labs

Roy Osherove tells how his views have changed on several topics on .NET unit testing, such as: what is a unit? what isolation frameworks make sense? Property vs. Constructor Injection, things learned from the ruby world, and much more. Watch this video on http://www.techdays.ru/videos/6832.html

My last delivery gig was a great reminder about keeping the principles and values of the Agile Manifesto in mind. It was unlike any agile method that you would probably recognise.

We were building a prototype system to demonstrate the capabilities of a technical standard and the data that it contained. Our main stakeholders, both relatively non-technical knew the type of audience the prototype was intended to influence and making a technical standard come to life with an interactive prototype was our remit. We had free reign of how we worked, the technology we used but our approach consistently remained true to the agile set of values and principles – focused on value through the demonstration of working software in a collaborative and adaptive manner.

I think about how we worked at the end of the project, and it looked nothing like how we worked at the start of the project.

Communication was key

Our small team was highly distributed – our two stakeholders located in one part of Switzerland, two of our team members (mostly working) in Germany, one of our team members moving between London, Germany and the client and myself where, during one week was in London, Manchester and then Germany. We knew communication was going to be tough. Our first step was ensuring we kicked the work as a team together in the same place. We spent the first week working with a large variety of industry stakeholders, understanding their concerns, the issues the new standard was going to address, and trying to get into the heads of our own stakeholders about what they were trying to do. This time turned out to be essential in guiding our future work and helped us connect the “what” to the “why”.

With our high level of distribution, we knew that we would need to do multiple channels of communication. We started off with daily stand-ups using video conferencing software with our stakeholders, which later turned into daily showcases at some point to help us further plan more work. When one of our team members moved remotely, we even did daily afternoon stand-ups to ensure that we kept synced with any major shifts in the day.

We experimented with many forms of chat software early on. We tried google hangout (but it seemed to turn one of our machines into furnace), we tried group skype, we tried google chat and we ended up settling up on chatzy as a way of having a persistent chat. We evolved a protocol of trying to have conversations in the chat room, so that when our remote member came back from meetings with stakeholders, they could easily answer and respond.

We experimented (probably half-way into the project) with leaving our video conferencing software (GoTo Meeting) on when one of our members were remote so that it felt like they were in the room and they could see us in the room. A spare laptop (our build server) and a simple crate fixture to prop it up so they could see us worked well.

We gave up using a physical wall in favour of an online card wall (Trello) as a mechanism for sharing work. Our ability to concurrently edit/update that turned out a great way of capturing and sharing notes.

Daily planning and story-writing sessions

Our “stories” were small. Our technical team of two developers, a user experience/front-end designer could churn through a lot in this context (moving between 20-40 stories per week) and we worked hard to ensure that we identified and split stories based on new needs and feedback from our stakeholders.

When we first started off, we started off doing a story-writing session to tackle our initial user journeys. The first session, I remember being remote and we were still able to “sit down” as a group and do a brainstorm. We set aside fifteen minutes, and split in two sites (me remote) and the rest of the team in one place we all got index cards out and brainstormed potential user stories. I used the in-built video camera in my laptop to share my index cards and they did the reverse as we talked through each one via video conferencing software. At some point, further on in the prototype, we moved to a daily planning session where we’d capture ideas directly into our online card wall.

Continuous Deployment

We still had a small build pipeline into production with a handful of unit tests to sanity check our final product that would automatically deploy the latest build into our “production” environment. I’m not sure, but I would guess that we deployed into production at least twenty times a day (as a team) and our stakeholders were surprised to see the system evolve even as they were interacting with it.

Even during some showcases, we were able to fix small issues (such as wording, placement) and have it appear a few minutes later.

Automated unit tests for quick feedback and design

Given it was a prototype, we were clear we didn’t need to have as much automated testing in place for a system that would have a very short shelf life. For us, testing goes beyond validating the behaviour you expect to a mechanism to drive design. If it’s hard to test, there’s probably something about the design that needs to change. For us, our tests provided two mechanisms – fast feedback about when to address code smells, and the other was to validate the simulated data model that needed to represent “realistic data.”

Given the domain our prototype worked in, our clients needed a balance where they didn’t want any real examples, but they wanted “realistic” samples. This means that we ended up modelling our customer’s domain in a way that let us generate new datasets easily. As an example, when we needed to extrapolate a “points based system” based on constraints that someone ran a search by, we only needed to touch one class to generate data that we tested as quite realistic against end users of the system. Prices had a relationship between the brand of the product and class of service, and this was just as easily modelled. Our unit tests allowed us to evolve characteristics of our model before plugging in new inputs to generate different outputs.

Poly-skilling or anyone could fulfill any responsibility

We all took part in story-writing. We started off with our analyst taking care of tracking progress, but we quickly moved that responsibility to a developer so that they could better use of their time testing the system with end users, and distilling the feedback from the large number of sources.

Our user experience designer was fantastically competent as a front-end developer and even let us lonely developers have a go at reworking some icons that needed adapting based on user feedback because his time was better spent looking at overall flow.

We took time out as a group to take part in exploratory testing trying to find weird user-nuances, edge bugs compiling them into a google spreadsheet before working with our stakeholders to feed them back into work.

Everyone on the team had a go at facilitating retrospectives and organising the feedback sessions that gave us the steer on which further direction to move in.

As a team, we made sure that everything that needed to happen happened without being precious about who did it.

Continuous reflection and continual improvement

Although we held a small handful of retrospectives, they weren’t our only opportunity to improve. If someone wanted to try something, we gave it a go for a day and then worked out if we wanted to continue doing it. Some things died off if someone felt we weren’t getting value from it. Other things just continued on because it seemed to work for us.

Developing social connections in the team

One activity we used to kick off our team was also to be explicit about some of our natural preferences – such as what sort of chronotype we were.

I think one thing that worked really well for us was having lunch together when we were in the same location. Mostly this was in Germany, which has a culture of having a sit-down lunch rather than the grab-and-go culture in the UK. I think this helped us bond as a team, and we grew to know each other more, sense each other’s working preferences and just get a chance to know each other much more.

The idea of “Failure Demand” comes from systems thinker, John Seddon, who describes it as “unnecessary burden on the system.” By looking at removing failure demand on a system, you free up more capacity to focus on value added work. Much of failure demand also maps to the lead concept of “waste” although not all “waste” is the same as failure demand.

Some classic examples (and tell-tale signs) I see with companies include:

• Poor quality work – Features that are not tested, or well designed end up generating bugs. A smell to look for is lots of issues reported by end users. Lots of errors in production logs are also another great smell for detecting this.
• Features designed without thinking about User Experience – Without putting the end user of a system in mind, many organisations build functionality without exploring how/why an end user of their system will end up using it. Working with an effective user experience capability means simpler, clearer interfaces that help end users get the job done. Smells to look out for include interfaces that have too many additions or features added to it.
• Requirements solely driven by a Product Manager – Many organisations rely solely on the HiPPO (the Highest Paid Person’s Opinion) to drive requirements. Although a Product Manager role is still useful for other reasons, faster experimentation and data collection of testing hypothesis is of use. Look out for smells like long release cycles, date driven requirements, or large backlog requests of detailed “user requirements” specified by the Product Manager without real involvement or feedback from end users.
• Misunderstandings – As a software organisation grows, the communication channels significantly increase. When people do not validate their understandings with each other, they end up doing more rework than necessary. Depending on how complex the problem space is, using visual models, workshops that explore a certain approach and simply showing progress constantly (daily or weekly basis) help to resolve this.

What other examples of failure demand do you see? Please leave a comment.

We were trying to template google analytics and make it part of our requirejs setup. When we did what we thought was obvious to wrap it in a module and declare a dependency on it, it seemed to fail quite miserably.

The trick was that we missed that you needed to export a global variable. This means in the javascript file initialising google analytics we had to add the following code block

var registerGoogleAnalytics = function(accountId) {
  var _gaq = _gaq || [];
  if (window) {
    window._gaq = _gaq; // export as global
  }
  _gaq.push(['_setAccount', accountId]);
  _gaq.push(['_trackPageview']);

  // rest of google analytics initialiser script...
}

Some links that helped us working this out:

• https://productforums.google.com/forum/#!topic/analytics/-wzmrVpsOTo
• http://stackoverflow.com/questions/9738815/google-analytics-gif-request-not-sent
• http://productforums.google.com/forum/#!topic/analytics/MmT2237oOpA

Your favorite Butler will visit Israel on June 6 for the Jenkins User Conference Israel. More than 200 people have already registered to hobnob with other Jenkins users and eat like kings.

The agenda is up here. You’ll find a great list of speakers from Israel, Europe and the US to compliment a plethora of treats. There will be an ice cream break, fruits break, beer break and special chef lunch. And everyone gets a limited-edition JUC Israel t-shirt, designed by the t-shirt-design gurus at JFrog.

Featured speakers:

Kohsuke Kawaguchi, the creator of Jenkins (formerly, Hudson) and elite architect at CloudBees, will deliver a keynote about the current state and the future roadmap of Jenkins.

Hans Dockter, the creator of Gradle and the founder of Gradleware will speak about next generation build tool to CI server integration.

Fred Simon, JFrog's co-founder and Chef architect will share JFrog's vision of the future of continous integration in the cloud.

Many thanks to lead sponsors JFrog and CloudBees, who have put a lot of time and energy into organizing the conference. Thanks also to sponsors Cloudify and White Source for showing their support for Jenkins!

Register here.

Can't make it to Israel? Here are more Jenkins events:

• Moving to Continuous Delivery in the Enterprise – June 10, London
• Jenkins Meetup – June 15, Munich
• Jenkins User Event – September 6, Copenhagen
• Jenkins User Conference – October 23, Palo Alto, CA

Every company has a moment where they are forced to care, I mean, really care about Security and Privacy. Sure, you should always care in the back of your mind, but at some point it comes front and center and a key pillar of everything you do. The question is whether you are going to be ready for when it comes. Odds are, no. (Because if you were, you would already be caring.) I’ve seen this moment happen a couple times, so here is my list of things you now need to pay a whole lot of attention to.

First, Security and Privacy are related, but different. In hand-wavy terms; Security is related to keeping information in and the bad guys out, and Privacy is about individual people’s information in your trust. And it is a trust, not a right.

With that, here is my brain dump on the topics.

Security

• Who is the officially designated person for security problems?
• Physical security – padlocks on the cage, etc.
• Can people wander the office without being questioned?
• Is all input validated on the backend as well as the frontend
• Disarm all input
• Disarm all output
• Don’t blindly use user provided strings in queries
• PCI compliance?
• Don’t store your password in the clear…
• The first question about any change should be ‘what are the security ramifications’?
• Do security bugs get put into the main bug database?
• How are security things disclosed

Privacy

• Who is the officially designated person for security problems?
• Do you know what PII (Personally Identifiable Information) you have
• Do you know what flows the PII participate in?
• People need to be bucketed based upon their informational needs
• Don’t clone your production database down into lower environments — without scrubbing the PII
• Do not display PII to anyone other than the owner of it. (Unless they really need it.)
• PII should be encrypted in the database
• Thou shalt not grant access to the production database
• Log the stink out of access, including read, of things that contain PII
• The second question about any change should be ‘what are the privacy ramifications’?
• Do privacy bugs get put into the main bug database?
• How are privacy things disclosed
• What legislation around PII affect you? And in what jurisdiction? Is it where the head office is? Where the app is hosted? Neither?

Writing secure code is actually not that hard. We know how to do this. At this point it is really just sloppy code. But putting the people and process around how the code that is generated is hard.

This is just a quick off-the-top-of-my-head list, but the key thing to remember is that its not paranoia if they are actually after you. And ‘they’ are.

I just finished up a webinar entitled Production Monitoring: The Key Steps Towards Continuous Delivery, presented with Airbrake.io The webinar focused on how Production Monitoring is the most important process in any application, but particularly online applications when practicing Continuous Delivery.

 

The Key Points were:

• Continuous Delivery is not a process that I can define for you, rather its a goal.
• The Goal of being able to continuously deliver your code to QA/UAT or Production and react in real time to the results of the release.
• Iteration Planning is Stressful
• Confidence in Releases is Key to Automating Deploys
• Confidence in Code is Key to Moving Fast
• More Data and Less Stress

If you missed the webinar, you can view it above or watch it on youtube and/or download the slides.

At the end of the webinar, I was left wondering: How does Assembla fit into the Continuous Delivery Pipeline? Stay tuned, more to come.

To Learn More about Continuous Delivery checkout some of my other blog postings:

Continuous Delivery vs Continuous Deployment vs Continuous Integration 

Distributed Continuous Integration - Keep the Mainline Clean 

Avoiding Premature Integration or: How we learned to stop worrying and ship software every day

You ever have those really good ideas, create a product or website around it, and no one cares?  That is what is happening with the Custom Tab at Assembla.  It’s about my favorite tool in the stack there, since I can use it to extend Assembla functionality and tools without doing anything.  

Our team used to have a bunch of tools all over the place, New Relic for monitoring our application, Nagios for monitoring our servers, Jenkins for our CI, Kibana for log aggregation, and even a custom application for showing off our Developer stats.  We had documentation to let everyone know where each tool was.  It was tedious and annoying to keep up to date and inform everyone where to go next.

Instead, I put them in Custom Tabs:

Now, when we add a new tool to our stack, its immediately available and visible for all our developers to use from within the Assembla project.

Ideally you are able to use authentication integration so that being logged into Assembla also has you logged into the other service or tool removing the need to double login, but typically this is not an issue as you would have to login again for another browser tab.

We also just added the favicon as default to Custom Tab tabs, I hope you enjoy this feature as much as me. To try this out yourself, visit the Admin tab of your project > click on Tools > and Add the Custom Tab Tool. 

To Check Out More Cool Features and Tools - www.assembla.com

Cucumber.js is a version of Cucumber, the popular open source Behaviour-Driven Development (BDD) tool, brought to your JavaScript stack. It runs on both Node.js and modern web browsers. This talk explains how to use Cucumber.js to test a realtime-web application, drawing on experiences in testing Dashku.com, and give the audience tools and tips for how [...]

Fans eager to get their hands on the new album from acclaimed electronic music duo Daft Punk, “Random Access Memories,” a week early were in luck when Apple’s iTunes software recently released an inadvertent leak. The computing giant’s music store has helped promote many major albums in the last year by offering full-length, high-quality streams in advance of their release in an effort to combat piracy. However, due to a software security flaw discovered by 9to5Mac, Apple may have instead been enabling illegal downloads.

Since Apple does not hide or encrypt HTTP requests in iTunes, users could find the URL hosting the stream by using a URL scraping tool, 9to5Mac reported. Equipped with the URL, they could then go to the site to download the entire album for free and save it to their computer in high-quality MP4 format. Although DRM prevented users from playing it on other devices, the hole still raised some significant challenges for the company to address.

The economics of streaming
Artists such as Bob Dylan, Justin Timberlake and David Bowie have all had albums previewed as iTunes streams, and rock band The National was also debuting their album this way at the same time as Daft Punk. Artists generally opt to offer a stream in the hope that fans will go to iTunes to listen to – and possibly, as a result, pre-order – the album rather than downloading a leaked copy, 9to5Mac noted. While doing so might enable fans to rip a lower-quality version, the hope is that added exposure is more valuable.

In the case of Daft Punk, the album had already leaked, but such issues could raise broader concerns as Apple prepares to launch its iRadio streaming service with iOS 7. A tweak to secure the software and prevent such leaks will be important to maintain the trust of record labels with full catalogs of music available.

This problem recently occurred with popular music streaming service Spotify, with a flaw that The Verge dubbed “Spotify’s nightmare.” The publication reported that a freely available Chrome extension could be used to download a full, DRM-free MP3 file of any track being played in the company’s web player, which has been in beta since November but did not encrypt its file transfers. The extension was removed from Chrome’s Web Store and Spotify issued a patch, but the flaw briefly gave anyone access to download any song from the service’s 20 million song catalog.

With the economics of music streaming services still in flux and the music industry as a whole struggling to determine viable business models for the internet, ensuring that such tools do not offer built-in workarounds is essential. To shore up the software security of these types of applications and avoid leaks, programmers can use tools such as static analysis to catch potential errors and make their applications, in the words of Daft Punk, “harder, better, faster and stronger.”

Software news brought to you by Klocwork Inc., dedicated to helping software developers create better code with every keystroke.

If you use Jenkins and can be in Israel on June 6, don’t miss the Jenkins User Conference in Shefayim! Jenkins CI is the leading open source continuous integration server, with more than 61,000 active installations and more than 730 plugins that support building and testing virtually any project.
Join the community of Jenkins technologists dedicated to expanding their skills and moving the Jenkins platform forward. Jenkins project founder and CloudBees elite architect Kohsuke Kawaguchi will open with the keynote, flanked by other brilliant Jenkins supporters such as Hans Dockter, founder of Gradle and Gradleware, and Fred Simon, JFrog’s founder and chief architect.

More than 200 people have already registered, and our co-organizers at JFrog say they expect all 300 spots to fill up. You can see why – check out the awesome lineup on the agenda and the welcoming venue:


In addition, the food and drink will flow freely – there will be a fruit break, ice cream break, and beer break in addition to a special chef lunch. And everyone gets a commemorative conference tshirt.

Special thanks to our friends at JFrog for co-sponsoring JUC Israel with us (they’ve done a lot of the heavy lifting on this one)! And thanks also to sponsors Cloudify and White Source.

Register now!

If you can’t make it to Israel, consider these Jenkins events:

• Moving to Continuous Delivery in the Enterprise – London, June 10
• Jenkins Meetup – Munich, June 15
• Jenkins User Event – Copenhagen, September 6
• Jenkins User Conference – Palo Alto, CA, October 23

-- Lisa Wells
CloudBees Partner Marketing Bee & Managing Editor, Continuous Information

 

Follow CloudBees:
   

In Part I of this month’s Testing the Limits series, Jonathan Kohl talked the life of the Agile methodology, his relationship with and advice about mobile app testing, and how new and season testers alike can advance their skills and feed their passion.

Today, he’ll talk about the biggest hang-ups teams have when it comes to testing, how to overcome those hurdles, how he became a fan of “gamification” in testing and a few other words of wisdom.

********

uTest: When speaking or consulting on mobile application testing, what’s the most common question you encounter and what’s your answer?

JK: This is the question that comes up the most after people have heard me talk about testing on mobile projects:

“Is it true that we need to test on real devices, incorporate movement, and test out in the real world, outside of the office?”

My answer: “Yes.”

Mobile technology has been developed to support movement, and it has a lot of dependencies. For example: networking (while moving you change networks, technology, and encounter lots of errors or weak signal conditions), location services (all about movement and spending time in different locations), weather and environmental conditions (temperature and light have an enormous effect on how some apps work), and movement (the devices have movement sensors, and are interacted with using touch screens and voice control. Combining inputs and sensors getting triggered from movement can be tough for apps to handle.). I know of no tool that helps us sort that out without getting physical with the devices. Hopefully we get better ones soon that focus on mobile technology, instead of treating it like a small PC/web browser. 

uTest: You work a lot with startups, when there’s a shoe string budget how do you communicate the importance of testing and QA?

JK: A successful business requires execution on several dimensions, for example, understanding your customers and their needs, having a great product or service offering that solves real problems for people, having enough investment to enable you to deliver, and a strong grasp of your financials. These require different skills and focus, but there is an over-arching need to create value for your customers, and part of that is great customer service. Technology fits directly into that, especially as we view organizations through the window (screen) of a smartphone or tablet. A poor technology experience is another type of poor customer service, so there is a direct line there. If you let down your customer or provide them with a poor first experience (which we are finding is increasingly on mobile devices), you can lose them forever. So not only do we need to have great people skills and a good strategy for satisfying and impressing our customers in our human interactions, but in our technology interactions as well.

A lot of people don’t realize that we are evaluated on our ability to deliver on the technology front, and that technology is a major part of customer service. It fits into the customer experience, but also in our offering of a product or service. Does the technology help, or hinder? Do we have an awkward experience, or is it seamless. It also has an effect on investment and financials, even if it is indirect. A quality product and technology stack is vital to the success of a business over the long term, so we need to invest in ways to make sure that we meet our customer’s needs there as well. Good quality processes, development and testing are part of that, and we ignore them at our peril.

uTest: Part of your consulting work is to help teams adjust to methodology changes. What’s the biggest hurdle these teams need to overcome and how do you help them do that?

JK: Dealing with people issues – different individual people with different agendas, motivations and fears. On one hand, you have people who have bought the marketing of a methodology and think that it will cure all ills. On the other, you have people who are deeply threatened by the change the methodology represents. It is a difficult balance to reign in the exuberance and unrealistic expectations of one group, while encouraging the laggards to get on board and actually try it out. I spend a lot of time myth busting on both groups. The methodology will not make everything perfect (and it won’t work forever), but it will also not cause you to lose your job, or cause bad things to happen to you. I work with teams by doing – getting in there and demonstrating, and helping address their fears. If I can do it, anyone can do it.

It’s also important to help them be able to measure the success of their methodology adoption in real terms: better product, better customer service, saved costs, etc. Just measuring success on adopting a new process misses the point, and will lead to some difficult situations down the road, particularly if that new process isn’t helping you create value for you, for your team, for the company, and for your customers.

People issues are hard to cope with. They aren’t fun, and it means we have to confront people on difficult topics. However, healthy disagreement and healthy confrontation are good, healthy things. If we suppress conflict, it just goes underground. We reach peaceful solutions through negotiation and co-operation, not by suppressing them in a need to “be positive.” There is also nothing quite like trying something out and seeing whether it works or not. Evidence, generated by a team that is committed to getting results, not just in implementing a methodology change, is powerful, and helps build teamwork and consensus towards reaching goals. Talking is one thing, doing and getting feedback on how we are doing helps enormously.

uTest: You’re a fan of “gamification.” What drew you to this concept and why do you think it works?

JK: My colleague David McFadzean can take the blame for that. David and I were looking at various topics: using uncertainty factors and monte carlo simulations when estimating software projects, game theory ideas for helping teams organize their mix of processes, tools, technology and internal policies, and engagement, particularly with regards to mobile apps. I do work in mobile strategy, mobile app design and product management, and I was working on formulating my thoughts on mobile design and dependencies. David kept pointing out how I had used game theory ideas, or gamification ideas in my work without realizing it, so eventually I gave in and started looking at it more seriously. At first, I thought gamification was childish, but he urged me to look into it more deeply, and I was surprised at what I learned.

David is a video game enthusiast, so we started looking at video game design ideas and how they could be applied to a project we were considering working on. I then discovered Jane McGonigal’s book Reality is Broken, and I loved her game creation, the research she had done regarding video games, and her positive urging to help solve real world problems with games. I’m not sure she would agree with how I implement game concepts on software projects, and how I have worked to make software testing activities more like a game (she’d likely prefer we made a real game out of it, rather than gamify something else), but I owe a lot of my energy and inspiration in this space to her. I am drawn to her positivity and her challenge for us to do better things in our lives and to help harness collective productivity to solve problems.

It works because it is a powerful engagement model. Just look at how much time people play games on mobile devices. The game designers are tapping into something powerful, and they know how to develop great apps people want to engage with. Gamification when done well helps motivate people to return to use our apps over and over, and they feel drawn to the activities within the app. Games help provide intrinsic rewards – Jane McGonigal calls games “hard work that we like to do.” Many times, especially in software testing, we avoid the hard work because there is no inner motivation. We just have to do it because it is our job, or it is someone else’s job. I have had success in the past by making testing interesting and even fun on software development teams. It is not uncommon to work on teams I lead where everybody tests, and sometimes it’s hard to get people to do their other jobs like programming, analysis or project management because they are having fun testing.

Gamification isn’t the only engagement model, and because it became a bit of a buzzword, there is an enormous amount of bad gamification out there. But, if you take the time to analyze it systematically, determine that it will be a good thing to try in your software or system, and put the time in to create it from the ground up, it can be a useful tool.

uTest: You’re quite the prolific writer. What’s your favorite topic to write about – the one you never get tired of?

JK: Anything that helps people look beyond their current problems, to look at the big picture and inspire them to create great software. It’s easy for us to get caught up in good practices and tools, and forget about the people we are developing software for. While tools, practices, processes and things like that are very important, they should all serve our efforts to create great software. We often forget that and put other things ahead of that effort.

One thing I never get tired of hearing from people who read my work, is when it helps them. Especially if it inspired them to change their world for the better, even in some small way. That’s always my goal – to inspire people to do something better, and hopefully my experience resonates with them and they can enrich their own experiences by building on those ideas.

uTest: What new thing/trend/innovation are you keeping your eye on at the moment?

JK: I’m watching mobile or pervasive technology that utilizes movement (gestures, eye movement, etc.) rather than depending on keyboards and touch screens. This is a fascinating space, as devices become more embedded in our lives, and (hopefully) easier to interact with. It is also interesting to imagine the unintended or unwanted consequences. In many ways, we are just scratching the surface of what mobile technology can do for us. Mobile technology has taken a big step forward with smartphones and tablets, and network speeds and reliability are getting there, but have a long way to go yet. It reminds me a lot of the rise of the world wide web in the 90s. There is so much potential for fascinating tools, usage and effects both positive and negative on human behavior and interactions.

uTest:   Any brand new advice or words of wisdom that we can be the first to share?

JK: This is a tough question to answer. I think I will leave you with a thought about the lack of permanency in our industry, particularly with regards to software development processes. As a consultant I see a lot of people working very hard to implement a tool, practice or process change, expecting it to solve a lot of their problems. People will push to get something through, hoping for great success, sometimes sacrificing their health, their emotional well-being, and sometimes even political capital or their reputations to try to get adoption. While that particular solution may help, it won’t last forever. We need to adapt and change, and sometimes it really isn’t worth that personal sacrifice. If the team doesn’t want to adopt a tool or practice or development philosophy, there are most likely deeper issues that need to be addressed first.

The hardest problem to point out to people who are desperate for change is that no one solution will last forever. Everything changes, so this new state is not static and is not permanent. Once you have overcome this hurdle, there will be new ones. Many lottery winners have to go back to work, rock stars have to release an album and go on tour when their kids need an expensive university education, etc. There isn’t a lot of permanence in life, so we need to be open to adapting and changing. Getting to X, whatever X might be, is not a permanent solution. It’s just the best next step of a journey. This also applies to our software development processes. What worked last time may not work next time, so we need to carefully evaluate what we do on the basis of how it helps, and to be able to know when it isn’t helping us anymore. Implementing Scrum, buying a new productivity tool, or creating a fantastic new mobile app isn’t the end of the road for us. We haven’t arrived, it’s just (hopefully) the right thing to do at the time.

In this journey of life, we don’t really arrive until our journey ends at the end. Similarly, on software projects, if we get arrogant or complacent and think we have arrived and don’t need to adapt, we are probably already dead. We have to constantly change and adapt to new technology, to market and economic forces, to evaluate new tools, practices and processes and adapt our mix of those elements frequently, or else we will fall behind.

Exploratory testing is an approach to software testing that is defined as doing in the same activity application learning, test cases and test design and execution. In this article, Martin Jansson and Greger Nolmark propose to perform exploratory testing using a storytelling game format. This is a game where two or more persons collaborate on telling a spontaneous story. When you use storytelling for exploratory testing, the storyteller role is filled by the test lead, coach or similar function. The other software testers are the players. Software developers and business analysts ...