Speaking to a customer recently, I was told:

"Honestly, our favorite thing about moving to AnthillPro is that we've moved beyond 'Plug-n-Pray' deployments. You know, many of our deployments were so scary we'd have a bunch of people in the office or on a call all weekend to execute and debug the deployment and then have all hands on deck Monday morning to deal with the inevitable problems. We were all so stressed and tired that we were pretty much useless for a few days after the deployment.

That's all gone now that we've automated. Most of those deployments are a 30 minute effort Friday night, and we don't do anything special on Mondays."

It always feels great to hear that your product isn't just good for productivity, traceability, etc but that you're also making people's lives better by giving them their weekends back. But I think it's important to call out that changes in process for this customer and others like them that are equally important.

• No more Word documents containing the deployment plan They're hard to follow, and get out of date.
• No fixing application server configuration in Test environments by hand: Instead of fixing a broken configuration of the test environment by hand (which often results in the same breakage in Prod), the teams fix the automation to set to the configuration properly in all environments and redeploy to Test.
• Repeatable Deployments: An automation system can only deploy that which is automateable.  This rules out funky processes that rely on guess work and gut checks. The process of figuring out the deployment process well enough to automate it makes the process better. (see our WebCast on using automation to shine a light on your process.

It comes down to making sure your process can be automated. Automating that process. And not circumventing the automation - even in test environments. Each of those three elements delivers some unique gains.

This weekend I realized my last post was almost 2 months ago, on July 4th.

This break from writing was not intentional and it was not really a break since I was really busy with tons of PractiTest work and some additional heavy-duty chores related to caring for 2 small children during their summer vacations.   But there was also a positive side to this pause since it gave me a chance to reflect on what I’ve written on the blog so far, the subjects I’ve covered and those I haven’t gotten to yet.

I did something interesting, using “wordle” (a very cool app!) I generated a word map of the blog’s content:

Word Cloud for the QABlog

It was no surprise that the word TESTING came so strong and central, but there were also some other words that took an important place and I want to take this chance to review them.


SHARE – Sharing is (almost) always positive, but in Software Development and specially in Agile Teams it becomes one of the biggest success or failure factors.
I am currently reading “Agile Testing” by Lisa Crispin and Janet Gregory and it covers this point broadly with many reasons why sharing and collaboration are two of the most important factors for succeeding in agile processes.  By the way, the book is a great read and I recommend it even to testers who are not part of Agile Teams.


TIME – If I had 3 wishes they would be happiness for my kids, world peace, and a 32 hour day!  Time is one of our most valuable assets and so we need to learn to manage it correctly.
But managing time is not enough, we also need to learn to respect it, both our time and that of our colleagues.  For me personally the biggest time waster is context switching. When I stop what I’m doing to read mails, answer IM’s or phone calls, or even when someone walks up to me to ask “just one small question” it takes me between 5 to 10 minutes to reach the level of concentration I was before the interrupt.  If you do this 2 or 3 times an hour you end up spending half the time just getting to restart your work.  Can you relate to this?


THINK – this is a big one!
Most of us don’t really think as much as we’d like to accept, we are mostly busy reacting to what is going on around us.
To really think we need to take a time-out, breath deeply for a couple of minutes and clear our heads from all the urgent things in order to focus on the important ones (notice that most times the urgent things are not necessarily the most important ones!).  When was the last time you did this??
Whenever we take the time to THINK we use our resources better by investing them on the tasks that are really needed.  It’s a shame we don’t get to do this more often…


DEVELOPERS – these guys and galls are our biggest allies, and yet they’re also the ones with whom we tend to be most in-conflict during our projects.
Our relationship with developers makes me think about the classic book “Men are from Mars & Women are from Venus” by John Grey.  In fact we need to understand that the issues between developers and testers are mainly linked to the fact that we are 2 different species (or at the least belong to 2 different cultures) and in order to communicate and work together we need to understand and respect the principles of the other side, what’s important for each of us, and how each one approaches problems and challenges in his own way.
The key lies in understanding & communicating with your colleagues- just like in all types of relationships.


PERSPECTIVE – one of my personal favorites and closely related to thinking.
When you are in the middle of the forest it becomes too hard to look at the trees.  Perspective allows us to take a new look at the issues we are working on and check for new and interesting stuff even in the places we’ve already visited multiple times before.
Gaining perspective is relatively easy, you just need to fully focus your attention on another subject for some time and then revisit your previous task.  Just by switching context you will be able to see things under a different light.
I use this all the time: when testing to make sure I really covered all the important scenarios; when trying to solve problems by looking for different approaches that may give a better result; and even when in I find myself arguing with a colleague when I take time-off to cool down and think about the stuff that is really important.  Give it a try, and tell me if it worked for you!


Lastly an interesting pairing of words that came out of the random image:
GOOD SCENARIOS – something I have not talked about much in the blog but a subject I think I will write about in the near future


I am hoping that now that summer vacations are reaching their end, and after having released some pretty amazing stuff in PractiTest that we were working on for a number of weeks, I will have some more time in my hands to continue posting more regularly…

• This domain is forbidden!+" rel="" title="Tweet This!">Tweet This!
• Share this on del.icio.us
• Digg this!
• Share this on Reddit
• Stumble upon something good? Share it on StumbleUpon
• Share this on Facebook
• Share this on Technorati
• Add this to Google Bookmarks

Related posts:

1. When you think you’ve done enough, go for a walk and then think again
2. Testing the image in the mirror
   - or -
   Why a good tester needs to be Self-Critical?

A couple weeks ago, we rolled out v3.0.4 of our platform. And now, after a little extra time in the oven, we’ve launched another feature designed to make it quicker & easier to access your uTest account.

Social Sign-In
Let’s say you’re like millions of other people around the world and you have an account on Facebook, Twitter, or LinkedIn. And let’s also say you’re tired of keeping track of passwords, remembering to sign-in everyday to all the websites you like, and are yearning for something simpler. Starting today, we have a solution for you, at least when it comes to your uTest account (we can’t speak for anyone else). Now you can log in to the uTest platform using the credentials from your Facebook, Twitter or LinkedIn accounts.

Setting up this linkage is simple:

1. Get started by visiting our platform and clicking the button for your favorite social network(s).
2. Then sign in to your social network and confirm the connection.
3. And that’s pretty much it. The next time you visit the uTest platform, just click that same button and you’re in.

Enjoy!

Cloud computing is an emerging phenomenon that offers enormous advantages, such as shorter time to market, flexible computing capabilities and limitless power, but the cloud market, still in a very early stage, continues to grow and evolve.
As cloud computing evolves, it creates a global infrastructure for new possibilities used in software quality assurance and testing. Businesses can share public or hybrid clouds with each other or create private clouds to be shared within the whole company, instead of using separate options for different enterprise departments. However the cloud is also threatened by some risks. These risks should be addressed to create the highest result in implementing the cloud and avoid threats on the other hand.

In the last few posts I have discussed some of, what I consider to be, the most valuable Agile methods for development.  The list is pretty long, so breaking the list up allows me to define each practice and include the individual benefit of each Agile method.  This post defines some hot terms right now- continuous integration, multistage continuous integration, and story points.  Enjoy!

Agile Method: Continuous Integration

How frequently have you merged your code with changes from the mainline, only to find that the result doesn’t build, or it builds but it doesn’t work? Monthly? Weekly? Daily? Hourly? Or worse, how often have you made changes that broke the build, requiring you to quickly correct the problem while getting flames from your team members?

A practice that has emerged to address the problems of integration is called Continuous Integration. The basic idea is that if integrating changes together and getting build and test results on a regular basis is a good idea, integrating and getting build and test results on every change is even better.

With Continuous Integration, all work from all teams is integrated into a single codeline as frequently as possible. Every check-in automatically triggers a build and usually a subsequent run of the test suite. This provides instant feedback about problems to all interested parties and helps to keep the code base free of build and test failures. It also reduces the integration headaches just prior to release.

Agile Method: Multi-stage Continuous Integration

Integration is tough enough when you are just integrating your work with the work of other folks in your small team, or the whole effort is being done by a small team, but when you are part of a large team there is also something called “Big-Bang” integration. That’s the integration of the work that multiple teams have been working on for long periods of time. In a typical project, this integration is done in a phase toward the end of the project. During integration, many problems are discovered for the first time which leads to delays and/or changes in scope.

The real question is, what is a good way to structure this integration so that it will scale smoothly as you add more people to the equation? A good starting place is to look around for a pattern to follow. What are some similar situations? I have found that everything your organization needs to do in order to produce the best possible development organization can be entirely derived from the patterns and practices at the individual level. This approach makes it much easier to understand and much more likely that it will be successfully followed.

As individuals we work in transient isolation to reduce the impact of work in progress on each other. Organizations isolate WIP by using only official versions of 3pty sources and by producing official releases for customers.

Multi-stage continuous integration (MSCI) scales CI to large distributed environments by isolating work in progress at the team level. Changes move from individual to team to mainline as fast as CI allows, but stop on failure. MSCI is particularly important in a distributed environment where fixes to problems exposed by CI can be delayed by a full day

Agile Method: Using Story Points For Estimation, Instead of Units of Time

In my experience, the best unit to use for estimates is story points. Two different people with two different skill sets or levels of ability in an area may take different amounts of time to perform a particular task. Estimating in hours mixes together the scope of the work that needs to be done with the speed at which a particular individual can do that work.

On the other hand, story points are a relative measure of the scope of a user story. Story points separates out the “what” from the “who.” For instance, if you have one individual that is stronger with .Net than with Java, they will estimate a Java story as taking more hours than somebody that is stronger with Java. But they will probably both agree that something that is twice as easy to implement will take half as long to do.

To use story points, you need to create a relative scale of scope. A simple approach is to find a simple and straightforward story that you use to represent a single story point. Then think of stories that are 2, 3, 5, and 8 times larger in scope. You should have a couple of examples for each story point value to take into account that some stories have more test than coding, more documentation than test, etc.

Story points are primarily used for planning, not for implementation. Story points are used to help determine the contents of release by calculating a velocity.

Next up: Backlog, velocity, planning poker and burnup charts.

If you’re in the market for a new mobile device (and these days, who isn’t?) one of the most important decisions you’ll have to make is whether to choose the physical keypad or the touchscreen.

As we learned from our most recent What Do uThink poll, most mobile users actually want both of them. In fact, 70% of respondents said they would prefer a device like the Motorola Droid or the Blackberry Torch, as opposed to the 20% who said they preferred the physical keypad only (e.g. Blackberry Curve, Blackberry Bold) and 10% for the virtual touchscreen (e.g. the iPad, iPhone, etc).

So, 70% of mobile users can”t be wrong, can they? Let’s take a look a few of the arguments (from the uTest Forums thread) in favor of each, then decide for yourself.

Physical Keypad
“I go with Physical keypad. The reason is I have experienced problems while using touchscreen keys. I love Physical keypad which allows me to type the message fast and call the number much quicker than a touchscreen. Also, my LG Android had gone for service because the touch screen was malfunctioning. For instance, when I pressed 3, it used to display 6.”

Hybrid
“I prefer a hybrid model as it gives me independence to use the phone as per my convenience. Also, it makes things much easier for me. If I have to chat or SMS I can use the keyboard feature, but if I have to punch in a phone number or username/password I can do it from touchscreen. Plus, different situations demand things differently so a hybrid model is a perfect one for me.”

Virtual Touchscreen:
Pros:

1. Does not take physical dimensions & weight, thus devices can be lighter & thiner, or can be larger with larger screens & additional physical buttons in return to that acclaimed space & weight.
2. Some physical keyboards can be used only on one orientation. Virtual keyboard will mostly work on both.
3. Easy keyboard layout navigation & usage – E.g. Input switch, Special chars (rather than hitting an Alt/Shift/Sym+Char), Smileys and other special inputs.
4. Languages support – As opposed to physical keyboard which can support 2 languages max, TouchScreen keyboards can support and unlimited amount of languages, so everyone can enjoy the languages keyboard of their choice.
5. Used device’s brightness setting thus can be visible at dimmed or low-light environments with no problems, as opposed to physical keyboards’ limited lighting.
6. Clarity & efficiency – Most touch keys use all sorts of key highlighting pressed button such as – Coloring, Magnify glass (e.g. iPhone), Vibration (E.g. Android)

So where you come down on this debate? Which type of device will you be leaning towards for your next purchase. In other words, What Do uThink? The comment section is all yours.

If you were unable to attend Sonatype’s last webinar on Build Promotion with Nexus Professional, you can view the presentation recording here. This webinar is an introduction to the Build Promotion capabilities of Nexus Professional, the industry leading repository manager to help companies acquire, manage, and report on open source software artifacts in their software development projects.

The Build Promotion feature in Nexus Professional allows an organization to create a temporary staging repository and to manage the promotion of artifacts from a staging repository to a release repository. This ability to create an isolated, release candidate repository that can be discarded or promoted makes it possible to support the decisions that go into certifying a release.

Upcoming Webinars:

Build Promotion with Nexus Professional

When: Thursday September 9th, 2010 at 10:30 am PDT, 1:30pm EST

Who: Blaine Mincey, Senior Systems Engineer, Sonatype

Register for this webinar

 

August has been a emotional roller coaster of a month for me.

It started on an extremely happy note. We announced the Lab Management capability of VS 2010 on August 4 at VS Live, and we released the feature on August 19. The capability is now available to all users of Visual Studio Ultimate and Visual Studio Test Professional – and you can read about the details around availability in Brian Harry’s blog.

I joined the Visual Studio Test group three and a half years ago, and assembled a team to build the Lab Management product. Putting together the team, figuring out what we would build and how we would differentiate our offering, the hard push to get part of the VS 2010 cycle, the building of the product, incorporating customer feedback and trying to ship with the rest of VS 2010 – all of this was a great experience. I held the product back to ensure that we had adequate customer adoption and addressed the important feedback we had received. A lot of hard work had gone into this product, so finally shipping this earlier in the month felt great! We had indeed built something very innovative, and getting it into the hand of customers was a fantastic feeling – it made all of the sweat and toil of the last three years well worth it! What a joy indeed!

As August winds to an end, it reminds me again, how life is such an intertwining of happiness and hurt.

Three and half years back was also a joyous time on the family front. I took on German Shepherd puppy – Archie – as the second pet in the family. He was going to be a great companion for the 6 month old Labrador (Asterix) and a darling for my boys, my wife, and me. Archie was six weeks old when we brought him in. Over the course of this time, he grew into a very handsome animal – extremely active, a great source of joy for us, and a core part of our family.

 

Archie had one problem though. He was extremely aggressive with all strangers – humans, animals, or birds. We have a big yard (fenced of course) in our house – and Archie would be all over the place – letting all strangers know that he did not appreciate their coming into his home. Our neighbor once remarked that Archie wouldn’t let even a fly get into our home without a good contest. I must admit I did feel proud of this trait.

We of course had to leash him up when we did want friends and others to come. I actually turned my two-car garage into a huge kennel for him – and put up steel collapsible gate that we would close and lock, he was in there.

But we had trouble. It wasn’t a completely fool-proof arrangement – we had a few occasions when our lapse led Archie to be loose when strangers were in our home and out in the open. Archie bit several people. Some of these bites were bad. I know if I were living in the USA still, the first such accident would have been his last one – I would have had to do something decisive about it. Here the system just happens to be more tolerant and lax. After each such accident I resolved to be more careful – but over time- we ran into newer lapses we learnt about – and each time, Archie would have bitten one more person. Some were complete strangers, and some were close friends. Some were complete acts of stupidity of the victims (why would the ignore the “Beware of Hunting Dog” sign on the gate and walk in?), and others were lapses on our part.

The count of such accidents rose - it reached 20 last weekend – and that was the last trip-wire for me. I finally took the decision that I would have to give Archie away :-( This led to a tremendous uproar in the family – the kids were particularly sad and angry too. Archie was too much part of our life. Ram Cherala suggested I contact Cesar Milan – though I didn’t know how I’d have possibly done that here in India.)

All of last week was very agonizing for me. How would I part with him? How could I betray his love for me? Who would I give him away to? I finally went back to the breeder that I had gotten Archie from, and he agreed that he would keep Archie in his home.

It was a sad morning today. I had to take Archie to his new home. I thought he looked sad himself – and took a last few pictures with the kids.

He has had a great time in our house – lording over the yard and sleeping on our bed.

 

 

I realized how much of a “dog’s existence” he would now have when I saw his kennel in his new home this morning

Archie reminded me again, though, how aggressive he can be with strangers – here he is clearly expressing his displeasure, and those vicious fangs reminded me of the pain he has caused to many.

Sigh! This was the right decision. I hope that Archie gets used to his new home, and perhaps I will visit him in a couple of months once he has gotten used to his new environment.

I returned back home with a heavy heart – remembering Archie’s first week in our home – an adorable and naughty pup.

Visitors to our home will now heave a sign of relief – no more to face this magnificent but ferocious beast – patrolling the boundary of our home.

 

 

But today, I know, we lost a part of our family – a faithful friend who would cheer us up when we were stressed and bothered by mundane situations. One who reminded us time and again what unconditional love was all about - yet it was I who betrayed him.

Archie – you will always be in my heart – farewell, my friend.

Identity Access Management (IAM) is a very complex aspect of IT. Finding someone that really understands it is a challenge. I have found one of those guys.

Corbin Links is an expert in the implementation of various forms of access management systems - commonly called Single Sign On by those of us that need to simplify. He is the author of a trilogy of books entitled "IAM Success Tips Volume 1-3".

Corbin has gotten involved with load testing because many times his projects for large enterprises requires his team to ensure performance of IAM. We at LoadStorm are fortunate in having Corbin as a user of our load testing tool, and he has been a delightful customer. Recently, he asked if I would come on his podcast to share some thoughts about performance testing relative to IAM.

Below is a summary of our interview Corbin calls, Stressing Out Your Access Management System.

Stress Testing for IAM

Many times IAM implementations sidestep stress testing because of inadequate resources or skills. Any enterprise will have 3-4 environments of IAM at a minimum. That necessitates much more testing. Usually there will be both internal and public facing environments. Typical provisioning of IAM will typically take dozens of tests and tuning cycles.

Two of the biggest challenges to stress testing an access management system are budget and time. It is common to skip load testing because it comes at the end of a project that is already over budget anyway. If the funding issue doesn't get you, then having someone available to actually build and run the tests might.

Corbin has been on projects that took 2 months just to install a big tool like LoadRunner and get the scripts created. Cost and staffing for LoadRunner were enormous drains on the project. He told me that IAM involves big heavy enterprise infrastructure that can run well into the millions of dollars. So, the erroneous perception of the CTO was that the load testing tool should be extremely expensive too. Corbin is changing that paradigm and saving his customers hundreds of thousands of dollars.

IAM Demands MORE Stess Testing

Corbin believes stress testing must happen at a minimum of 2 points in the cycle. It should be moved up into the development and debug stage, as well as test need to be run during the certification stage.

IAM implementers must be ready with a long term tool and staffing strategy so you don't have to go hit up purchasing for more test runs later. He emphasizes that SaaS models are very beneficial because of the speed and simplicity of the testing. Also, he advocates purchasing subscriptions with unlimited testing runs as far superior to paying by the test.

Subsequent releases or configuration changes can hurt your performance, so enterprise systems need more regular testing. In access management especially, there are thousands of parameters that define what happens in a transaction through authentication and access rules. If you change one of those, the entire system has changed and must be tested again.

Since the application rules are accessed dynamically, which determines the path from one point of the application to another, it is important to have the ability to re-test constantly with confidence. He also emphasizes how Http versus Https is a big deal in IAM implementation. You must test both of them thoroughly and independently. There is lots of overhead incurred with secured transactions such as credentialing and they must be performance tested with care.

Corbin recommends a fixed price stress testing tool to eliminate the hassle and worry about the cost of extra test runs - which are almost guaranteed to occur. In his experience, access management systems may need to run stress tests maybe 5-10 times a day. No one has time to continually set it all up again. Worse, there are so many meetings in an enterprise setting that have to be called to get testing done again.

The Importance of Good Performance in IAM

Response times are crucial in access management systems. Both B2C external pools and large internal user pools must be considered in stress test coverage. Internal users will be more patient on a corporate portal because they must use the systems to do their job. However, in a B2C model the external users will not wait.

Implementers of IAM need to ensure that users will not have to wait because slower performance results in lost customers. See this blog post entitled Web Performance Tuning = 10% Profit for the facts about how 7-12% revenue is lost by making people wait.

This is a great cost justification for load testing. In most of Corbin's access management system implementations stress testing is usually viewed as a cost center issue. If you have these statistics about revenue and performance, it will help you get further up the food chain to fund the testing to guarantee IAM will perform as well as it can.

He points out that there is incentive on the internal portal too. Many times companies don't understand the value of IAM. If people start to wait for it, they will circumvent the access management system. Offline systems like spreadsheets and ad hoc document storage will become popular. If the system doesn't work quickly, users will get creative to not use it.

Unique Requirements of IAM

Enterprise grade access management tools sometimes use front end login pages that are comprised of an insane number of objects. Many tiny pieces of Javascript and images. Corbin has seen one IAM tool that had over 100 nested CSS stylesheets for a login page.

Authentication checks on all of the objects create security overhead that is in addition to the normal requests of a web page! This extra processing poses challenges that most load testers haven't encountered in other web applications. Corbin emphasizes the need to optimize these processes because they can kill performance adoption, which will in turn kill adoption of the access management system.

Extensive re-directs are common in access management systems. Front-end processes capture data about a user, then it must make a decision about the user before allowing the request to be serviced by the web application. There are many load testing tools that Corbin has used that can't handle multiple re-directs. It is very important to test for that in IAM.

Access management implementers are usually over-tasked, and they aren't load testing experts. So what should they focus on for quick certification? Hammer on the front door. Focus on the login process. It's important to stress test with a file of many unique users and create a scenario that goes through a successful authentication. You need a heavy volume of concurrent users getting logged in, so find the peak number of users in your situation, such as 8:00am, and add about 25-50% of users. Then run a load test at that higher peak volume to have ensure you can have faith in the performance of your system.

Because access management utilizes methods such as sticky sessions and secure session cookies, you must test with many different users in the scenarios.

Gracious Host

Corbin asked me about the upcoming enhancements to LoadStorm. So I shared a few of those in the podcast - proxy recorder for scenario building, extra reporting data, scale up to 500,000 users, server-side monitoring during tests, and controlling geographic sources of traffic.

I thoroughly enjoyed the podcast interview, and I have had a great time working with Corbin on projects for his enterprise clients. I look forward to our next chance to work together.

Please check out the Identity Access Management Success Podcast with Corbin Links on iTunes.

Important resources mentioned on the show

* IAM Success Audio – Collectors Edition – http://bit.ly/iamcollectors
* Loadstorm.com – http://www.loadstorm.com
* Corbin Links on Twitter – http://www.twitter.com/corbinlinks
* Corbin Links’ new web contact page: http://www.corbinlinks.com
* Corbin Links on LinkedIn – http://www.linkedin.com/in/corbinlinks
* Comprehensive article on how to stress test an Access Management System – http://bit.ly/namstorming

Our test management software TestRail is still a rather new product, especially if you compare it to some of the other tools in our niche. That’s why we were especially happy to see that so many teams adopted TestRail as their new test management tool. A lot of those teams switched to TestRail because they weren’t happy with their existing solution. Here are some of the quotes we received from customers about TestRail so far:

We are very grateful to receive such positive feedback and testimonials. Thank you! We really appreciate it. If you also want to contribute a quote, please email us. You can see more TestRail customer testimonials and reviews on our website:

TestRail Testimonials

Pardon my American “gun-loving” nature while I start this blog post with an analogy about guns. Let’s say that I’m interested in learning how to shoot a gun, so I go visit my local shooting range for instruction. The people who run the shooting range (which is fully licensed and very reputable) give me extensive safety training before finally issuing me a gun with some ammunition. While standing in front of the target, I carefully load the gun, point the barrel at my foot, and pull the trigger.

So whose fault is it that I just shot myself in the foot? Is it the shooting range’s for not issuing me special bullet proof boots or for not training me even more thoroughly about the dangers of shooting my extremities? Or is it mine, for shooting myself in the foot?

A recent Windows “bug” has put Microsoft in the position of the shooting range. I put “bug” in quotes because it’s hardly the shooting range’s fault that I shot myself in the foot, but it’s still their problem in the end. Same with Microsoft who must now deal with an annoying flaw in their DLL loading behavior that isn’t their fault but has become their problem. Ars Technica explains the problem very well, but here’s a quick summary of the issue:

For the uninitiated, Windows applications may have their functionality spread across dozens or even hundreds of files called DLLs. When you tell your application to perform a task, the instructions for performing that task might be contained in a DLL file somewhere with the application or even as part of Windows itself.

Now there are two places an application can look for a DLL file. The first place is simple – wherever the developer explicitly says to look. That’s the way Microsoft says to do things (and has for 12 years), and it’s the safest approach to use. But Windows supports another approach which is to look for the DLL file wherever the application happens to be looking for other files. In other words, if your application is an MP3 player, and it’s loading an MP3 file from your media directory, then it can also look for necessary DLL files in that same directory.

This is legacy Windows behavior – a lot of old applications expect Windows to work this way. But it’s also incredibly dangerous. All I need to do to break your application is to put a hacked DLL file in the same location as another file I want to open. Microsoft realized this was a problem a long time ago, so way back when they released Windows XP SP1, they made it possible for a developer to turn off this behavior entirely within their software. So it was a huge surprise when security researchers recently announced that 40 different applications (including iTunes for Windows) were still vulnerable to DLL loading bugs because the app developers forgot to do disable the legacy DLL loading behavior.

This puts Microsoft in a bind. On one hand, they have to support a legacy behavior for older applications that a few people still use. On the other hand, developers are still writing buggy code that doesn’t take advantage of the security features that Microsoft has offered for years. This issue is plainly the fault of the developers, but in the end it has become Microsoft’s problem.

So what’s the solution? Microsoft has released a hotfix that lets you turn off the DLL loading behavior entirely, but you should be careful using this as it may break some poorly written applications. Then again, anything that doesn’t work after you install this is broken anyway, right?

In the long term, what should Microsoft do? They’ve long maintained a strategy of maximizing backwards compatibility, but sometimes it backfires with problems like this. Should developers be responsible for writing their code securely, just like they should avoid other bugs such as buffer overflows and race conditions? Or should Microsoft break support for some older applications to better safeguard new ones? Of course, breaking that support may require you to upgrade your software, or even buy entirely new software if the original developer is no longer in business.

What do you think?

A week or so ago I was working on “owner code reviews” for changes made during the Surround SCM 2011.0 development process. Part of our code review process is that every source code file is “owned” by a developer and, when another developer makes a change to a file you own, you review it. While I was reviewing files it occurred to me that it would be really nice if the Surround SCM GUI Client had an “Open with Finder” or “Open with Explorer” option that made it easy to open a file with the default application configured for that the particular file extension. For example, Qt UI files would open with “Qt Designer”, header and source files (.h, .c, .cpp) would open with Xcode, etc.

I pitched this idea to another developer on the team and, as it turns out, the Surround SCM GUI Client already has that ability. I figured that since I was unaware of it, it would be a great topic for my next blog post.

To activate this feature:
1) Launch the Surround SCM GUI Client
2) Open the User Options dialog (Tools -> User Options)
3) Select “View/Edit File” in the pane on the left side.
4) Select “All other text files” (“View”) and click the “Edit…” button.
5) Select “Associated Application” from the “Open files with:” combo box.
6) Click “OK”.
7) Repeat 4-6 for the remaining file types.

