The Testing Show - Conferences and Conferring with Anna Royzman, Claire Moss and Mike Lyles

I have been terrible with my shameless self-promotion as of late, but I think it's time I switch that up a bit. Remember my comment about that "grind" earlier in the week? Here's the end result and yes, I always feel better about it after it's all said and done because I enjoy seeing the end product and most importantly sharing it with everyone out there.



I have a little favor to ask as well if you are so inclined. Do you enjoy listening to The Testing Show? If you do, could I ask you to go to Apple Podcasts and write us a review? Reviews help people find the podcast and make it more likely to appear in the feed listings. Seriously, we all would really appreciate it. We work hard to bring these out and I'd love nothing better than to have more people be able to find it.



In any event, we hope you enjoy this month's episode. To set things up, here's the lead in for the show:

August is a busy time of year for software testing conferences (not to mention conferences in other industries). This month, we decided that, with everyone heading off to conferences hither and yon that we would dedicate a show to the topic, and we have done exactly that. Anna Royzman (Test Masters Academy), Claire Moss (DevOpsDays) and Mike Lyles (Software Test Professionals) join us as guests in their capacity as conference organizers, speakers and attendees (not necessarily in that order) to riff on Conferences and Conferring with Matthew Heusser, Michael Larsen, and Perez Ababa. Want to know where to go, what format to take part in or if you want to try your hand at speaking/presenting? We’ve got something for all those bases!

The Testing Show - Conferences and Conferring with Anna Royzman, Claire Moss and Mike Lyles: The Testing Show team discusses the QA conference season with Anna Royzman, Claire Moss and Mike Lyles. Tune in to learn more!

When There's Nothing But The Grind

First off, I want to make sure that this doesn't come off sounding wrong. The title is accurate, but perhaps not for the reason folks might suspect.

As the Producer and Editor of The Testing Show, the heavy lifting of getting a show finished and up on Apple Podcasts is done by me. Yes, when we schedule the recording the panel and guests are all in on it together. When I deliver it to QualiTest, they take care of posting it so it's available. At times I am able to outsource the transcription process, but not always. This episode, it's all in my wheelhouse due to vacation an unavailability of my regular transcriptionist (who does a fantastic job, I might add and worth the price to have them do it).

There's no easy way to say it; to produce the show to the level I want to have it, with as clean audio as possible, grammatical edits and a full transcription so those who are hearing impaired can follow along, there are no time-saving shortcuts. Every second of the audio needs to be examined, edits made, transitions cleaned up, and waveforms spliced so that there is a minimum of intrusion. If I've done a good enough job, the end listener should just think it's a seamless conversation. For anyone who has actually done editing for podcast dialog, you know what I mean when I say, as soon as you've done these kinds of edits, you forever hear them in other podcasts, too. Perhaps I'm a little too aggressive in this process but since I do it this way, it takes quite a while to edit each show. The tricky part is (since I'm dealing with edited audio and transcribing edited audio), this is the literal definition of an extended monotask. When I write code, test, or write these blog entries, I can have other things going on in the background, take little detours, let my mind idle for a bit and then pick up again. When I'm editing the podcast, I don't get that break. I have to be focused and nothing else can be vying for my attention while I do it. For veteran podcasters, this probably comes as no surprise, but I can (and frequently do) spend about six hours per episode from completion of recording until handoff for posting. It can really chew you up some days but there is no exhilaration quite like when it's all finished and the email goes out saying "It's all ready to post, have at it!"

To relay this to testing and the oft-heard fact that monotasking is the best way to accomplish a goal, I both agree and disagree. Having to switch contexts from one project to another frequently does make for inefficient work and I have plenty of experience with that in my everyday testing life. However, too much focus on one thing, even if I am "in the flow", will physically chew me up and fatigue me fast. Still, there's no way around it. The show needs to be edited, it needs my undivided attention and that undivided attention can easily spread to six hours per show. What to do?

This is where I have to exercise supreme diligence if I don't want to drive myself crazy. Was I a smart individual, I would block out the track immediately, determine where I could perform rough cuts, do them within the first hour, and then approach a fine tuning on subsequent days, spending no more than an hour at a time on any given day. Of course, that doesn't often happen. What typically happens is I find myself coming up on a deadline and then the sense of "compression" takes over. With that sense of compression the "procrastination adrenaline" kicks in. From there, I move Heaven and Earth to get it all done in one Herculean shot and, once I do, I feel both joyous that I have finished it and absolutely mentally drained at the sheer volume of the process. This, of course, lingers in my memory, but for some strange reason, it doesn't make me any more likely to be more diligent the next time. So many times, it really does come down to "Dude, this is the last day before the deadline, now you have to do "The Grind" all in one day!" For a long time I thought I was just insane, but as I've talked to many creative types in various capacities, this approach is way more common than I thought. In a way, the combination of "time compression" and "procrastination adrenaline" all come flooding in at once, and that sense of terror is both motivating and, again, exhilarating. It's terrible on the nervous system, though. The hangover that comes after completion is rough and I literally feel like I need days to recover. Yet time after time I find myself doing it again. It's as though there is a form of "project amnesia" that creeps in. Either that or my amygdala just craves that terror state and tricks me into doing it again and again.

Question for those out there reading this... how do you deal with a project that demands sincere monotasking? Are you measured and deliberate? Are you a procrastination adrenaline junkie? Somewhere in between? How do you deal with it? What are your approaches to making it more manageable? Don't get me wrong, I love producing the show and will continue to do so. I'm just looking for better ways of keeping what little of my overall sanity I have intact ;).

Coming off a Long Break

Hello, everybody!

With the exception of yesterday's post to Jerry Weinberg, this blog has been quiet for a few months. That was partly by design, but it stretched way longer than I intended it to. There was a specific issue I was trying to deal with (elbow procedure that required me spending less time on the keyboard) but in reality, for a time, I felt like I had come to an end of what I wanted to say. After eight years and more than a thousand posts, I started to feel like I was going through the motions, repeating myself, or just posting content to promote other content I was producing elsewhere.

I intended to take a break for a few weeks but that break stretched into almost four months. In that time, my work life changed considerably. My company was acquired for the second time. Socialtext is still a part of PeopleFluent and PeopleFluent is now a part of LTG based in London, UK. Dealing with the changes from that took a lot of getting used to. In those changes is the fact that much of our old approach to work and doing things went out the window. I've had to adapt to new roles, new needs, and a new overall view as to what we should be doing. As part of that change, I've been asked to:

- Be the Scrum Master for our Engineering team (those who say "wait, isn't Socialtext a Lean/Kanban shop?", the answer is "we were, but now we are aligning with Scrum principles so as to be in line with other teams").

- Investigate a new approach to automation (we will be embarking on using Cucumber with the two lower layers in a yet to be determined configuration but it will be totally different than what we have used up to now).

- Upgrade and update our overall infrastructure for how we build and deliver our software (mostly dealing with a Jenkins modernization and moving to pipelining but also looking at our container strategy and what we could do differently or better).

- Somehow still find time to test software in an environment where we are now adjusting to two-week sprints.

While "life has been happening while I have been making other plans" I came to the realization I actually have been unlearning and relearning a bunch of new stuff. Why haven't I been talking about it here?

