In mid April, I was welcomed by the Seattle community to speak about Appium at their Mobile Development Meetup. In addition to having a great time and great conversations, there were some key takeaways from the meetup that are worthy of some thought. Of course, there’s not time to summarize all the amazing conversations that I had with the wonderful Seattle-ites, but here are the high points.

Mobile testing is more important now than it’s ever been. There are few things as painful as submitting your app to the app store, getting it accepted and published, then realizing that your app has a showstopper bug that’s getting lots of 1 star reviews. Of course, more testing would solve that problem, but testing everything manually is a long, slow process. So we turn to automated testing, but the situation there is little better. Between all the different frameworks (with different limitations), it starts to feel like you’re learning a new framework every time you want to write a test. So it’s back to manual testing… and the cycle repeats itself.

There’s a deep need for a cross platform testing tool. People are writing apps for Android and iOS now. Not just one or the other. And you’re probably being asked to test on both platforms. So rather than manually test on every device and OS you need to support, what can you do? You need a tool that lets you write your app so you can write one test and run it on many platforms. It was great to see people’s enthusiasm for Appium because it lets you run tests on iOS and Android.

Accessibility is not optional. This is a sticky issue for a lot of developers. On one hand, accessibility is a key technology for the web, and something we all ought to have in our apps anyway. On the other hand, it takes time to build in accessibility and your project was due yesterday. Tipping the scales in accessibility’s favor is the fact that nearly all iOS and Android testing tools use accessibility functionality in some way to automate the device. Much like the early days of browser automation, these labels and hooks are all that exist to allow for automating the device. So if you’re stuck on accessibility, remember that it makes testing your apps easier too.

Mobile Development is complex. If you’ve gone to a mobile meetup, odds are you left with your head spinning. Keeping all the frameworks, concepts, and tools straight is a full-time job, and you’ve got code to write! Don’t feel bad. The mobile world is complex and moves at an astonishing speed. It’s worth some time to get the basic concepts straight: Hybrid v. Native apps, the major app development frameworks, and the top testing tools (like Appium!).

Windows Phone and Firefox OS cannot just be ignored. While neither of these platforms has the market share to command a lot of attention yet, it’s important that mobile devs keep their eyes on the future. You don’t know what the market will choose as the next great platform, and it’s absolutely key to keep a strong awareness of what is coming in the future, and how you can write killer apps with great tests on that hot new platform. So important that Sauce Labs’ Jonathan Lipps spent his time at GTAC working with some Mozillians to hack Firefox OS into Appium.

Seattle’s mobile developers are amazing! I had some great conversations and spent the day after my talk hacking with some cool engineers, getting them set up to use Appium. Props to Carter Rabasa for setting up an amazing meetup. If you’re in the Seattle area, check them out!

By working together to create the set of tests and then determining where that testing belongs, we can increase efficiency, reliability and reduce debugging time for failures in the future. The test pyramid is an idea explained by Mike Cohn in his book “Succeeding with Agile”. Its main point is that you should have more low-level unit tests than high level end-to-end tests running through a GUI. Video Producer: http://aceconf.com/

Once again, you’ve helped us make this year’s annual survey the largest of it’s kind. 3500 of you participated in the latest survey of developers using open source. Your enthusiasm accurately represents the use of open source software in the survey findings:

• An overwhelming 86 percent of you stated that your applications are at least 80 percent open source with the remaining 20 percent custom components and code.

Organizations are reacting to this trend by providing development infrastructure that is designed to leverage open source components and frameworks (e.g., Maven, Hudson/Jenkins, Eclipse, Git, Nexus, etc.):

• 53% noted that they are standardizing on an open source development infrastructure stack.

But given the explosive growth in component usage – 8 billion downloads from the Sonatype Central Repository in 2012 represents an 800% increase in activity since its inception – it comes as no surprise that organizations are struggling to keep up:

• 76% of large organizations have no control over what components are being used in software development projects
• 65% don’t maintain an inventory of components used in production applications.

And since development is under extreme pressure to deliver applications fast while budgets are being cut, it’s also not surprising to see security taking a back seat:

• More than half of large organizations shared that developers don’t focus on security at all.

The good news is that Nexus users have a natural path to address these shortcomings – a strategy that we call Component Lifecycle Management. And we will soon launch a community relating to Good Component Practice.

But, lets’ get back to the survey.

 

The survey results are also available in pdf format here.

Let us know what you think about the results. What did you find surprising? What actions will you take?

And check back with us to continue the dialogue and to learn more about best practice approaches for managing your components.

Here is a presentation I did on an overview of the three main practices under the Agile umbrella, Scrum, XP, and Lean. PPTX available upon request.

http://testdrivendeveloper.com/content/binary/Agile%20Software%20Development%20Overview.pdf

XebiaLabs, the leading provider of Enterprise Continuous Delivery Automation, today announced version 3.9 of its Application Release Automation solution Deployit. The new release adds out-of-the-box support for additional middleware stacks and au ...

When it comes to integrating with, and depending on, third-party APIs in your business solution, you had better think twice of the implications. As Lorinda Brandon already pointed out in her “Safe...

In the following post, guest blogger Lucas Dargis outlines several reasons why he believes testers should use requirement documents for checking purposes, but should not rely heavily on them for testing. Lucas Dargis is a software testing consultant. He has led the testing efforts of mission critical and flagship projects for several global companies. He specializes in the development and implementation of testing strategies.

***

The prevalent idea that testers are dependent on a requirements document to do their job is a dangerous one. Requirements are not always needed to test. In fact, in many situations, they may actually reduce a tester’s effectiveness.

The process of deriving tests directly from the requirements has several names. The ISTQB uses the term “specification-based testing”, sometimes it’s referred to as “Happy Path” testing, but I think the most appropriate name is “checking”. Michael Bolton wrote a well-known post about this topic. Checking is confirming that what we believe is actually true. Products are built in accordance with the requirements, so the requirements are what we believe to be true. When we verify that our product meets the requirements, we are “checking” the product. When a tester relies on a requirement document to test, he isn’t testing, he’s checking.

When we test, we are exploring, investigating and learning. Our actions are influenced by new questions and ideas that haven’t yet been explored. The use of requirement documents while testing can cause problems because it can give a false sense of test completeness, it can steer testers in the wrong direction, and it can reduce the independent thinking of the tester.

Gives a False Sense of Test Completeness

If we have verified that our product meets all of the requirements, does that mean that the product has been well tested? True, you have verified that the product behaves the way we expect it to (in specific situations) but you still don’t know how the product will behave in situations not specified in the requirements.

“That wasn’t in the requirements” I’ve heard testers use this excuse many times and it drives me crazy. As a tester it is your job to investigate the product to learn about areas and behaviors outside of the requirements. A product is much more than its conformance to the requirements. It’s up to you to cover that gap between what is expected of a product and what actually is.

Checking that a product meets the requirements is necessary of course, but checking alone does not indicate test completeness.

Steers Testers in the Wrong Direction

When you first start testing a new product or feature, what should be the first thing you test? Some might say you should verify the requirements. I challenge that view. I think the requirements should be one of the last things you test. In my opinion, a developer who writes code that didn’t meet the requirements failed to do his job. Before the test team sees the product, the developer has already spent hours working and verifying that his work is correct. Although possible, a strong developer rarely produces work that doesn’t meet the requirements. With that in mind, there is little value in retesting his work, especially when you consider the other aspects of the product that haven’t been tested yet.

Requirement documents can stifle the creativity of exploratory testing. When testers have a requirements document in front of them, they may be more likely to verify the requirements first and focus on areas where the likelihood of learning new information is the lowest. Instead, they should focus their efforts on new tests and unexplored areas where the opportunity for learning is the highest. When testing without requirements, you eliminate its influence on your testing decisions; you have to rely on your own abilities, your knowledge, and your curiosity. You test.

All testers have heard the old saying “Trust but verify”. I’m not saying that we shouldn’t verify developer’s work, only that there’s more value in performing a test for the first time, then performing the same test multiple times. Focus on the activities that produce the most value first.

Reduces Independence