Now try it out. Select a file from the source view window, right-click (CTRL-click),  and select “View File” or “Edit File”. The default application for the selected file should launch.

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

In the beginning was the word. And thanks to Guttenberg, the word was often enclosed in a glossy book and sold for $49.95 at my local computer store. The noble computer book with a shelf-life of six months was the perfect solution for a piano with a missing wheel. Computer books (part of the discipline of book-learnin’) are an increasingly endangered species. Sales of computer books have been off by 8 to 10% year over year for a decade, a trend that shows no sign of slowing.

Still, I miss old-school, printed computer books. It wasn’t so much what they contained, as what they quantified. Using the Rumsfeld model, a nice fat computer book helps me quantify the unknown unknowns. As I tackle a new body of knowledge – say a new language or IDE – the unknown unknowns are infinite. As soon as I have that book in my hand, the unknown unknowns turn into known unknowns. I now know how much I don’t know, and the table of contents is my new best friend – whether I read the book or not. It is hard to beat stretching out at the cottage with a refreshing beverage and the latest tome on source code analysis.

But software developers don’t typically think in linear ways. While many of us are college or university trained, in spite of years of classroom training we run away from learning new knowledge in the old school way. Developers search for the answer to their current problem, rather than accumulating knowledge for its own sake. They listen and watch communities, RSS feeds and blogs for trends. They look for on-line videos, podcasts, newsletters, and magazines. They may even find a book in PDF, and print out a few pages that they want to use for reference.