- Partly out of fear.
- Partly out of feeling inadequate.
- Partly out of not really understanding what I'm doing.
- Partly out of feeling like I'm making this all up as I go along.

I then realized,  "Wait! That's the whole point of this blog." Had I waited until I was an expert on anything, zero posts would have been written and this blog would not exist.

I was asked a couple of days ago on Twitter about what to do when someone wants to start blogging but doesn't know what to talk about or feels they don't really have any worthwhile experience to share. I said to "just start" and "while you may not be an expert in X, you are an expert in your own experience with X. Start there." That may have been helpful to them, but I realized that it was most helpful to me. It reminded me that there's a lot I'm learning and relearning and that process is rarely pretty, often incoherent and usually frustrating. That never stopped me before. Why am I letting it stop me now?

If you're still with me, thank you for indulging my "navel-gazing" for today. I have a lot of stuff I'm working on, and things I've wanted to talk about but not felt it would be worth saying. That attitude is over. It's time I started talking about my own worldview on "fill in the blank" again. Looking forward to re-engaging. I hope you will be, too :).

Talking About Talking - a 1 1/2 armed #LiveBlog from #STPCON Spring 2018

Any time I attend a conference, I tend to go with 70% new content and about 30% familiar speakers. Over time, I've found it harder to look for new people because many of the people I get to know get asked to repeat present at conferences. With that out of the way, I consider Damian Synadinos a friend, but I picked his discussion for a specific reason. While I think he is intending for this to be about public speaking, I'm looking to see how I can leverage public speaking focus on my own active company interactions.

Why do I speak at conferences, at meetups, or at events? There are a variety of reasons but if I have to be 100% honest, there are two reasons. The first is wholly professional. I want to develop credibility. I want to show that I walk the talk as well as that I know at least an aspect of something. The second is personal and depending on how well you know me, this is either a revelation or so obvious it's ridiculous. I'm an ex-"RockStar". I used to spend a lot of time entertaining people as a singer and I loved doing it. I get a similar rush from public speaking, especially when people say they actually enjoy what I'm talking about and how I deliver the messages I prepare.

Part of talking in public is the fact that you are putting your ideas out there for others to consider. That can be scary. We own our ideas and our insecurities. as long as we keep them to ourselves, we can't be ridiculed for them. In short, people can't laugh at us for the things we don't put out there. Personally, I think this is a false premise. I have had people laugh at what I presented, but not because what I was saying was foolish or made me look dumb. Instead, it was because what I was talking about was in and of itself funny (actually, more absurd) but people laughed because they could relate. To date, I have not been laughed at. Laughed with, lots of times. If you are afraid people will laugh *at you*, let me reassure you, it's hugely unlikely that will happen.

The biggest reason why I encourage getting out there and speaking is that our ideas deserve to be challenged and we should want to challenge our ideas. Also, we may never aspire to get on a stage and speak, but all of us participate in meetings or presentations at work, in some form or another. By getting out there and speaking, we can improve our ability to function in these meetings. 

Something else to consider for a reason to give a talk or speak in public is what I call the "ignorance cure" for a topic. It's wise to talk about stuff we know about, but once a year or so, I will deliberately pick something I don't know much about or that I could definitely know more about. When I do this, I try to pick a timeline that gives me several months so that I can learn about it in a deeper way. People's mileage may vary with this, but I see a definite benefit from doing this.

Not every talk idea is going to be amazing. Not every talk idea is going to be some revolutionary idea. Truth be told, I'm lousy at revolutionary things. I'm highly unlikely to be creating the next big anything. However, I am really good at being a second banana to take an idea someone else has and running with it. Don't be afraid that something you want to talk about isn't new. We aren't born with ideas, and most of the time, we stand on the shoulders of giants.

My recommendation to anyone who has any interest in public speaking, no matter how small, is to borrow from Morrisey... "Sing Your Life". Talk about your experiences, as they will always be true and real. You may not be an expert on a topic, but you are absolutely an expert on *your experiences* with that topic. Also, if anyone wants to get up and talk, let me know. I'd be happy to help :).

Modern Testing Teams and Strategies - a 1 1/2 armed #LiveBlog from #STPCON Spring 2018

One of the fun part of being a "recidivist conferencist" is that we get to develop friendships and familiarity with speakers we get to see over several years. Mark Tomlinson and I share a ridiculous amount of history both in the testing world and personal endeavors, ao I always enjoy seeing what he is up to and what he will talk about at any given event. This go-around, it's "Testing Teams and Strategies" so here we go...

Does it seem common that the people who decide what you do and how you do it have NO IDEA what it is you actively do? I'm fortunate that that is not so much the issue today but I have definitely lived that reality in the past. It's annoying, to be sure, but often it comes down to the fact that we allow ourselves to be pigeonholed. The rate of change is insane and too often we think that we are being thrown into the deep end without a say if what happens to us. If we don't take some initiative, that will continue to happen to us.

I've had the opportunity over the past (almost) three decades to work in small teams, big teams, distributed teams, solo, and freelance. Still, in most of my experiences, I've been in what I call part of "the other" organization. That's because I've worked almost exclusively as a tester in those three decades (my combined time as a cable monkey, administrator and support engineer equals up to less than four total years and even in those capacities I did a lot of testing). Point being, I've spent more time as part of another organization that has been siloed. It's a relatively new development that I'm working on a team that's both small enough and focused enough where I'm actually embedded in the development team now. As a point of comparison, my entire development team is seven people; three programmers, three testers, and one manager. Really, that's our entire engineering team. That means that there is too much work and not enough people for anyone to be siloed. We all have to work together and in reality, we do. My role as a Tester has dramatically modified and the things I do that fall outside of the traditional testing role is growing every day.

if I had to put a name on our type of team, I'd probably have to describe us as a blended group of "Ronin", meaning we are a relatively fluid lot with a host of experiences and we are ultimately "masterless". If something needs a champion, it's not uncommon for any of us to just step up and do what's needed. The funny part is Mark just put up the "non-team testing team" and basically just defined what I just wrote. Ha!!!

OK, so teams can be fluid, that's cool.  So how do we execute? Meaning, what is the strategy? To be clear, a strategy means we deliver a long-term return on investment, align resources to deliver,  arrange type and timing of tactics and make sure that we can be consistent with our efforts. Ultimately, we need a clear objective as well as a strategy to accomplish the objective. Sounds simple but actually being concrete with objectives and developing a clear method of accomplishing them is often anything but. In my opinion, to be able to execute to a strategy, we have to know what we can accomplish and what we need to improve on or develop a skill for. Therefore a skills analysis is critical as a first step. From there, we need to see how those skills come into play with our everyday activities and apply them to make sure that we can execute our strategy with what we have and develop what we need to so that we can execute in the future.


(still editing, refresh to see the latest :) )

More than That - a 1 1/2 armed #LiveBlog from #STPCON Spring 2018

I had to step out and take a meeting so I missed probably half of Damian Synadinos' talk. Therefore, if this feels incomplete and rambling, well, that's because it literally is ;).