The idea of “independence” (See ISTQB Foundation) refers to how close a person is to a product. A developer who wrote the code would have the least amount of independence, while a person in a different company who has never seen the product would have the most independence. Independence can often be a great quality for testers. Testers with no preconceived notions of how the product is supposed to work are able to view the product with more objectivity.

Consider the common situation where a product was built according to incorrect requirements. The tester was able to verify that the product met the requirements, so was there an issue? In this case the requirements served as a false crutch to the tester. Just because the product met the requirements doesn’t mean it was working correctly. A tester with no knowledge of the requirements would have been better positioned to identify any errors because he wouldn’t have been comparing it to an incorrect “truth”.

We have now seen some reasons why testers should avoid relying on requirement documents. While they may be a necessity for different “checking” activities, testers who wish to provide value thorough “testing” must understand that their value is best realized when they test without requirements.

We have a problem. Application development has become agile, component-based, and open source dependent. But security approaches haven’t kept up. Every day we’re forced to make the dangerous choice between speed and security, putting Development and Security at odds. There has to be a better way.

Join Wendy Nather, Research Director, Security, at 451 Research tomorrow, Tuesday, April 30 from 11:00AM-11:45AM EDT (GMT-0400) to understand:

•     The changes in application development that have left security behind.
•     Limitations of existing security approaches that could leave your organization exposed.
•     The new requirements that are driving security to align with application development.

In addition, Sonatype CSO Ryan Berg will provide a brief overview of Sonatype CLM, a new application security platform designed specifically for today’s applications and for managing the modern software supply chain.

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.

Secure development lifecycles sound good: processes to ensure that developers create software more securely from the start. But doing so does increase the cost of the software and the time to...

For Cegedim Activ, seeking to improve test processes for their software Activ’Ro, Kalistick Test Coverage Intelligence platform quickly became an indispensable asset.

Feedback on the tool deployment within Cegedim Activ from the company’s Head of Quality Control Certification Unit, Anne-Marie Bailly.

Cegedim Activ

Key Facts

• Software Publisher
• 500 employees
• 9 locations
• €74M in sales in 2011,
• 300 million insured people

The Cegedim Group supplies services, technological tools, specialized software and database and workflow management services to all healthcare stakeholders:

• - industries,
• - pharmaceutical companies,
• - healthcare professionals,
• - insurance companies.

The Group’s “Software Development” Branch, Cegedim Activ, is the leader in software solutions for personal insurance on the French market.

Application: Activ’Ro

• SaaS
• Mix of Waterfall & Agile software development
• Target market: Managing organizations for mandatory healthcare plans

“We were looking for this type of tool, without knowing if it already existed.” The Challenges

This project depends on 4 major stakes:

• Industrialize the testing process on a key but still young application
• Identify the current test coverage on the solution, create new scenarios, and increase test automation (Selenium tool)
• Increase quality and reduce risks on software versions provided to client organizations
• Facilitate the transition to an Agile process

Kalistick’s Solution Kalistick, a key asset for the industrialization of test processes

Cegedim Activ sells and maintains six software solutions on which numerous tests are regularly performed. But in 2009, when the company decided to launch and market Activ’Ro, its new SaaS solution, dedicated to managing organizations  for mandatory healthcare plans (local cooperatives, self-employed…), no automatic regression tests had yet been put in place.

“There were of course acceptance tests and manual regression tests already in place”, says Anne-Marie Bailly,  Cegedim Activ’s Head of Quality Control Certification Unit. “But the test automation pilot project with the Selenium tool was still to be completed, and we wanted to move forward without delay.”

It is at this time that Anne-Marie Bailly attended a webinar on Kalistick. “We were looking for this type of tool, without knowing if it already existed… And we were amazed by the solution that was presented to us”. Indeed Kalistick quickly  became a key tool in the industrialization of test processes for Activ’Ro.

A perfect complement to the automation tools and test management solutions such as HP QC, XStudio, or Selenium, Kalistick is a particularly innovative solution and  unique which can detect any “test holes” in our test coverage.

The solution therefore  makes it possible, among other features, to build new test scenarios in order to improve their coverage and thereby increase the quality of published software versions.