The challenge for technology companies is to make our collection of facts, tools and interfaces accessible without binding it all up in a single document with a cover. Wikis, on-line API tutorials, developer communities, and a host of other information bits need to replace the old book model.

Of course, it’s hard to argue with Groucho Marx, when he said “Outside of a dog, a book is man’s best friend. Inside of a dog it’s too dark to read.”

Sonatype will be holding a much anticipated webinar on Hudson Integration with Maven Studio for Eclipse next month.  On Tuesday September 28 Senior Systems Engineer at Sonatype, Blaine Mincey, will host a webinar that will show you how Hudson Integration will increase productivity, by allowing you to view the build results from your Hudson jobs within your own IDE.

This webinar will highlight features that are available with the Hudson Integration feature of Maven Studio for Eclipse. It will review the benefits of Hudson Integration directly from your Eclipse development environment.   Finally, it will demonstrate how you can track the status of interesting jobs in Hudson so you know immediately if something needs to be fixed without leaving your IDE.

Hudson Integration with Maven Studio for Eclipse webinar:

• Tuesday September 28, 2010
• 6:00 am PDT, 3:00 pm Europe Summer Time (GMT+02:00)
• To register, please click here

 

Who? Damon Poole, AccuRev Founder and CTO, Agile expert and popular speaker.