I am intimately familiar with being asked "what I do" as well as "who I am". The fact is, I am a lot of people. No, I don't mean in a schizophrenic sense (though that's debatable at times). I mean it in the Walt Whitman sense:

"Do I contradict myself? Very well, then I contradict myself, I am large, I contain multitudes."

The point is that we are never just one thing. All of our quirks, imperfections, and contradictions come from our many experiences, histories and active pursuits.

Depending on who you talk to about me, you might get a wildly interesting view of exactly who I am. It might get really interesting depending on what period of my life you ask about, but if I had to guess, these identities might show up:

actor
bass player
bodybuilder
boy scout leader
carpenter
cosplayer
dancer
drummer
father
fish geek
gardener
guitar player
husband
mandolinist
mormon
obsessive music fan
otaku
photographer
pirate
podcast producer
poet
programmer
prose writer
singer
snowboarder
tester
video gamer
yogi

If I had to choose a specific attribute, I'm going to lay claim to "eclectic".

Each of these has informed my life in a variety of ways, and each of them has given me skills, interests and a number of very interesting people to do this variety of things with. In many ways, it's the people that I interacted with that informed how long or how little time any of these endeavors/attributes have been a part of my life, but all of them are and all of them have provided me skills to do the things I do.

Also, if any of the items on that list have you wondering what they are or how I'm either actively involved in or why I chose to mention them, please be my guest :).

Taking an AXe To It: Starting Accessibility Tooling (#CNC2018 #BLOGMORE)

I am rather far behind with my commitment to the #BlogMore challenge in the #CNC2018 campaign. Part of that is, of course, “life is what happens when you are busy making other plans” but more specifically I came to a conclusion that my original outlines were way too ambitious.

My topics as outlined were more suited for chapters for a possible book rather than single blog posts. Thus, I have decided to take something from each of the outlines and get very specific. Rather than do a vague post about Accessibility and Inclusive Design, I will focus on a specific tool that will allow me to address coding and design more directly.

There are numerous tools available that will allow programmers and testers to evaluate websites and applications for Accessibility and Inclusive Design. This post will be about just one of them. aXe is a tool developed by deque. It is open-source, free and runs inside of the browser along with a variety of Developer Tools. Currently, two versions are available (for Chrome and Firefox).

Adding an aXe to Your Arsenal

Installation is straightforward. Start by navigating to the download page for the extension (here’s the flow for Firefox):

1. Click on the Add to Firefox button.

2. Give aXe permission to be added as an extension.

3. After installation completes, this confirmation screen will appear.

4. Depending on how many add-ons you have, you will see something similar to the following on your Firefox browser toolbar.

5. Click on the aXe icon to get a help message. aXe is part of Developer Tools and appears within that context.

My preferred way to open Developer tools is to just click anywhere in the browser main window, right click, and then select “Inspect Element”.

If your installation went correctly, you should see the following. Click on the aXe navigation bar header to see the screen below. If you see this, you are good to go.

Press the “Analyze” button on your chosen web page. I might as well pick on myself. Let’s have a look at http://mkltesthead.com/.

See that output at the bottom? That’s an indication that I have some stuff to deal with.

I hear you saying, “well, OK, that’s… interesting… what exactly am I looking at here?”


A First Pass at your aXe Analysis
aXe gives the user a condensed listing of issues found. Let’s take a look at the listing in more detail:

The top section displays the number of Accessibility violations (in this case, 95 of them). The listing below the violations count is an area that says “Needs review”. These are potential violations, but they may not be. Let’s take a look at one of them:

We can see the issue. The validator cannot actually determine if the color contrast of the title is compliant. The reason is that there is an image beneath it, and that image has varying shades, where in some areas there is definitely a bold contrast, but in a few areas, the “whites of the Tachikoma’s eyes” are right next to the text. Below the issue description is the actual code that is being evaluated.

In this case, I have two choices. I can either tell the system that this is not an issue and move on, or I can consider how to match both the letter and spirit of the issue and fix it. Options are I could remove the image, or I could darken the image significantly so that all areas are in sharp contrast.

Additionally, I can do some sleuthing through the tool by clicking on the “Learn more” link next to the description. I can also click the “Inspector” link and see the element in context with the surrounding code for the page:

Clicking on “Highlight” will focus on the element in question but leave us with the review screen:

Having given the code a once-over, I can now (if I choose) make a decision for a course of action. In this case, I am going to make the executive decision to leave the image as it is and say that it is “not an issue” because, for 97% of the text, there is ample contrast.

By selecting “This is not an issue” and clicking the “Save” button, I update the aXe database and move on to the next issue that needs review.

If you followed along, that should give you some feel for how you can quickly use aXe to validate a number of Accessibility issues on your chosen page. There's plenty more where that came from, to say the least, and I will be getting into more details in future posts, both with aXe and a few other favorite Accessibility tools.

The Code Newbie Challenge for 2018 #CNC2018: BLOG MORE: Mission Two: Blog Outlines and Schedules

Week three and mission two are completed. My thanks to Christian Haas for feedback and some additional commentary in this post :).


This week's homework for Blog More is to complete an outline for each of the three blog post ideas.


Homework:
1. Post your favorite outline below.
2. Find someone’s posted outline in the group and give them some feedback. What stands out to you? What points were most interesting? What did you want to learn more about? Be kind but specific in your feedback.

Mission 2:  Outlines and Schedules

My Top Three

1. Writing Code around Accessibility and Inclusive Design

• Intro: a quick explanation as to what Accessibility and Inclusive Design are.
• Sample Code that is not accessible and why (web example)
• Using Inclusive Design Patterns to help set the stage
• Changes to code that will make it more accessible
• Methods to check and validate such things
• Sample Code that now IS accessible and why (web example)

My initial thoughts: 

I’m realizing this is a topic I could write examples for every week for a year and probably still have plenty to write about. I will probably have to tailor this down to an introductory article first and then go into specifics about individual inclusive design patterns, etc.

Christian's comments:
I'm curious about this topic as a whole. For me, your first entry could be about setting the stage, with one or two examples showcasing how far the topic could reach. I myself am more interested from a theoretical point of view. It would affect my daily work only if there were info/references to "closed" systems; I'm not working on web UI, but for a dedicated, trained, target audience using Java UI.

My follow-on thoughts based on feedback:
This is an interesting angle and one I hadn't considered. How do we make applications accessible in a more specific programmatic focus? By Java UI I am assuming these are applications that have a command line style interface or otherwise interactions at the Operating System level and not online or via the web. To be honest, I haven't given a lot of thought to how this would work for a command line application, but it's an interesting thought experiment. When I'm writing a script or some interactive piece of code, how Accessible or Inclusive am I making those interactions? Definitely worth considering.

2. Skeleton Keys: a resource for TDD/BDD in the shell and other programming languages

• What is skeleton-keys?
• Why would anyone need it?
• TDD/BDD in the shell? Really?
• Unit Testing Tools in three languages (bash, ruby, and python)
• Starting small: structure, tests, and output
• Compare and Contrast the three languages and approaches

My initial thoughts:
Why did I pick three languages? OY!!! Oh yeah, so I could actually make some comparisons. I think these might end up being rather long (like book chapter long), but on the plus side, once I get this started, I will probably have plenty to write about for a very long time.

