by Test Vizor

A 20 year IT-generalist’s journey on improving software quality in large corporate environments and small agile ones through the adoption of context driven testing and DevOps tools and principles. Hopefully, you will find insight based both on successes and failures to help you effectively impact the quality of your software projects. We may even have some fun along the way with topics in Ruby, Elixir and pentesting.

Read this first

Ranking bugs

I recently ran across a well-intentioned request on StackExchange’s beta Software Quality Assurance and Testing group on ranking defects. Something to do with locating a good bug matrix to use.

This would have been my response, had StackExchange not decided my answer looks like spam:

It appears the option you found is very similar to the old idea of Risk Prioritization Numbers. It’s an artifact of performing Failure Mode and Effects Analysis or FMEA. People have created several variations of this over the years and attempted to apply it to software development activities like testing. The problem I have with it when used in this context is its subjectivity and, as a result, failure to faithfully relate the effect on the end user.


What is severe or highly likely for one customer may have no impact upon another. Of course there are exceptions … your software kills someone

Continue reading →

Is Exploratory Testing Just ‘Playing Around’

Take a moment to think about the importance of language as a tester, especially under the heavy shadows of larger business entities. It’s a topic often discussed in software testing circles when it comes to testing and for good reason. It’s important to bring up the less seemly aspect of this, because language, such as in the title of this post, is sometimes used in documentation describing test activities and planning or in verbal discussions with stakeholders. Have you seen it happen? What is the cost of using such language?

 Bureaucracy and Politics

One of the issues you have to contend with in larger organizations is the bureaucracy and politics that contributes to the officialism within them. Those things are often seen as bad words. That’s because political practices, official procedures and red tape are so often misused or abused that they have become bad words. They have

Continue reading →

New Context, New Beginning

I started this blog with high hopes. However, due to certain constraints, it has made more sense to hold some commentary until a more appropriate context presented itself. That time is quickly approaching.

I have roughly a dozen articles of much more interest than the pathetic smattering constituting my old content, which I’ve all but removed already, all in some phase of development. I hope you come back to read about some more interesting topics, such as:

  • How much value is there in ranking bugs?
  • Bug advocacy and avoiding bug genocide
  • Serendipity, I love you, but there’s a time and place for you
  • Expertise vs education
  • Developing expertise
  • A series on Toolsmithing
  • Best Practices: an origin story and the future
  • Advanced data collection to supercharge your testing
  • And many more!

Until then … gear up, vizors down and happy testing!

Continue reading →

A simple Ruby webserver for your testing infrastructure

On occasion, I run into the need to host some files on a web server to perform some testing. Whether it’s testing an embedded solution on smart, multi-function printers, serving files for mobile testing or facilitating some piece of automation, it’s nice to have a throw away web server when you need it.

Several scripting languages can pull this off, but since I’m partial to Ruby, I thought I’d offer up the Ruby flavored one-liner I use on occasion. I find this useful as it’s easy to just whip out on a command line any time I need it or fold it into more complex workflows.

Just type this in at the command line, assuming you have Ruby installed, and you’ll have a simple little file server up and running in seconds:

ruby -run -e httpd . -p 5000

Just a quick breakdown on what we’ve done here:

ruby -run -e
  • first, we’re kicking off the ruby interpreter, telling it we’re going to run

Continue reading →