"Developer Experience" as an Aspect of Quality

Recently, a leader within my organization sent excerpts from Designing Great Web APIs around for reading, reflection, and discussion. The subtitle of this book is "Creating business value through developer experience."

James Higginbotham, the author, asserts that "entire markets are emerging where APIs compete for the attention of developers." I agree with this, and it tempts me to include this in my big list, Aspects of Quality. I could tuck it under 'invites repeated use', but I'm not sure that calls this out specifically enough.

As we design systems that are more open, made more as the middle-man, meant more for consumption of primaries, this becomes a critical factor in judging quality.

If we do look to test this specifically, what kind of test would it be? Usability? Desirability? Something new?

For now, I will think on these things, and look forward to your thoughts.

You can hear me in the harmony

I am a fan of Harry Connick, Jr.  The man can sing.  The man can swing.  The man has more going for him than any natural man should have.  But hey, more power to him.

I listened to his tune You can hear me in the harmony this morning and it got me thinking.

Recently I wrote a post about people who think testing is merely a supporting role.  While I certainly think most testing activities are equal in importance to other development activities, and should be considered as one within the SDLC, there is also this harmonious component that Mr. Connick, Jr. reminded me of.

So much of the art of testing and leadership is being able to accept and get really good at singing harmony.  We aren't called to be the Bono-like lead singer- with charisma, leather pants, and spotlights dripping off of us.  We are the person in the shadows, perfecting our art, contributing where we should, and taking satisfaction in helping others see their vision come to life.

I suppose this is just another aspect of the servant-leader model, but I wanted to call out a few thoughts.

I try my best to look at every single person in a way I look at a dear loved one.  They are individuals with talents, weaknesses, struggles, and joys.  They have goals. They have passions.  They deserve great things.

They are most certainly not a means-to-an-end.  They are not resources.  They are human beings- wonderfully imperfect and deserving of respect.

A definition of love that I cling to goes as follows:

Desiring the good of the other as other.

In this light, I strive to serve them (stakeholders, employees, co-workers), in the background, in the harmonies, in order to help them achieve their goals.

A further thought I had, is that, beyond this individual view, an organization is very much like a band.  Everyone has certain roles, and those roles can change over time, but the final product looks a lot like a group of people on stage putting on an inspiring show.

Think of all the people needed just to get that band on stage.  Roadies, managers, ticket-takers, sign-makers, janitors, sound and lighting engineers, and someone willing to take a risk.  MOST of the effort put forth is by those living in the shadows, living in the harmony.

Realizing these few things helps me to stay focused on what is important in testing and leadership.  I hope to be the best back-up singer I can be, and take joy in seeing the lead singer shine.

And now- Harry Connick, Jr.

Deadly Defects

Toyota settles acceleration lawsuit after $3-million verdict

Toyota Motor Corp.'s first loss in a sudden acceleration case, in an Oklahoma courtroom this week, could embolden attorneys nationwide who are looking to bring hundreds of similar cases.

Worse for the Japanese automaker, the verdict centered on the company's electronics, which have been a focus for plaintiffs seeking to prove safety defects in the company's cars.

Toyota on Friday confirmed that it had reached a confidential settlement in the lawsuit, which involved the fatal 2007 crash of a Camry. The settlement came hours after a jury assessed $3 million in compensatory damages but before the panel could levy a punitive award.

The verdict could provide a road map for attorneys seeking to hold the automaker liable for injuries and deaths.

Things can get serious in the world of Test Engineering.  Again, this points to a need for Test Engineers that can do impact analysis and risk assessment.

Testing Infinite Scenarios

I have been involved with implementing integration into a mapping service.  I am thankful we were not responsible for testing the accuracy of the third-party GIS (Geographic Information System) service itself, but only the integration of the service with our solution.

However, in testing we did notice a few problems with some of the information we were receiving.  Some of our client properties were not displayed correctly.  They were *close*, but not exact.

When I read this article yesterday, I was reminded of an anxiety I had when I tried to place myself in the shoes of those implementing and testing the GIS itself.

Apple Map flaw results in drivers crossing airport runway

As test engineers know, most test configuration matrices are massive (exponentially affected when adding new configurations), but the GIS testing poses a truly staggering challenge.  Nearly infinite scenarios.

In these times, I use my handy-dandy guide to prioritizing test cases:

1. Do an equivalence analysis (what configurations/scenarios are the same for testing purposes)
2. Do a risk/impact analysis (what happens if something goes wrong?  do people die?  is revenue impacted?)
3. Do a change set analysis (what has recently changed?)
4. Prioritize your configurations (what are the most common configurations?)
5. Prioritize your functionality (what is the most commonly used functionality?  usage statistics are very handy here)
6. Identify the complexity and time-to-test of the different configurations (prioritize complex tests lower, all other factors being equal)

However, I feel like something is missing in my list above, with regards to this particular GIS problem.

How would you approach GIS testing?

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?