Christina's comments:
Bash: yes - Ruby/Python: is there a particular reason to have both? I don't have experience in either language and see (from the outside) they are somewhat similar in terms of capabilities. Mainly procedural with object-oriented additions; weak type system, and interpreted. For a broader coverage, it should have a variation in perhaps at least two of these points. (e.g., using C, C++, Java, C#, Go, or ...). Since you already identify that this can be done in various languages (taking time and effort to write this), I suggest that, if you want three initial examples, they should be quite distinct from each other. Or reduce to two. (Or give particular reason why Ruby & Python)

My follow-on thoughts:
This is a very good point. I picked Ruby and Python mostly because they are languages I'd been either working with or had some recent exposure to and wanted to set up as a way to focus on some starting poitns for those languages. Having said that, they are two languages that fill a similar niche. They're not the exact same, but Christian makes a good point that they are similar enough that they may not prove to be all that interesting a comparison. Perhaps using a language such as Java or C++ would make more sense, though I haven't used either in a meaningful way in a long time. Still, for this purpose, it may make for a more interesting comparison, so worth re-examining.


3. Creating a framework from the ground up (Jenkins, Docker, Protractor, Angular, Jasmine)

• You Keep using that ‘Framework’ word. I don’t think it means what you think it means.
• Jigging your Jig-Saw Pieces (short intro/tutorial on all five pieces, including installation)
• Setting up a basic application to test
• Puting the onion back together
• writing the Angular App
• testing with Protractor/Jasmine
• putting it into Docker
• managing it with Jenkins
• Lather, rinse, repeat

My initial thoughts: 

This would make for a great series with a minimum of five posts for each piece (plus the many that I haven’t even mentioned yet, such as plug-ins or add ons to make the job easier to manage).

Christian's comments:
With your first point about using "framework" wrong, I suspect this title is intentional. Still, is the overall goal to write a Javascript based template project?
If so, I'd be less interested as I don't work in JavaScript (That should not be a reason to change your goal, I understand that), though, if it were pitched as "how to create a template stack with Jenkins, Docker, ..." might be half interested as I'd consider an automation pipeline for different languages. Perhaps this could even be a two-parter: How to set up a build-pipeline with Jenkins & Docker and then specializing it for a JavaScript project, and then specializing it for a Java project for instance... (These are all just ideas, I believe your thoughts go already in that direction...)

My follow-on thoughts:
Yes, the use of the word "framework" in both the title and the shout-out to The Princess Bride reference is in part to say that the word framework gets thrown around a lot and maybe doesn't really mean what a lot of people think it means. My goal is to address the broad areas and try to see how to implement the pieces. Just setting up the scenario would be a series of posts (setting up Jenkins, working with git, creating docker containers, setting up a project, making tests for the project, running those tests, making sure they integrate with the CI pipeline, etc.). Perhaps skeleton-keys could be the project that allows me to put this all together and integrate into a series of posts.


One thing is certain, this challenge series is showing me that there are plenty of things to write about in these spaces and I will probably have ample to write about for a long time.

Code Newbie Challenge 2018: #CNC2018 #BlogMore: Mission One: Blog Ideas

The first official mission for the Code Newbie Challenge has completed. Here are my follow-up and thoughts about this week's assignment.

Mission 1:  Three Ideas

Goal
Develop and validate the three blog ideas for this challenge.

Homework 
Come up with 10 blog ideas, then narrow those down to 3.

This challenge had a lot of great supporting material to help people get into the mindset of what it would take to create a technical code blog post. 

Research: 

• Search Twitter for hashtags related to areas of interest.
• Search blogs that talk about areas of interest. Medium, Dev.to, FreeCodeCamp, Hackernoon, Codeburst, basecs, Mozilla Hacks, etc.
• Look at Newsletters like JavaScript Weekly and RubyWeekly
• Think about things I am actively working on and wish there were posts that answered my concerns.

Brainstorm:

Aim for ten ideas. Here's the list I came up with:

1. Examining Accessibility and Inclusive Design (this is my personal touchstone topic, as if I really want to make a transition to writing code, I want to do it in a way that can help me advocate for Accessibility and Inclusive Design better) - Explainer for concepts, tutorial or project for specifics
2. Walking through Developer Tools that emphasize Accessibility - Explainer
3. Making a Skeleton Resource for Coding (my biggest problem is getting started, so my overall goal is to make something that will help me do that. I figured I could explain along the way as I make it). Project, possibly tutorial
4. Writing shell scripts using TDD and BDD principles (using shunit2) - Tutorial, Project
5. Quick Fixes for Big Headaches (the shell can be your friend) - Project
6. Deploying your own little CI Pipeline (Deploying Jenkins on your local machine) - Tutorial, Project
7. Containers for the curious (Deploying Docker on your local machine) - Tutorial, Project
8. Blending Angular, Protractor and Jasmine into a testing framework - Tutorial, Explainer, Project
9. Road Rash: Cautionary Coding tales while the wounds are still healing (I did something, I got stuck, it hurt but I figured a way out of it) - Explainer
10. How Would You Automate This (an actual Series I’m Currently Working On) - Explainer

Narrow it down to 5:

Many of the ideas I came up with are not so many ones I would want to eliminate as they are either peripheral to or prerequisite of what I'd want to write about. By taking my original list and grouping them, I came up with the following more condensed list:

1. Examining Accessibility and Inclusive Design, Walking through Developer Tools that emphasize Accessibility  - Explainer for concepts, tutorial or project for specifics
2. Making a Skeleton Resource for Coding, Writing shell scripts using TDD and BDD principles, Example shell fixes to demonstrate the project - Project
3. Deploying your own little CI Pipeline (Deploying Jenkins on your local machine), Containers for the curious (Deploying Docker on your local machine), Blending Angular, Protractor, and Jasmine into a testing framework - Tutorial, Explainer, Project
4. Road Rash: Cautionary Coding tales while the wounds are still healing (I did something, I got stuck, it hurt but I figured a way out of it) - Explainer
5. How Would You Automate This (an actual Series I’m Currently Working On) - Explainer

One of the reasons I ordered this list this way is that I couldn't figure out how to put Road Rash into another location other than as a sidebar, and it felt the weakest of my choices. How Would You Automate This I deliberately put at the bottom as I'm already writing the series. I want to emphasize posts and areas that I'm not already doing or that would actually be new territory for me.

Validate your ideas

I received some great feedback and interest from several people who reviewed my list and who expressed interest in seeing certain topics get covered. That had a lot to do with my grouping and decisions on which topics I would want to focus on.

Pick your top three

The top three and the working titles for each:

1. Making Your Pages and Apps Accessible Using Inclusive Design Principles
2. Skeleton Keys - A Project for Getting Started in bash, Python, and Ruby
3. A Testing Framework From the Ground Up - Jenkins, Docker, Angular, Protractor, Jasmine

Turn In Your Homework 

 

Turned in to the CNC2018 Facebook group, but also this blog post :).

 

Bonus Reading 

 

Here are some additional blog posts to check out:

7 Ways to Mine Twitter Data for Blog Post Ideas

Mediocre Ideas, Showing Up, and Persistence

Book Review: How To Become A Web Developer: The Career Changer’s Guide