Implementing the solution “The Kalistick tool works perfectly, despite the complexity of our software which contains over two million lines of code.”Anne-Marie Bailly

Too good to be true? A proof of concept was implemented to verify the promise offered by the Kalistick tool and validate its compatibility with Cegedim Activ’s new solution.

It was indeed crucial to avoid any mistake in this vast project of test  process industrialization for Activ’Ro, a solution whereby customer organizations are particularly demanding in terms of quality, but their financial means do not always allow the sufficient allocation of human resources in the acceptance  phase.

“The pilot project answered all of our requirements,” says Anne-Marie Bailly. “The Kalistick tool works perfectly, despite the complexity of our software which contains over two million lines of code.”

On the Security of the Code

That said, it was also necessary to completely reassure Cegedim Activ on how Kalistick works. In the sensitive and competitive sector that is healthcare, security of code in deployed software solutions is  crucial.

“Our tool is built on a hybrid ‘On-premise/ Cloud’ architecture”, says Marc Rambert, Kalistick Director. “The ‘Application Scanner’ and ‘Test Footprints’ modules are installed at the customer site, and the analysis and dashboards are hosted in the  Cloud.”

But one of Kalistick’s real strengths lies in that not a single line of code is actually sent to the Cloud which guarantees total security at this level.”

Transparency is highly valued by Cegedim Activ. That is why the solution, which combines “on-site” safety with the advantages of SaaS, both in terms of the business model (simple subscription) and in terms of maintenance (no dedicated  internal server), has been completely implemented within the company.

“One of Kalistick’s other advantages is that it can determine exactly which tests must be run.” Go further still

“The competence and the high reactivity of experts we dealt with from Kalistick, specifically regarding the integration of XStudio and other tools we use, also played a role in our decision,” says Mrs. Bailly.

“Cegedim Activ is therefore currently  assessing its implementation on other company products, especially since the company is planning to generalize agile methods on all its solutions, while today a portion of development still follows a waterfall model.”

Indeed, according to  Anne-Marie Bailly, “one of Kalistick’s other advantages is that it can determine exactly which tests must be run – those which relate to a portion of code which has been modified – as well as identify those tests which would be useless to run –  those which relate to a portion of code unaffected by developments made from one version to the next.

This functionality is crucial when you decide to shorten your  time to market.”

I messed up this week. And the week before. And the week before that, the one prior, most weeks last month, most months this year, most weeks in most months most years ... Basically all the time. And I do it on purpose because it puts me in a position to find bugs that I wouldn't otherwise come across.

I'm not talking about deliberately entering junk content into applications, configurations, data and the like. I'm not talking about random clicking in a system under test or trying to engineer corner cases by artificially restricting disk space or RAM or some other resource or any other of those legitimate test vectors that benefit from experimenting with the available parameters.

I'm talking about sympathetic testing - or even just plain usage - in an untidy way to try to increase my test coverage in passing. Here's some examples:

• If your application is in the cloud, maybe don't log out of it when you've finished your current task. Look for odd effects next time, perhaps after you've moved between networks or not accessed the system for a few days.
• If you start an application daemon or service at the console, don't close it immediately, but leave the console open while the system runs. Check in on it now and again as you move between tasks and look for exceptions, unexpected errors and so on.
• If you have an instance of your application open already and want to try something, sometimes don't use the open instance but open another and watch for effects due to cross-contamination.
• At the end of  a session, don't close down cleanly. Instead, leave the application in the middle of an interaction - with a dialog open, say - and see what happens when you come back to it.
• If you're testing a web-based application don't always use the same bookmark to get there. Use your browser history, or type into the URL bar and get some old URL from your history or paste a URL from an old email to find a new starting point and see what the server does with it.

This can be extremely productive and has the side-benefit of forcing you into a state of mind where you're alert to issues from the moment you begin your task. You should be looking to automatically log wherever and whatever is possible, record exceptions and other error trace immediately you see it, take screenshots of anything you think might be unexpected behaviour and so on because one of the consequences of this approach is that reproduction steps can be harder to obtain and the evidence can help you to return to the bad state later.