What? Presenting “True Agility Requires Us to Re-examine Our Beliefs” for Nashua Scrum Club.

Where?  45 High Street, Nashua, NH 03060

When? Thursday, September 9, 2010

Why should you attend? Damon says “Too many projects that “go Agile” are actually far from true Agility. They end up reverting to old habits or just change the labels on the activities that they are doing without changing what they actually do on a day to day basis. As a result, many so-called “Agile” projects get few if any of the benefits of Agile and some are even worse off than before! Why does this happen?”

This session will give you an opportunity to uncover and re-examine your mental model of software development by taking a look at the top ten Agile blind spots. This will allow you to discover the blind spots you or your organization may have so that you can work towards removing them and start experiencing the full benefits that true Agility offers.

Visit Nashua Scrum Club to register!

Inspired by the Top 10 Performance Problems post which focuses on Server-Side performance problems taken from companies such as Zappos, Thomson, Monster and Novell I came up with the Top 10 Client-Side performance problems in Web 2.0 applications I’ve seen when working with our dynaTrace AJAX Edition users. Symptom: JavaScript blocking resource downloads and slowing page [...]

Ranorex 2.3.4 is now available and includes the following release notes: General changes/Features

• Improved support for Visual Studio 2010 (GAC list now correctly shows Ranorex assemblies)
• Added method to get an image of the current mouse cursor
• Improved performance for recording and repository code generation