One of the most difficult to pin down topics and titles of the last couple of decades is to define oneself as a web developer. What exactly does that mean, and what skills does one need to know to become one in this day and age?

Julie Torres, one half of the "Code Crush" podcast, has done what I feel is a good job distilling that into an 86 page book titled, specifically enough, “How to Become a Web Developer: The Career Changer’s Guide”.

Starting with the Prologue, Julie describes the specific circumstances that started her on this journey. With a softening job market during what we now refer to as “The Great Recession,” Julie describes how she moved from being a bank teller to become a junior developer. Her point in sharing this story is to make clear that you don’t need an advanced degree in computer science or have lots of history as a programmer to make the shift into doing web development. This book pledges to help you make that transition. Does Julie deliver on that promise?

Chapter Zero: Prepare for the Journey 

Julie sets out some basic markers to help you make the most of this journey including the idea of starting your job hunt while you start your web development journey. Counterintuitive, but makes good sense. Looking at what is out there, what is required and what skills are consistently being asked for is a great way to tailor your learning path. Utilizing Meetup groups and other resources will also help. Determine how to measure your progress, whether that be a way to check in with an online community or work with a specific mentor or group of people. In this day and age, showing goes a long way and having resources you can demonstrate to show your skill can be a big boost in this process. Code repositories and websites in the cloud to show your work can help tremendously. Don’t be concerned with whether or not you “measure up” to others out there. At the start, you won’t but your journey is yours and that’s what matters.

Chapter One: First, Choose Your Goal

Front End, Back End, Full Stack, Mobile, and a reference to QA by way of automation. This particular part touches me because I am primarily a tester in my work role, but many web development skills are still part of my daily repertoire. I’m glad Julie include testing on the list because many developers do actually make a decision to look at testing as a primary responsibility. The point is, deciding where you want to place your efforts will make a big difference in what you study and in what order. Likewise, there’s no rule that says you have to be permanently committed to any one goal, right?

Chapter Two: Choosing Your First Programming Language

Languages have a lot to do with the applications or environments you want to work on. Java is now a perennial favorite of many organizations because it is ubiquitous. Large corporations use it, Android devices use it, and there’s a large ecosystem for the language. It’s a wordy language, true, but the benefit is that there’s a lot of examples out there to look at and review. JavaScript is a language that has spawned numerous libraries and smaller ecosystems of their own. When you see people asking about Angular, Bootstrap, jQuery, React, etc, those are all specialized JavaScript frameworks. PHP is a great language specific for a large number of existing sites. Python and Ruby are also popular languages that also run in web stacks (Django and Rails, respectively). What you use will depend a lot on what you ultimately want to work on. If your dream job is making iPhone apps, you may want to take a look at Swift. The key is start with where you want to go and then pick what you will work with.

Chapter Three: Paths to Learning

You may be thinking “I don’t have a Computer Science degree” and that’s totally fine. Many of the best developers I’ve know have degrees in completely different disciplines. Whether you choose to go to college, do a coding Bootcamp or use an online resource like freeCodeCamp, the point is you have to put in the time, get frustrated a little and work through the issues you will undoubtedly face.


Chapter Four: What Skills Do You Need?

The foundational skills necessary are surprisingly small. Yes, it helps a lot if you can touch type and do so at a decent speed. Knowing how to use a computer or mobile device well is important especially if you can understand how to open, edit, move and manipulate files and directories. Understanding fundamental math skills and having a good understanding of the scientific method is also very helpful (not mentioned in the chapter and were I to suggest any additional basic skills to include I’d strongly suggest that one ;) ). From there, you will need to learn about how to use the command line of your chosen operating system(s), understanding the basics of HTML and CSS, using a version control system to chart your progress and, on occasion, back up and go to an earlier time to do something different, and understanding of how the Internet works (TCP/IP and HTTP, for example). From there, databases, return codes, error handling, and flow control of programs will come into play. Sounds scary? In truth, it’s fairly straightforward but the devil is in the details. Again, the key here is to understand what you want to do and then plot the course to get there. It will require a fair amount of knowledge buildup and experimentation, as well as false starts and frustrations. Julie goes into some detail in this chapter about the various frameworks available, sample programs and applications you can develop and ways to display them so that people can notice your progress.

Chapter Five: Things to Ignore (at Least For Now)

Depending on what it is you wish to work on, there may be many skills that will be important later on, but that you do not need to worry yourself with at the start or even in the first few years of your progress. You may never have to get familiar with topics like binary, specifics of computer hardware, or the underlying computer networking infrastructure and communicating with the lower layers. There is a list where there are things that will be helpful to understand later on and while I agree with much of the list, I have to take issue with testing being considered not so important. Personal opinion time, I wish more developers would put testing and a testing mindset at the forefront of their learning. It will help encourage more developers to see what they are developing, to begin their work with questions of quality and experimentation in mind and to ultimately help deliver a better product to their users.

Chapter Six: Learning Resources

This chapter includes a list of resources to help fill in key concepts and skills you may need. Many of them are completely free, while some have a small cost associated with them (small is relative, of course). Julie also includes a variety of blogs and websites that can also be helpful (I too am a fan of the Tuts sites and encourage people to check it out).

Chapter Seven: Staying On Track

The chapter starts out with this quote:

"Learning to code is more of a motivational challenge than a technical one." -- Quincy Larson, Founder of freeCodeCamp

On the whole, I agree with that. How we keep ourselves motivated is important, and finding our true motive is also critical. Do we want to make more money? A good place to start but may not sustain us in the long run. Chose methods that will help you stay committed to your goals, such as participating in meetups, hackathons, or other projects you can do with other people to get feedback and feel connected to what you are doing.

Chapter Eight: Career Goals

Just as important as what you want to do is where do you want to do it? Do you want to work for large companies or would you be interested in working for smaller organizations? Understanding the tradeoffs for each is important. Large companies can have great infrastructure but very defined ways of doing things. Smaller companies may be more chaotic and struggle with getting to profitability but the sky's the limit with where you can potentially get involved. You can also work with various employment agencies on a contract basis to rotate jobs and gain experience. Once you have a good enough foundation, you could perhaps hang up your own shingle, so to speak, and freelance. Don't be surprised if you find yourself doing a little of all of that, especially in the first few years.

Chapter Nine: The Job Hunt

Remember that advice in Chapter Zero? Here's where doing all of that this whole time should start helping. If you have been communicating with a variety of people along your journey, they may take an interest in what you have put together and speak with those in their organizations that have a hand in hiring. Resumes still matter at a lot of places, but they are taking a backseat to demonstrable ways that you can show your skills. In this day and age, tools like LinkedIn, GitHub, SlideShare, and a blogging platform can do a lot to boost your visibility as well as have lots of examples of demonstrable skills. Additionally, connect with people and communicate with them. The key here is to start this process well before you need to look for a job so that when you are ready, you have already identified people who you can communicate with. Another bonus is that, if you do this regularly, they will likewise know you are ready and can help you find your next gig.

Chapter Ten: Interviewing

