I posted a reply to Phil Young on the MagenTys blog about “Re-Shoring.”  Below are my comments on that post.

I used to think that communication, culture, and face-to-face interaction were the important factors in why offshoring has failed.

But now I think it has more to do with the quality of services. Not that Indian or Chinese (or whatever) testers are inferior, but apart from the cultural and communication problems, and despite the domain knowledge gap, the problem is really that offshoring as a strategy is flawed.

The idea that providing warm bodies to fill chairs in a cheaper location is a solution to quality costs is erronious. You’d have the same quality control problems if you outsourced a key component of your business to Arkansas (or Wales).

The act of delegating tasks to someone whose priorities are not your own is the fatal flaw. They are incentivized to produce numbers at low cost. That’s the core problem — on top on any other problems inherent with remote teams in general.

But, remote teams — even distributed teams — can succeed if they are critical stakeholders in the business and not merely vendors. A distributed team can take advantage of the best talent wherever it is, not just in London (or Silicon Valley.)

Vendors, on the other hand, should provide a clear product or service, not be a part of your business strategy. And quality should be an important part of your business strategy.

Vendors are by nature a centralized entity with their own quality and business concerns. That’s not to say you can’t find a high quality “quality” vendor, but I don’t see how it works for the typical use case.

Of course, take my spiel with a grain of salt. I’m a tester who works remotely and a consultant who helps build distributed teams, so I may be biased, but I believe in what I’m selling.

It’s time for a rant on dynamically typed languages.

Frankly, I’m embarrassed by the state of scripting languages these days.

The Python, Ruby and Javascript communities have wandered so far from the principle of getting things done simply and quickly in a misguided attempt to cope with their insecurity of not being “big boy languages” or “hard enough to learn” that they have gone out of their way to make things esoterically stupid and obtuse in what can only be seen as a way to alienate beginning users.

I can’t recommend any of them to new programmers.  Each has had their moment in the sun, usually shortly after the previous reigning scripting language has gone off the deep end.

Perl has long gone the way of esotericism, and if you’re interested in asking yourself (over and over again) — what is an object really, it’s a good language to revisit from a purely academic standpoint — or if you’re stuck at Amazon or maintaining an old media web site.

PHP frameworks struggled to catch up with Ruby on Rails, but I defy anyone to start with Rails as their first framework nowadays.

I’ve never tried Laravel, but PHP has made strides for improvement but it’s probably too late, with too ugly of a codebase to move forward.

Ruby refuses to test on anything but a Mac and is no longer supported on Windows (or operable with MySQL or SQLite or MongoDB on that platform).  It’s pretty much a free for all on Linux.  And while gem, bundler, rake, capistrano, less/compass, sinatra, etc are all nice tools, they should not be required for hello world.  And unless talk like Yoda you do, read well it does not.

Python has always had the sore thumb of whitespace issues — suprise!  people still cut and paste code from the internet.  And suprise again!  it’s in plain text, not your favorite editor’s in memory document map.  Python has also had Ruby envy and a proliferation of tools.  Pip is almost as easy to use as easy_install and almost as well supported.  But watch out for Python 3, and beware of 32/64 bit compatibility across libraries in this text-based scripting language.

Javascript emerged as a serious contender with node.js and the V8 engine which finally gave serverside javascript the performance and stability it needed to take off.  Combined with the JQuery locator function and compatibility wrapper, you finally had something exciting.

But creating cool apps fast got boring faster.  Npm was a great package manager — only it only worked on the server.  So create a different standard on the browser — or two or three.  And use br^H mungify to convert!  But then, why not use grunt, yeoman, and bower to really abstract the word “require” which really just does a good job of reading files into the interpreter.

And port every one use tool from ruby with a different syntax.

Still, I really liked javascript.

But wait.  Javascript is flexible — you don’t have to program in a straightforward syntax — so why should you?  Make everything a callback, and pass functions to every function — even if you don’t have events or async code.

Scala — you could have been the next big thing.  Optional dynamic typing — but maybe Groovy proved how hard it is to be a scripting language on the JVM and still have performance.  So instead, you try as hard as you can to tell people you can only program Haskell in Scala.

Okay, I’m done ranting.  Time to get some work done.

 

I was also asked what programming language you should use for automation.  Here’s is my response to that question.

Regarding the programming language you use for automation — I don’t think it matters.

A few points to consider:

1)  What language will the product developers around you be using?

You should consider using what they use because you can ask them for help and it might make for a more consistent base.

2)  What platform will you be deploying to?

This isn’t a big factor, but if you’re using Linux, probably don’t use C#, but if you’re a Microsoft shop, there’s nothing wrong with it.  It will also be easier to work with your existing tool chain (e.g. build tools)

I don’t think anyone needs told not to use Objective-C even if they’re an all Apple shop.

3) Do you value static or dynamic typing?

They both have pluses.  I like that I can build a framework that’s intuitive to use (especially in an IDE) when I use static typing, but I often get frustrated by the hoops I have to jump through (using enums and collections) to do so.

Sometimes it’s easier to just get things done in a dynamic language.  And it is still true that they’re easier to learn and the lack of a compile step can help speed things up.  But type safety is nice too.  I guess it depends on your own personal style.

I got an email from a fellow tester recently asking what he could do to move from manual testing to automation. Here’s my (slightly edited) reply:

Shifting from manual testing to automation involves two main things I can think of from the start.

The first is obviously technical. You need to learn programming. How much depends on the tool you use. Some tools help hide the details of programming, but since you mention Selenium, I’ll assume that’s not what you’re talking about.

It doesn’t take much to learn the basics of programming. But it’s easy to miss some important principles and work harder than necessary creating less than optimal code if you don’t understand good programming principles. I won’t go into that in detail here other than to emphasize that the better programmer you are, the more reusable and maintainable your automation will be.

Apart from the technical aspect of programming, I think good testers already have many of the traits of good programmers — analytical mindset, precision in language, creative problem solving, and and attention to detail.

The second thing you need when moving from manual testing to automation is more subtle. And that’s shifting from an exploratory mindset to a defensive mindset. More plainly, you won’t be looking for problems with automation, you’ll be looking to prevent problems.

Your goal with automation should be to check that software is valid, not to find problems. As a manual tester, you’re rewarded for finding subtle problems — but as an automated tester, you’ll be limited to what you can anticipate with your automation, or you’ll tear yourself up trying to write predictive code.

The goal of automation isn’t to find new defects, it’s to verify expected behavior, and to stop regressions.

There are two points to keep in mind when you write automation.

1) Everything can’t be automated, nor should it.

Some things are too hard to automate reliably — or take too long to do so. Some things are easier and faster to do manually. And automation can’t notice anything wrong that it’s not specifically told to check for. Humans can.

2) Automation frees up manual testers to do exploratory testing and provide rapid feedback on things that are not easily automated.

Automation doesn’t replace manual testing, it enables it.

You should consider automating things that are repetitive, error prone, or to slow to do by hand. But you should also realize that not having a human check an area of functionality means that the person would not notice if other things go wrong (even simple things) in related areas.

Personally, I still like testing. And I like that my automation helps me to do better testing. I’ve found that when automation is not an expression of my testing (e.g. when I’m only writing automation, and not also doing exploratory testing) that not only does quality suffer on the product, but that my automation is less effective than it should be.