People talk about setup, test, teardown sequences and in some cases that's exactly what's required. You may need to understand your starting context as precisely as possible so that when running a sequence of test ideas you can return to that context each time. But your users won't be running inside a sterile laboratory, so make sure you don't always do that either.
Image: http://flic.kr/p/9RnnTK

Here is a thing I learned from J.B. Rainsberger at XP 2012 in May 2012. I used it in the past months quite extensively for debugging communication based upon the Satir Communication model. While doing some research for this blog entry, I discovered that some others have also written about the topic. I especially liked Dale Emery’s Untangling Communication which seems to go a bit deeper than my understanding of the topic. Anyways, here’s my write-up which might give a different perspective.

The Satir Communication model

Family therapist Virginia Satir developed model about communication. Jerry Weinberg wrote quite extensively about it in several books. However, the first time I really understood the model, was in the context of debugging communications.

Let’s dive into the model, first. There are four phases when a a human receives any form of communication: intake, meaning, significance, and response. Let’s dive deeper into them.

Intake

During information intake we humans take in the message the other person communicating with us is trying to give us. We take in the words the other person says, we take in the body language, we also subconsciously notice things the person is sending to us. For a web blog this mostly consists of reading what is there.

Needless to say that the amount of communication we may intake depends largely on the communication channel used. For face-to-face communication the amount of information that I can notice is much wider than for example for text chat exchanges on the internet, or asynchronous written communication like email or twitter.

We’ll take a discrete look on the things that may go wrong in a few.

Meaning

After taking in the message as it was said we start to interpret the message based on our previous experiences with the person we are interacting with. That might mean that we come up with the worst possible interpretation, for example when we deal with an identified patient, that is someone we mostly see as the troublemaker. That might also mean that we come up with the most positive interpretation for a person that we love or feel close to.

We form interpretations based on our previous experiences with the sender, or based on our skills on intake. We combine the intake of the message together with our previous knowledge of the situation, the environment, and our previous experience in similar situations like this.

Significance

Taking our intake and our interpretations into account, we form significance to the message. Significance is based upon upon our feelings about the situation, how we experienced similar situations in the past, and the good or bad interpretations that we came up with. But also the surroundings of our family life might lead to different significance assignments for the message we received.

Response

Last, but not least, we decide whether or not to respond, and what an appropriate response will look like. We base our responses based on the information we took in, the meaning we formed from it, and the significance to the message that we attached to it. For example, in a particularly stressed situation in your family, you will respond differently as when everything is alright at home.

When things go wrong

But what happens when things go wrong? And how does the model help there? In order to debug communications, I go through the phases in order to check where something went wrong and to correct the situation from there. So, let’s go through the phases to see where communication might go awry, and what we might be able to do to resolve the problem early.

Intake

When something goes wrong during intake, we understand different things. For example when I write the word “integration test”, there are at least two different meanings I am aware – that’s why I usually try to avoid that term. Other such terms are for example to my experience “quality”, “testing”, and “agile”.

When something goes wrong during information intake, we end up with a misunderstanding. That means that the sender of the message had a different understanding of the term than the receiver, and we end up with something called ‘shallow agreement’ if we don’t find out about our misunderstanding before agreeing together on something.

In order to check for misunderstanding in our communication I try to ask clarifying questions. For examples when I am asked to create better quality, I ask for more specific details about the term “quality”. When someone asks me for “best practices”, I ask for a definition of that. I think that is also the reason why we allow clarifying questions in LAWST-style peer conferences.

Meaning

Weinberg’s famous Rule of Three Interpretation origins from this phase. To cite Quality Software Management Volume 2 – First-order measurements on page 90:

If I can’t think of at least three different interpretations of what I received, I haven’t thought enough about what it might mean.

That means that at times I might end up with a different interpretation than the sender has. If we are not on the same page regarding our understanding of the words, it is also clear that it’s more probably that we end up with different interpretations regarding the situation.

When dealing with misinterpretations, that is we attach different interpretations to the communication than the sender tried to send to us, we need to explore the situation a bit deeper. How come the sender came to the interpretation? What other intake of the situation did he come up with? Most of the time I find out there are other contributing factors that I was not aware of so far. By asking the Data Question I at times explore the interpretation:

What did you see or hear (or feel) that led you that conclusion?

(Gerald M. Weinberg, More Secrets of Consulting, Dorset House, page 114)

Significance

In regards to significance, I need to go a bit deeper. I need to explore feelings of the sender. For me to understand the significance the sender attaches to a particular situation or communication, I need to ask for previous experiences. I don’t have that many experiences with dealing with those situations. Most of the time this highly touches our inner beliefs. To be honest, I have not found many ways to change those other by providing different experiences.

I haven’t been in too many situations where communication went wrong in the response part. That’s why I don’t dive deeper into it here.

Last, but not least, I usually find myself already in better communication with the first two parts, as most of our communication seems to go awry there. viagra

I have some great and some sad news. Let’s start with great news.

Great News! :)

Joel Pearson

Joel Pearson joins the team as support sheriff.

Bret Pettichord’s nomination:

I would like to nominate Joel Pearson as a support sheriff for Watir. He is active every day on the ruby-talk mailing, answering questions about testing with Ruby and frequently recommending Watir-Webdriver as a solution.

(…)

Here is an example of what I am talking about.

http://www.ruby-forum.com/topic/4407767

Bret

Joel about himself:

Hi all,

Hopefully I’ve done this correctly as I’ve previously always used
forum interfaces for mailing lists.

My programming experience is just over 2 years, Ruby for about 1 year.
I started using Watir-Webdriver just under a year ago while trying to
build an automated interface for a web-based stock system. I basically
just built a few front-ends for ease of use, capable of batching
repetitive tasks and analysing information.

Since then I’ve developed some of my own wrapper classes to use within
my company for reporting and bulk processing, allowing me to write
customisable reports quickly from a template. I would say I’m still a
novice programmer, but as I’m being paid for this work I guess I’m
technically a “professional”.

I’ve made a few minor alterations to my local watir-webdriver files.
The main one was adding an optional timeout length while waiting for
javascript alerts. I wrote that a while ago so I could probably do it
better now.

I’ve also started work on my own gem which attempts to emulate
Microsoft Excel’s API as an invisible workbook class. This is to
simplify manipulation of data when analysing HTML tables, and to make
the transition from Excel VBA to Ruby a bit easier. It’s still in the
early stages of development at present.

The Ruby mailing list was (and still is) a great source of helpful
advice when I was starting out learning how to use Ruby and Watir; so
I continue to participate in the hopes of giving something back to the
community in return for all the help I’ve received. And, of course, to
continue to benefit from all the great advice on there.

Links which may be of interest to you:

• http://stackoverflow.com/users/1847477/virtuoso
• https://github.com/VirtuosoJoel
• https://rubygems.org/profiles/virtuoso

Some of my old posts feel a bit cringe-worthy when I look back at
them, but that’s all part of learning. I’ll stop rambling now, let me
know if there’s anything pertinent I missed.

Thanks,

Joel

Sad News :(

Bret Pettichord asked to be moved to alumni section.

It is time to move me to the Alumni list, as I am no longer an active contributor to the Watir project. I don’t contribute code any more and I haven’t helped manage the project since hosting the Watir Bazaar a year ago (March 2012). I’ve asked others to recognize when they’ve stopped contributing. Now it is my turn.

I should make clear that my team still uses Watir-Webdriver (and WatirMark) every day, so we continue to be users and I continue to encourage my team to contribute to the project. I am also very happy with the current team that has been keeping the project active, especially the leadership provided by Jari, Jarmo and Zeljko.

(…)

Last year I had been working on an application for membership in the Software Freedom Conservancy, but realized that I did not have the commitment needed to submit it. If others would like to pursue this, I am happy to support their efforts.

Bret

Tiffany Fodor also asked to be moved to alumni section.

Hi all!

I saw in an earlier message where Bret asked to be moved to the alumni section on the Watir.com site because he hasn’t done much with the team in the past year. It occurred to me that I’ve likely done even less and should be moved to the alumni section as well.

I still use Watir-classic every day – thanks so much for keeping us IE-saddled folk in up-to-date Watir code! We’re in a “do more faster” mode here at ICAT and I don’t have much time to help out with the support end of things. I’ll try to look in from time to time, but I can’t promise to help on a consistent basis. Also, I don’t have the skills to be updating the source code.

I’m happy to help with the Software Conservancy application if we’ve decided that’s how we should move forward. Please let me know if I can be of help with it without just making it more complicated by handing it off.

I hope all is well with each of you – I missed seeing you all in Austin this year!

Take care!

-Tiffany

Hugh McGowan is the last one to ask to be moved to alumni section.

Hi all,

Seems like it’s the season…

While I use Watir-Webdriver daily, it’s been over a year since I’ve checked in or released code, so I should probably be moved to the alumni list as well.

It’s been great fun – I’ve learned tons and met some awesome people. Keep up the great work Jari, Jarmo and Zelkjo!

I’ll still lurk on this list and am happy to help with anything y’all need so feel free to ask. Let me know if you’re ever in Austin!

Thanks!

Hugh

Hi everybody!

A few Watir gems got updated recently. I just wanted to make sure everybody is up to date. :)