Whether it be initial phone screens, in-person general interviews or technical interviews, you will be judged based on how you respond. Having a good handle on a variety of skills and being able to explain them will go a long way in helping you with these interviews. You may be given a coding challenge to complete, either on-premises or as a take-home assignment. Practice a few of these so that you can feel confident that you can do them if given the opportunity or request. This chapter has a lot of practical advice for specific technical interview questions as well as how to negotiate for salary.

Chapter Eleven: Building a Successful Career

Once you get that first job, realize that it's the bottom rung of a new ladder. There's still much to learn and many areas that you can get involved if you choose to. Pay attention to sticking points in the organization and see if you would like to tackle those challenges. See where the rest of the market is going and if you feel that you are ready to pivot if market forces change. Most importantly, never stop learning.


Along with all of these chapters, Julie shares many personal anecdotes of her own journey that has brought her to where she is today. These vignettes help the reader see what choices she made, both for good or ill, that have helped inform the rest of the text.

BOTTOM LINE:

For those who are looking for an in-depth guide to learning how to become a web developer, this book doesn't cover those except for skimming the resources needed to accomplish those goals. This is much more of a field guide to allow you to safely manage the trek and it is filled with a variety of markers that you may find interesting along your journey. As the title says, this is a Career Change guide, and those focusing on the "How To Become a Web Developer" are missing the key in the subtitle. This is a guide to navigating a career change. To that end, it meets its goal admirably.

It's That Time Again: The #StateofTesting Survey 2018

As in previous years, I have decided to take part in "The State of Testing" Survey and I encourage anyone else who is actively involved in testing endeavors to do the same. Note: I did not say "testers" need to take it, though that's likely who it's directed to. As I have become more involved in software delivery as a process, software testing is a key part of what I do, but it's not the only thing I do.


As I see it, software testing is transitioning. There will certainly be areas where dedicated testing as a role, a responsibility, and a job title will remain for quite some time to come. However, I also see that testing as a dedicated discipline in many organizations, if not disappearing, is definitely getting to be hazier. In previous decades, I might have been worried about that and truth be told, I was. Today, I take heart in the fact that there is much we all can do to be successful and do meaningful work. as I often remind myself, my mentor Ken Pier was fond of saying "there is always work moving from theory to practice".

The following I am borrowing directly from the Practitest QA Intelligence Blog, so I am presenting it in its entirety below (Thanks, Joel and Lalit :) ):

What is the State of Testing?

The State of Testing™ seeks to identify the existing characteristics, practices, and challenges facing the testing community in hopes to shed light and provoke a fruitful discussion towards improvement.

The final report is translated into several languages and shared globally, further expanding the reach and impact this report has on all of us in the QA world.

This is the 5th year that the QA Intelligence Blog is running this survey in collaboration with TeaTime with Testers, and with your help,  it can be bigger and more comprehensive than in previous years.

Each year the amount of participants has increased, and the final reports become even more valuable as a culminated reflection of testing trends, challenges, and characteristics.

See the results from the previous State of Testing surveys

So there you have it, another chance to take part in the State of Testing Survey is upon us. Are you interested in playing along? If so, click below and let's get to it :).

ANSWER SURVEY NOW

---

The Testing Show: CodeNewbie With Saron Yitbarek, Part 1

Happy New Year everyone!

I'd like to present the newly retooled The Testing Show. New theme music (courtesy of my band Ensign Red) and what I hope will be a new streamlined format for the show. I've learned a thing or two about doing audio the past few years and I'm hoping to see us transition a little bit to a broader storytelling approach along with the regular interviews that we do.

To that end, that special guest I was talking about a few weeks back is Saron Yitbarek, the mastermind behind the CodeNewbie website, podcast, Twitter chats and recently the producer of the BaseCS podcast as well as running the Codeland development conference.

I joke during the intro in this show that I feel like a bit of a fanboy here, but seriously, I have wanted to interview Saron for a long time. I was a little nervous asking if she'd be on our show with her level of visibility, so I was overjoyed when she said "yes" and even more so at the natural conversation that we had. She's not just a great interviewee, she's an excellent interviewer as well, so there was a really fun give and take on this show. To that end, I likewise decided that my traditional heavy grammatical editing style wasn't suited for this conversation. Some of the audio may sound a little less slick by TESTHEAD standards, but I feel it adds to the immediacy and excitement of the conversation. I'm not kidding when I say I was a bit giddy at a few spots in this episode.

All right, fanboy gushing aside, this episode covers what I think is interesting ground. Saron is perhaps one of the few guests who has never identified as a software tester, but she totally gets testing. What's more, she totally gets the frustration of getting up the courage to commit to learning how to write code (and yes, it takes courage to do it). It takes courage to be continuously frustrated. She also shares a lot of her ups and downs and frustrations that she has had during her own journey, and how she uses that as fuel to help support others on their coding journeys.

We recorded for almost two hours, and it has been a struggle to decide what to keep the focus on for these interviews. I'm hoping I've captured the best of the conversation, but I'll leave that to you all to decide.

If you enjoy listening to The Testing Show, I'd like to ask you a favor. Please go to Apple Podcasts and give us a rating. If you feel we deserve five stars, please give it to us :). If you feel we deserve less, that's fine too, but please leave a review and tell us why you feel that way. Give us a review as to why you think we deserve five stars while you are at it :). We aim to make The Testing Show the best podcast we can and if you have thoughts about how we can make it better, as the producer, I'm definitely interested.



The Testing Show: CodeNewbie With Saron Yitbarek, Part 1: The Testing shows talks about the process of learning how to code, so we talk with Saron Yitbarek about where and how to start. Tune in to learn more!

The Testing Show: Hiring and Getting Hired

It's been a big year for The Testing Show and this is the last episode of the year that is 2017. We were happy to have Gwen Dobson join Jessica Ingrassellino, Matt Heusser and me to talk about the changes that have taken place in the testing market over the past few years.

We riffed on a number of topics including the laws that prohibit asking about salary histories, having that discussion about money and making the best case for your worth, marketing your skill set and leveraging the variety of platforms at our disposal to help sell ourselves and our personal brands.

It's been a great deal of fun to produce and participate in this podcast and I'm looking forward to the new topics and guests we will have in 2018. I am actively working on a two-parter for January with a special guest that you are just going to have to wait and see/hear who it is, but I can say I've wanted to interview this person for a long time and I'm excited about presenting these episodes, along with some other changes for the show in 2018.

With that, please jump in and have a listen to
The Testing Show: Episode 50: Hiring and Getting Hired:

Good Ideas are Spawned From Bad Or Failed Ideas

My elder daughter and I have been working on a number of small projects together over the past few months and every once in awhile, I will get a comment from her where she says "wow, how did you know what to do in that situation? We hadn't faced it before, and you quickly figured out a way to deal with it. How is it so easy for you? Why can't I do that?"

I chuckled a little and then I've told her a maxim that I've used a bunch (and I'm sure I've said it here at some point, too)... "Good ideas/solutions come from good judgment. Good judgment comes from experience. Experience comes from bad ideas/solutions/judgment." In short, she sees that I can come in and consider an idea and implement it (in some things, I do have my limits, and they are legion). What she doesn't hasn't seen is the countless times I've tried similar things, failed at them, regrouped, reconsidered, remeasured, tried again, and repeated this process until I happened upon something that worked.