Bugs

• References to repository screenshots are now updated correctly if a screenshot is renamed
• Improved drag & drop of repository items into recorder view
• Fixed issues with recordings not being marked dirty in Ranorex Studio
• Allow undo/redo after saving a repository or recording
• Report view in Ranorex Studio now correctly supports Print, Print Preview, and Save As
• XML report is now correctly written even if Ranorex process is killed
• EnsureVisible now supports scrolling in WinForms ScrollableContainer controls
• The "class" attribute is no longer used for WinForms elements in RanoreXPath
• Fixed EnsureVisible for WPF ComboBox items
• Fixed code generation for string values containing the Unicode line separator character (U+2028)

Download and get the latest version of Ranorex here
(You can find a direct download link for the latest Ranorex version on the Ranorex Studio start page.)

In the third and final installment of our Testing the Limits interview with Ben Simo, we go back in time to the early 90s to find out how and why he entered the testing profession. We also rapid fire some questions on his browser of choice, his hardware preferences, hobbies and more. In case you missed them, here’s part I and part II.

*********

uTest: Let’s go back in time for a second: How did you get into the craft? What was the first application you tested? What was testing like back in the early 90s?

Simo: Providence. It was providence that got me into testing.

I was young, in love, and planning to get married.  I had been doing some part time database development work, but needed a full time job before the wedding.  I submitted letters and resumes to dozens of companies. I was willing to do almost anything that would pay the rent.  I lived in a city where the local job market was dominated by defense contractors. I quickly learned that many of them called nearly everyone who applied for anything in for an interview; so they could learn about people and add them to databases of potential hires for matching to work they did not yet have.  These companies would then present these people to the government as their available workforce when bidding on contracts. This made it frustrating for those of us looking for work. It often wasn’t clear, when going in for an interview, if it was for a real job or for a potential position that might come at some time in the future if that company were to be awarded a government contract.

