US Dialects- fascinating maps

Once again, I love visual representations of data.  This is an enthralling map of US dialects.

American Dialects Mapped

I admit, I still say 'coke' for a generic soda.

A view from Home (alternative working arrangements)

I have managed remote team members before, both at home and in other locations.  I find more pros than cons with this arrangement.  Here in an interesting article written from the 'inside'.  Since I have never actually worked from home long-term, I find value in reading these thoughts as one who manages employees who do.

Experiences and realities of a homesourced IT worker

What have your experiences been?  (both managing and working with alternative working arrangements)

Agile: DONE-DONE (done... done... DONE)

An insightful article regarding some of the many temptations we face in Agile development.

Getting to "Done" in Agile Development

More on Perception

An interesting quote I ran across today:

"If men define situations as real, they are real in their consequences."

This is known as The Thomas Theorem, from two sociologists in 1928.   This highlights the disconnect between  [perception + expected rational behavior] versus [reality + actual behavior].

Again, we should expect this and prepare for this as test engineers.

See my earlier post on this subject:  On "managing" perception?

Aspects of Quality

A couple of definitions of quality:

• "The degree of excellence of something."
• "The standard of something as measured against other things of a similar kind."

Take a tool, any tool, walk out to a car, and measure its degree of excellence.  In what units of measurement will you report your findings?  Inches?  Cubits?  Shakes?  Nibbles?

Testers, in a very real way, are explorers.  We confront the unknown, and answer questions about it.  We then report our findings in order to bring a greater understanding of what we have experienced.  Over the years, I have put together a list of questions we explorers can ask in order to ascertain the level of quality in our products.

Important questions to ask in order to measure quality:

1. Does it solve a problem?
2. Does it provide a desired service?
3. Does it invite repeated use?
4. Does it work?
5. Is it easy to use?
6. Does it perform its functions well?
7. Is it stable under stress?
8. Can it recover from disaster?
9. Does it fit together as a cohesive whole?
10. Is it easy to start?
11. Is it easy to disengage?
12. Is it secure?
13. Does it compare well against similar products?
14. Is it easily maintained?
15. Is it easily moved or ported?
16. Can it scale to broader or more limited use?
17. Does it invoke in the user a positive emotional response?

Of course this list is may not be applicable to all products, nor is it exhaustive, but I have found it quite useful in assessing quality.

Are there any questions you would add?

History at your fingertips!

For those of us who love the study of history and graphical representations of data!

1931 Histomap

I wonder what this would extrapolate to now, and then again in 100 years?

On "managing" perception

In the rare instances I am able to corner a customer, executive, or business partner, I like to ask them what the current buzz is.  Are people generally asking for more features, or better quality?  This admittedly un-scientific and ambiguous question has value for me, as a leader in test engineering.  The answer to this question matters for a few reasons:

First, to get just a bit of an idea of what our pipeline is looking like... a push for more features or a focus on improving quality.

Second, to show them we care about what is being thought and said.

Third, and most importantly, to get an idea of how the perception of our products is trending.

As a test engineer, perception is just as important as reality.  If your products are perceived as being of poor quality, then people will more readily notice and magnify the smaller defects that exist.  In the same way, when you, as a tester, are seen as being incapable, disinterested, or ineffective, people will focus on all of your flaws and mistakes.  Furthermore, they will distrust all work you do, effectively rendering you useless to the organization.

In "managing perception", I recommend the following:

1. Communicate the context
2. Be honest
3. Be open
4. Communicate frequently

All too often, people manage it this way:

1. Report numbers without context
2. Ignore it
3. Obfuscate
4. Delay

To make it simple, don't worry about managing perception- just focus on proactively reporting reality in proper context.

Leadership note:  Remember to manage the perceptions of team (capability), project (status), and product (health).

Does anyone have horror stories relating to perception in testing?

Becoming the HumanTester

Welcome to my humble space.  My name is Brian, and I am a test engineering manager.  I have worked in testing professionally and as a hobby for almost 20 years now.  After having worked at a few different companies with wildly different technologies and processes, I have started to see patterns emerge.  I thought I would share these patterns and ideas, so that people may take note of, criticize, and refine.

I like passing along knowledge (not just my own) and decided to do this for more than just my work teams.  I hope you feel free to participate, and I hope we all become better testers as a result of this blog.

Onward!