As a Scout leader, I've had the benefit of decades of teaching a few generations of kids how to do some basic stuff (note, I said basic, not easy or simple). We teach how to tie a handful of knots. We teach some basic cooking techniques. We teach how to handle items like an ax, a knife, and a saw. We teach how to safely use fire. We teach some basic wilderness survival tips. Each time through this process there is always a similar "wave" that I witness. At first, there's an excitement level, but that quickly gives way to a mild boredom. Seriously? This is such a big deal? Snooze! Still, I push on and demonstrate what I can and encourage them to practice what I am showing them. A hallmark of our Scouting year typically takes place three months in for a typical scout. That's the "silent campout". Not silent in the sense that there's no talking or interaction, but silent in that the leaders (i.e. me and the other adults) make it a point to not discuss any of the campout particulars with the troop. They have their campsite, we have ours. they are within eyesight of each other, and we reserve the right/authority to intervene if a situation is deemed unsafe. Outside of that, we let them pick the camp area, bring in all needed items, and then we leave them to it. They construct the camp, they cook their meals, they clean, they tend fires, and do all of the other things that we have taught them over a few months.

Each time, the outcome has been similar. The bored expressions often give way to genuine concern or in some cases panic. Wait, what was I supposed to do at this point? Did I pack what we needed? Did I cook that long enough? Am I going to be able to properly contain the fire? You get the idea. They make mistakes, they get frustrated, and then they approach the problem(s) from different angles. They confer. They discuss options. They experiment. Some of those experiments fail, but some succeed. They note the ones that were successful. The next morning, fewer mistakes, less frustration, and almost no panic. The process, while ragged, gets smoother and more refined. Almost to a person, this experience makes for a change of attitude, and then when we talk about "the basics", they are not so jaded and bored. they realize that basic stuff often is harder to physically do in a regular and smooth manner. Like everything, it takes actual practice and it takes some working through frustration. Do it enough, and you start to actually get good at those basics and then you forget that there was a learning curve at all.

My point with this today is that, too often, I think we approach aspects of what we do (testing, coding, administration, learning new stuff, getting out of our comfort zone) with the same mindset. We start out enthusiastic, we get bored and jaded and then we panic when what was supposed to be so simple doesn't work out to be. It's OK to feel these things. In fact, it's necessary. Over time, as we stumble, learn, practice and perfect, we too might forget exactly what it takes to do basic things and make them look easy. May I encourage you not to? You never know who may be watching and feeling discouraged because they can't seem to "get it". We've been there, we know how that feels. Let's make sure we remind others that basic doesn't necessarily mean easy, and that good ideas/solutions often come from bad ideas/attempts.

Seek JOY: #PNSQC Live Blog

Wow, we're at the end of the day already? How did that happen? Part of it was the fact that I started a few conversations with people that cut into talks being delivered, but as is often the case, those discussions can take priority and can often be the most important conversations you have at a conference.

Long story short though is that we are at the closing Keynote for the main two-day conference. Rich Sheridan of Menlo Innovations believes that we can do work that we care about and that we can have joy in the work that we do and in the workplaces we actively move in. Rich shared his story of how he came up into the world of computers and computing starting in the early seventies and how the profession he loved was starting to sap the life out of him and how he was contemplating leaving the industry entirely. He was experiencing the chaos of the industry. Issues, bugs, failed projects, blown deadlines, lack of sales, and all of the fun stuff any of us who have worked in tech recognize all too well. Chaos often ends up leading to bureaucracy, where we can't get anything done to not being able to get anything started.

The fact Rich wants to impart is that Joy is what all of us hope for in most of the things that we do. We often see it as some form but it's often nebulous to us. Additionally, jobs and companies cannot guarantee our success or our happiness. We have to have an active role in it and be willing to make it happen for us as we endeavor to make it work for others.

Why joy? Joy is service to others and being able to see the reaction to that service. IT's why we do the work that we do. We want to see our work out in the world. We want to see it get a response. We want to see people react to it. and we want to have that moment that swells up inside of us and that cheers us and makes us jump for (wait for it!) joy.

It's one thing to say that you want to build a joyful career, but it requires human energy. In most of the work environments that I have enjoyed the most, the work has almost always been secondary. What made the work enjoyable? The people and the interactions with those people are what makes for memorable experiences.

One of the most important things to foster joy is the idea of trust. We have to trust one another. Trust allows us to be open and frank. We can get into hard discussions and deal with conflict in a positive manner. When we can debate issues with trust and consideration, while still being committed to trying to get our issues resolved, we can deal with the hard issue and still be positive and remain friends.

Rich describes his office as a hodgepodge of machines, but the most astounding aspect is the fact that no one has their own computer. People change pairs and move onto other machines every five days, and with those moves, people move onto other machines. That means there is no such thing as "it works on my machine" because there is no dedicated machine for anybody.

Simplicity goes a long way to helping develop joy. Complexity for its own sake sucks the life out of us, and Rich showed the way that they manage their work. It's all on paper. It's all based on the size of commitment, and it's all based on creating meaningful conversations. Pans are then put on the wall, for all to see so that it's completely transparent. Honesty matters and with transparency comes honesty. With honesty and a willingness to express it, empathy comes into play. With empathy, we can see what others see and feel what others feel. To borrow from Deming, as Rich did "All anyone wants is to be able to work with pride" With that pride comes joy.

Rich Sheridan is the author of "Joy, Inc." and it is scheduled to be released very soon. Yep, I want a copy :).

And with that, the two-day technical program for PNSQC is over. Tomorrow will be another work day for me, but I think it's safe to say that I'll be literally buzzing with the kinetic energy that these past two days have provided for me. Thank you PNSQC team for putting on a great event. Thank you, speakers, for sharing your insights and experiences. Thank you, participants, for coming out and participating, and especially, thank you to everyone who came to my talk and offered positive feedback (and constructive criticism, too). Wishing everyone to get back to their destinations safely, and if you are here for the extended workshop day, I hope you all enjoy it and get to bring back great insights to your teams.

TESTHEAD out!!!

Lean Startup Lessons: #PNSQC Live Blog

Wow, a full and active day! We have made it to our last formal track talk for today, and what's cool is that I think this is the first time I've been in a talk with Lee Copeland that hasn't been physically running a conference.

Lee discussed the ideas behind Lean Startup, which was a book written back in 2011 by Eric Ries. In Lean Startups, classical management strategies often don't work.

The principles of Lean Startup are:

Customer Development: In short, cultivating a market for their products so that they can continue to see sales and revenue, and to help develop that relationship

Build-Measure-Learn Loop: Start with ideas about a product, build something, put in front of customers to measure their interest, then learn about what they Like or Don't Like and improve on the ratio of Like to Don't Like. Part of this is also the concept of "pivoting", as in "should we do something else"?

Minimum Viable Product: Zappos didn't start with a giant warehouse, they reached out to people and sought out what they might want to order, and then physically went to get the shoes that people ordered and sent them to them.

Validated Learning: "It isn't what we don't know that gives us trouble, it's what we know that ain't so" - Will Rogers
"If I had asked people what they wanted, they would have said faster horses." - Henry Ford (allegedly)