watir-webdriver:

• 0.6.3 April 10, 2013 (release notes)

watir-classic:

• 3.6.0 March 16, 2013 (release notes)
• 3.5.0 March 10, 2013 (release notes)

In the last few posts on sagas, we looked at a variety of patterns of modeling long-running business transactions. However, the general problem of message routing doesn’t always require a central point of control, such as is provided with the saga facilities in NServiceBus. Process managers offer a great deal of flexibility in modeling complex business processes and splitting out concerns. They come at a cost though, with the shared state and single, centralized processor.

Back in our sandwich shop example, we had a picture of an interaction starting a process and moving down the line until completion:

Not quite clear in this picture is that if we were to model this process as a saga, we’d have a central point in which all messages must flow to for decisions to be made on the next step. But is there really any decision to be made in the picture above? In a true saga, we have a sequence of steps and a set of compensating actions (in a very simplistic case). Many times, however, there’s no need to worry about compensations in case of failures. Nor does the order in which we do things change much.

Humans have already found that assembly lines are great ways of breaking down a long process into individual steps, and performing those steps one at a time. Henry Ford’s Model T rolled off the assembly line every 3 minutes. If only one centralized worker coordinated all steps, it’s difficult to imagine how this level of throughput could be achieved.

The key differentiator is that there’s nothing really to coordinate – the process of steps is well-defined and known up front, and individual steps shouldn’t need to make decisions about what’s next. Nor is there a need for a central controller to figure out the next step – we already know the steps up front!

In our sandwich model, we need to tweak our picture to represent the reality of what’s going on. Once I place my order, the sequence of steps to fulfill my order are known up front, based on simply examining my order. The only decision to be made is to inspect the order and write the steps down. My order then flows through the system based on the pre-defined steps:

 

Each step doesn’t change the order, nor do they decide what the next step is (or even care who the next step is). Each step’s job is to simply perform its operation, and once completed, pass the order to the next step.

Not all orders have the same set of steps, but that’s OK. As long as the steps don’t deviate from the plan once started, we don’t need to have any more “smarts” in our steps.

It turns out this pattern is a well-known pattern in the messaging world (which, in turn, borrowed its ideas from the real world): the routing slip pattern.

Routing slips in NServiceBus

Routing slips don’t exist in NServiceBus, but it turns out it’s not too difficult to implement. A routing slip represents the list of steps (and the progress), as well as a place for us to stash any extra information needed further down the line:

    public interface IRoutingSlip
    {
        Guid Id { get; }
        IEnumerable<IProcessingStep> ProcessingSteps { get; }
        IDictionary<string, string> Attachments { get; }
    }

We can attach our routing slip to the original message, so that each step can inspect the slip for the next step. We’ll kick off the process when we first send out the message:

Bus.Route(sandwichOrder, new[]
{
	"Preparation",
	"Oven",
	"Packing",
});

Each handler handles the message, but doesn’t really need to do anything to pass it down the line, we can do this at the NServiceBus infrastructure level.