I interviewed with the company for which my fiancé (now my wife of 19 years) Sophie worked. It appeared to be one of those information gathering interviews without an actual position to fill. I was asked a lot of questions but none seemed related to a specific opening.  At the end of the interview, the interviewer said he’d be calling me.  Time went by without any more contact. Nearly a month later, I got a call asking if I could start the next morning.

I was one of a handful of people hired to work as “data collectors”; to execute tests and collect results for an interoperability demonstration of digital imagery systems.  These systems, from a variety of different vendors, were used by the military for manipulating and exchanging digital photographs.  This test was the second phase of an effort to validate a new communications protocol standard. Our mission was to assess to what extent systems made by different companies could exchange information over a variety of communications systems. We were given a huge matrix of imagery systems and communications equipment (from encrypted telephones to push-to-talk radios) combinations to test. We quickly learned that this required we learn the communications systems, the imagery systems, and the protocol used to exchange data.  I enjoyed this challenge. By the end of the project, I found myself in the role of being the writer of the test report and numerous interface documents. I also learned that I enjoyed testing.

If I hadn’t received that call which led to becoming a tester, I would have likely taken a job as a pay telephone technician. We all know how cell phones have since killed the pay telephone business.

So, what was testing like in the early 90s?  For me, working for an independent fee-for-service testing organization, it was a great learning experience.  I learned that my role as a tester was to help our clients produce better products; not to just pass or fail their products.  I learned that every company followed different development and testing practices – regardless of what labels they gave them.  I learned to seek guidance from others who could mentor me. I learned that continual learning is essential in testing. I learned that testing is a better assessment tool than an assurance tool. I learned to plan and script testing only to the level of detail that made sense; understanding that some detail cannot be known up front.  I learned that testing is exploratory in nature.  I learned to communicate with stakeholders and developers. I learned that the real requirements aren’t necessarily the things documented in a technical requirements document.  I learned to create tools to help me accomplish tedious tasks and enable doing things I could not do manually. While I didn’t realize it at the time, I was becoming a context-driven tester.