One Metric That Matters: This measure may change over time, but it's critical to know whatever this metric is because if we don't know it, we're not going to succeed.

So what Quality lessons can we learn here?

Our Customer Development is based on who consumes our services. Managers, Developers, Users, Stakeholders. Who is NOT A customer? The testing process. We do this wrong a lot of the time. We focus on the process, but the process is not the customer and it doesn't serve the customer(s). With this in mind, we need to as "what do they need?  what do they want? what d they value, what contributes to their success? what are they willing to pay for?"

The Build-Measure-Learn Loop basically matches up with Exploratory Testing.

Minimum Viable Product: We tend to try to build testing from the bottom up, but maybe that's the wrong approach. Maybe we can write minimum viable tests, too. Cover what we have to as much as we have to, and add to it as we go.

Validated learning equals hypotheses and experiments to confirm/refute hypotheses. In short, let's get scientific!

How about the One Metric That Matters? What it definitely does not include are vanity metrics. What does the number of planned test cases mean? How about test cases written? Test cases executed? Test cases passed? Can we actually say what any of those things mean? Really? How about a metric that measures the success of your core business? How do they relate to the quality of the software? Is there an actual Case and effect relationship? Does the metrics listed lead to or inform next actions? Notice I haven't actually identified a metric that meets those criteria, and that's because it changes. There are a lot of good metrics but they are only good in their proper context, and that means that we have to consistently look at what we are and what that metric that matters and what really matters when.

Gettin' Covey With It: #PNSQC Live Blog

This talk is called "7 Habits of Highly Effective Agile" which is a play on words of the Steven Covey book, hence my silly title. Yes, I'm getting a tad bit punchy right now, but I am lucky in that I get to have an energy boost. Nope, no food or drink or anything like that. I get to have Zeger Van Hese next to me doing his sketch notes.

I've waited years to actually see him do this. How am I going to concentrate on doing a live blog with that level of competition (LOL!)?

Seriously though, "Seven Habits" is a book from the 80s that is based on the idea of moving from dependence to interdependence with a midpoint of independence.  For those wondering about the original Covey Seven Habits, they are:

1. Be Proactive
2. Begin With the End in Mind
3. Put First Things First
4. Seek to Understand, Then be Understood
5. Think Win/Win
6. Synergize
7. Sharpen the Saw

The Agile Seven Habits break down to:

1. Focus on Efficiency and Effectiveness (make sure that your processes actually help you achieve these, such as cutting down, technical debt, providing necessary documentation, etc.)
2. Treat the User As Royalty (understand your customer's needs, and what you are providing for them)
3. Maintain an Improvement Frame of Mind (adapt, develop, experiment, learn, be open, repeat)
4. Be Agile, Then Do Agile (we have to have internalized and actively live the purpose before we can do the things to get the results. Communicate, collaborate, learn, initiate, respond)
5. Promote a Shared Understanding (develop a real team culture, break away from roles, stop thinking it's not my job, learn from each other, wear different hats and take on different tasks, pairing as a natural extension, determine what is important)
6. Think Long Term (develop a sustainable process, pacing that's doable and manageable, making habits that stick and persisting with them)

Well, there's my thoughts. and here's Zeger's. His are much cooler looking ;):

What is the Law? 30 Days of Accessibility Testing

The Ministry of Testing has declared that May should be "30 Days of Accessibility Testing". As in the days of yore when I used to take on these challenges and blog regularly, I'm in the mood to get back to doing that. Therefore, I am looking to write a post every day around this topic and as a way to address each line of their checklist.

24. Learn about accessibility law in your country.

I live in the U.S.A., and therefore, while WCAG 2.0 is the guidelines I aim for, we usually refer to "Section 508" or features being "508 Compliant" because that is a section of the Rehabilitation Act of 1973. Actually, there are two areas in the Rehabilitation Act that relate to disabilities. The first is Section 504, which declares that the act "prohibits federal agencies, programs, or activities from discriminating and requires reasonable accommodation for qualified individuals with disabilities." Section 508 declares that "agencies must give disabled employees and members of the public access to information that is comparable to access available to others." A basic checklist of Section 508 compliance can be seen by clicking on the link.

Notice anything interesting there? Did you see anything mandating that Accessibility is the law everywhere? Nope. Just in the services and the fund allocated for them by the federal government. Is there a strict standard? Again, nope, but Section 508 by virtue of being a policy of the federal government, and with the sheer volume of software seats that the federal government provides, can carry a lot of weight in regard to the design decisions of companies.

I know for a fact that a large agency of the federal government looking to purchase a lot of software from my company was what initiated a thorough review of Accessibility requirements and areas that needed to be updated in our product so that they would buy it. The dollar amount of that deal most certainly played a part in why we undertook a large-scale retrofit of our product to meet Accessibility standards, and again, the standard we measured for that purpose were the guidelines as described to meet U.S. requirements. To meet the broader WCAG 2.0 requirements means we still have a distance to travel still.


For a nice breakdown of what USA Laws do and don't cover, see http://webaim.org/articles/laws/usa/

When You Can't Get a Grip: 30 Days of Accessibility Testing

The Ministry of Testing has declared that May should be "30 Days of Accessibility Testing". As in the days of yore when I used to take on these challenges and blog regularly, I'm in the mood to get back to doing that. Therefore, I am looking to write a post every day around this topic and as a way to address each line of their checklist.

Yay! I'm all caught up :).

16. Find a problem that might affect someone who can’t use their hands.

This is a broad range of issues that falls under the umbrella term "motor disabilities" and can have many possible causes. We can be talking about the limited use of limbs due to paralysis, deformities, prosthetics, and in cases where there is no limb to use. Due to these limitations, there are several instances that can be looked at as barriers to interacting with technology, as well as a number of devices that can help with overcoming those limitations. 

I remember as a child seeing a news program that celebrated a local resident who had lost the use of her arms due to an accident. She was a talented artist, and rather than give up her skills, she trained herself to use her mouth and her head movements to replace the motor control that her arms and hands used to provide. Yes, for those curious, she resumed painting by holding a paintbrush in her mouth. In many ways, that analog is used today by many with motor disabilities, where the head and neck, eyes, chin, and mouth are utilized to make up for the loss of hands as primary input devices.

WebAim has a page that is dedicated to assistive technology alternatives for those with motor disabilities. These range from simple sticks that can be held in the mouth to adaptive keyboards and large trackball mouse devices to speech recognition software. As someone who does a lot of typing throughout the day, I would find it particularly challenging to try to interact with a computer system sans the ability to type. Voice recognition software can come to the rescue, but that's also provided that you have a clear enough speaking voice to be able to control the software to respond correctly and effectively.

Have we noticed a trend in these past few posts? In all of them, I could make some specific recommendations, but there's one that stands out as near universal. Systems that are simply designed, with a minimum of clutter, are going to work better for anyone with a significant disability. What's more, a simpler and cleaner design will not just help those with disabilities but will be more helpful to everyone. Also, the last big takeaway from the motor disabilities page is that most devices mimic or interact with a keyboard so we would do well to make our products as keyboard friendly as we can, and in the process, require as few keystrokes as possible to accomplish the tasks we need to.