I had a new son delivered on April 3, 2015. Mikey is healthy. More details coming soon.
I’m not an SEO or marketing expert. But I am a testing expert.
And I am an entrepreneur who thinks about SEO and marketing. I create content about software testing (in part) to hep find customers for my test consulting business and network with other software testing and development professionals. I’ve also done my fair share of web development.
I’d like to know more about SEO, inbound marketing, and creating online content and connecting through social media. As a tester, I’m curious about the metrics and strategies SEO experts use to test their effectiveness and shape their content creation strategies accordingly.
So, I guess what I’m getting at is that I’d like to meet, and get to know and SEO expert and learn how they measure success and what their clients expect. I’d like to serve an SEO “apprenticeship” if you will, and maybe exchange services — I can build tools for content generation and distribution, measuring SEO effectiveness, and actions for turning views into actionable leads.
I’d also like to talk with businesses who are interested in SEO and inbound marketing, hearing what their strategies are, learning from their successes and failures, and maybe help them test the effectiveness of their SEO and marketing campaigns.
Here are some facts about software testing I compiled to help me seek clarity about what is needed and what can be done to improve the state of software testing.
- Software testing is a multi-billion dollar industry.
- There are three segments to the software testing marketplace: tools, services, and infrastructure.
- Testing is a young and growing discipline.
- Testing is a craft.
There is no strong academic or vocational discipline for testing.
Some great preliminary work has been done to codify testing practices, but testing is primarily learned by mentorship and trial and error.
There is no clear career path to testing.
No one says “I’m going to be a tester when I grow up.”
Indeed, few people know of the role before entering into it.
Fewer still set out to become a tester.
- Testing consists of two primary facets: regression testing and exploratory testing.
Both are necessary. The way they are approached should be different.
The process should be different for regression testing and exploratory testing.
A single tool does not fit well with both processes.
- There are two means to accomplish testing: manual testing and automation.
There is a gap in skill sets between the two.
There are some things that can only be accomplished well through manual testing.
There are some things that can only be accomplished well through automation.
There are some things that are better suited to either manual testing or automation.
Few people understand the needs of both manual testing and automation.
Fewer have the skill set and inclination to do both.
There is a gap in tools between automation and manual testing.
- Testing is largely inefficient.
Many testers are poorly trained.
Many testers developing automation are inexperienced in development or lack formal development training.
Software development best practices are rarely practiced in test automation — largely due to this lack of training.
Testing tools are marketed to and geared towards test managers and gathering metrics, not tester productivity.
Testing process is often not clearly defined.
The features and requirements to test are often not clearly elucidated.
Even when they are, they are not well prioritized.
- Testing is often an afterthought.
Testing organizations are often understaffed and resources.
Testers are often considered less valuable than developers.
Developers often don’t want to test.
Testing environments are often inadequate.
Time available for testing is often cut short.
- Expert testers are rare.
This may have to do with the lack of rewards and appreciation testing receives.
There is not a clear senior career path — senior testers move into management, development, or business analysis.
Senior testers should be mentoring junior testers.
Senior testers should be designing testing tools and processes.
Senior testers often make less than junior developers and low level managers.
Many testers burn out.
Including those who have a passion for testing.
A passion for testing is rare.
Many testers see testing as a stepping stone to development or IT management.
It is difficult to break out of the testing “ghetto” once labeled a tester.
Expert testers are good developers.
Senior testers understand the business as well or better than any business analyst.
- Creating something (development) and testing something are two different skillsets.
They have different goals.
It requires a different perspective.
Verifying something works and finding ways something will not work are not recipricol functions.
- Testers are focused on quality.
No other part of the organization is as concerned with quality.
Development strives for quality.
Customer support feels the effects of poor quality.
Testing measures quality.
Quality is most often the item cut from the list: Quality, Speed, Price — pick two.
Quality is rewarded in the marketplace more than quickness or cheapness.
A quality perspective can be taught.
Technical skills can be taught.
- Organizations need better testing tools and processes, and they need expert testers to use them.
- They need dedicated testing infrastructure, and they need someone who can help them see how to implement and organize testing.
I can help you:
- Identify and implement tools and processes for testing, requirements & defect tracking.
- Provision and configure IT infrastructure for test environments and tools.
- Create a culture of quality and enable testers, developers, and business to work together to achieve this goal.
- Find, interview, and train expert testers for your organization.
- Provide additional testing resources to fill your need for scarce resources.
- Develop valuable, maintainable test automation and train your testers how to do the same.
- Bring the results of manual and automated testing (including developer tests) together for clarity on what business features are actually being tested.
- Build products in a way that makes testing easier.
- Inject testing into every step of your business process from initial concept to customer feedback.
I’m focused on building tools and defining processes that make testing easier and more effective. I’m also learning that testing skills and training are often lacking, and that good testers are often under-utilized, under-appreciated, and hindered by technical roadblocks, management apathy, and lack of organizational clarity about what testing provides and what testers need to accomplish their goals.
I want to improving testing, with these three goals:
1. Finding and developing expert testers.
2. Building better tools for testers.
3. Helping organizations improve quality processes.
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.
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.
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.
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.