After nearly a decade, I moved to working for commercial software development firms — with fear and trepidation.  I wasn’t sure that my skills would transfer to being an in-house tester. I soon discovered that they transferred well.  I spent a short time with some misguided “quality cop” thinking after I was given a “Quality Assurance” title before better understanding and returning to my context-driven roots.

Rapid Fire Q&A:

• Favorite movie of all time: My favorite movie of all time would have to be “Star Wars, Episode IV: A New Hope”. It is both one of my earliest and favorite childhood movie memories, and I still love it

• Favorite movie… that’s about testing or taught you something about testing: I don’t know about it being a favorite, but “Man of the Year” comes to mind. The movie was disappointing in that it wasn’t the comedy it was advertised to be; and the software “bug” on which the plot was based made little technical sense; however, it illustrates the potential risks of software not working as it should – either due to oversight or ill intent.

• Mac or PC: Commodore. I still do everything on my Commodore 64. Seriously, I’m a PC. I’ve not used a Mac in over 15 years.

• Browser of choice: I’ve recently come to like Chrome for most of my personal browsing. However, I prefer Firefox for testing. There are many cool add-in tools for Firefox.

• Brand of smartphone: Motorola Droid X. After seven years of using Windows Mobile devices, I just switched to Android.

• Favorite US president (no fair picking Millard Fillmore… he’s my fav): Teddy Roosevelt. I can’t help but love an adventurer.