public class PackingHandler 
	: IHandleMessages<SandwichOrder>
{
	public void Handle(SandwichOrder message)
	{
	    // pack the sandwich
	}
}

The nice aspect of this model is that it eliminates any centralized control. The message flows straight through the set of queues – leaving out any potential bottleneck our saga implementation would introduce. Additionally, we don’t need to resort to things like pub-sub – since this would still force our steps to be aware of the overall order, hard-coding who is next in the chain. If a customer doesn’t toast their sandwich – it doesn’t go through the oven, but we know this up front! No need to have each step to know both what to do and what the next step is.

I put the message routing implementation up on NuGet and GitHub, you just need to enable it on each endpoint via configuration:

public class Startup : IWantCustomInitialization
{
	public void Init()
	{
	    Configure.Instance.RoutingSlips();
	}
}

If you need to process a message in a series of steps (known up front), and want to keep individual steps from knowing what’s next (or introduce a central controller), the routing slip pattern could be a good fit.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

An interesting thing happened to me the other day. I was getting a pitch about a new product from a pretty well-known enterprise and the marketing person said: "We are members of the 2012 API...

A software security vulnerability fixed in Oracle’s most recent Java Critical Patch Update, which was released on April 16 and addressed 42 flaws, has already begun to appear in several popular exploit kits, according to researchers. The rapid addition of the flaw to cybercriminals’ portfolios underscores the challenge developers face when relying on patches to protect software following its release rather than securing applications ahead of time.

Security researchers at F-Secure first reported spotting the exploit for vulnerability CVE-2013-2423 in the wild in a blog post on April 21. Oracle gave the flaw a 4.3 CVSS rating, and it can only be exploited through untrusted Web Start applications and applets on client deployments. It was being exploited just one day after being added to the popular open source Metasploit framework, a tool used by penetration testers.

According to a blog post by an independent researcher known as Kafeine, the vulnerability has already been integrated into the Cool Exploit Kit and is being used to install Reveton, a ransomware application. Ransomware is a type of malware that locks infected machines and extorts victims for money.

“This wouldn’t be the first time when cybercriminals have taken Metasploit exploit modules and adapted them for use with their own malicious attack toolkits,” IDG News Service’s Lucian Constantin noted in an article recapping the exploit.

Consumers can protect themselves against the flaw by upgrading Java. However, the appearance of the flaw in exploit kits so shortly after being patched likely means that a large number of Java users are still vulnerable.

The incident demonstrates that once a vulnerability is public knowledge – even though it is being shared for security purposes by researchers and testers using legitimate tools – it can be quickly assimilated into attackers’ tool boxes. To provide better software security and ensure users are not, counterintuitively, exposed to new threats following a patch announcement, developers can use tools like static analysis software, which enables them to catch errors prior to release.

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

uTest is setting the pace in Massachusetts…and we’re not talking about uTest CEO Doron Reuveni’s ability to run the entire length of the state without breaking a sweat.

Yesterday morning at the Boston Business Journal’s Pacesetters breakfast event, the BBJ named uTest the #1 pacesetting company in the region. In case you were wondering, the Pacesetters list is comprised of seventy Massachusetts companies that recorded the highest three-year growth rate in terms of revenue. Not too shabby.

“We’re thrilled to be named as the #1 Pacesetter in the region by the Boston Business Journal,” said Doron. “It further validates our vision and execution, and is a distinct honor to be recognized alongside so many great companies. Congratulations to all of the Pacesetters.”

It is truly exciting to be a part of the top companies driving the economy in Massachusetts, and as uTest CMO Matt Johnston said earlier this month, “uTest is proud to call the Boston area our home base.”

What makes us even more thrilled is that yesterday’s Pacesetters Breakfast Event was able to raise $76,000 for the One Fund Boston. As BBJ Publisher Chris McIntosh said, “these companies displayed the kind of commitment that symbolizes Boston Strong.”

Congratulations to all the Pacesetters, and thank you to the folks at the Boston Business Journal for putting together such a great award and event!

Google Charts makes it easy to show data visually and beautifully. You can show historical trends or by categories. Depending on the data your site gathers, you can show which users have the best...