• Top tech innovator of all-time (Edison, Gates, Jobs, Andreesen, et al): Apart from the modern computer, Thomas Edison has likely had a great impact on humanity.  So, if I had to pick only one, I’d say Edison. When it comes to computers, Charles Babbage and Steve Wozniak come to mind. The ideas of Charles Babbage led to the programmable computers we have today. And Steve Wozniak was essential in making computers personal and bringing them into our homes

• Best concert you’ve ever seen in person: I haven’t been to a real concert in over 20 years. However, I have fond memories of Barry McGuire sitting on the edge of a stage singing songs to the last couple hundred stragglers who remained.after someone else’s concert.

• Hobby that would surprise our readers: Since I recently quit my job and am looking for new work, I could say that software testing is now a hobby for me. It will hopefully be paying work again, real soon. I could call my obsession with old programming books a hobby. I collect and read old programming and testing books to better understand the history of software development.

Photography and exploring Colorado are two things I could also call hobbies; but those won’t surprise anyone who follows me on Twitter. Also, we’ve got a bit of a zoo at our house with cats, dogs, and fish. That too should not be a surprise.

What may be a surprise is that I’m a recovering collector of NASCAR die cast cars. Yes, I was once an addict with new cars regularly arriving in the mail.  I’ve now been clean, and not added any new cars to my collection, for well nearly two years.

uTest: If Al Gore had never invented the inter-web and software testing didn’t exist… what would you be doing for a living?

Simo: I’d likely be a starving photographer. When I was eighteen, I was considering pursuing a career in computer programming or photography.  My father advised me that he’d encountered more starving photographers than computer programmers. So, I pursued software over photography.

Editor’s note: We hope you enjoyed our Testing the Limits interview with Ben Simo. Who should be our next guest? You tell us.

Whether you’re looking to test your shopping cart under load or automate the login process, we have you covered! QA Wizard Pro includes built-in support for creating, retrieving, and using web cookies during load test playback. This video provides an overview of how to manage cookies within a load test script, including the specific commands needed to create and retrieve cookies during playback.

Download video in mp4 format

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