PNSQC 2020 Live Blog: Teaching Testing To Programmers. What Sticks, And What Slides Off? with Rob Sabourin and Mónica Wodzislawski

I had a feeling that as soon as I saw who one of the presenters was for this talk that "OK, this is going to be fun!"

I've worked with Rob over the years when I was part of the Board of Directors of the Association for Software Testing and I remember talking with him about this very topic. There's no question that testers can learn how to program and work as developers. It also stands to reason that developers can learn the skills to become testers. 

Mónica Wodzislawski is new to me but I have learned recently about a vibrant community of software testing centered in Montevideo, Uruguay, and I can only assume Monica is actively engaged in that community.

Corporate initiatives to “shifting left” and the focus on Agile software development, Test-Driven Development, and other areas pay lip service to softeware testing but do not approach testing in the manner that a skilled tester would. That does not at all mean that good developers cannot be good testers. They most certainly can and many are. The idea of actually applying software testing as a discipline within the Computer Science curriculum is a good one. Over the years, I've heard only a few places where testing is even mentioned beyond writing unit tests. The idea of a semester-long course dedicated to software testing (akin to the BBST course of classes) is still a foreign concept in developer's learning journies. 

Some of the challenges that get in the way of testing are the notion that somehow software testing can't be seen as universal (and to be fair, it cannot, there is no one size fits all approach). It seems that there is a hangup on the tool stack. If you don't understand all of the tools then you can't do effective testing. There are going to be unique tool needs and there will be unique challenges related to specific tasks but even with that, there are many testing methodologies that can be leveraged regardless of the software stack being used. 

Often the approach to templating and patterns is heavily emphasized with some developers. Others tend to look at the code and automation as the end result. Automation is a good tool to have and it's important to understand and have them but there is a lot of software testing that doesn't involve automated testing.

Rob and Monical both emphasize looking at risk to help determine areas that might need testing at a preliminary or expanded level. Create models that stand up to the work that you need to do. By developing a model, we encourage developers and testers to focus their attention on the areas that are going to be the most vital to the business. There's plenty more to do but that's a good place to emphasize. 

By setting quality goals and examining case studies, software developers can learn a number of great skills including building conceptual models, examining and applying patterns and anti-patterns, and examining common faults and solutions that can be applied.

New Title, Same Gig?

Well, today threw me for a bit of a loop.

Why, might you ask?

Today I received a new title. For the first time in my software testing career, it can be argued how much of my role as a tester is left. For the past almost thirty years my job titles have been some variation of the following (I'm going to say since 1994 as from 1991-1994, I was a Network Lab Administrator and an Engineering Tech):

Software Tester
Development Test Engineer
Quality Assurance Engineer
Applications Engineer (Basically a Customer Test Engineer)
Senior Quality Assurance Engineer

So what's different today? As part of my review I was asked if I would accept a new job title:

Senior Automation Engineer

I said "yes" but I will confess, a part of me is curious as to what that acceptance means going forward? Actually, I don't have to guess too much, I know, as I've been part of this conversation for a number of years leading up to this.

What this means is that I agree to be spending the lions share of my day inside of an IDE.
What this means is I agree to create code that will be reviewed and put into daily use.
What this means is I agree to step into a development role and all that that entails.
Additional to all of this, I also agreed to transition onto another team, outside of the one I have worked with for the past seven years.

Yep, I have a mixture of emotions today.

Am I ready for this? I'd like to say I think so.
Do I want to do this? As a matter of fact, yes.
Do I know enough to do this? That remains to be seen, probably not completely.
Am I comfortable with this change? Ah, now we get to the heart of the matter.

See, in large part, I'm not comfortable with this change. I'm having to put down a large part of my identity that I have fostered over the past decade. The titles and pronouns I've become so used to are at once still relevant and now totally irrelevant. A part of me is anxious, a little scared, a little concerned I may be biting off more than I can chew, especially with that Senior part. That means I'm supposed to mentor juniors. As a developer. I will confess that part feels really weird.

And yes, even though I am not necessarily comfortable, I'm excited to do this. The expectation has changed. The primary focus of my efforts has, too. In part, I was singled out as, "that person that always champions trying new avenues, looking at things in unorthodox ways, and not settling for how things have always been done." Really? They paid attention to that? I guess so. They also paid attention to my frequent frustrations that real-life testing needs often trumped my ability to make much headway in the automation space because other needs were prioritized first. They listened. They decided to let other people handle those aspects so I could better focus on coding effectively.

Have I mentioned I'm not even going to be doing this in a language and toolset I'm used to? Yeah, let me touch on that for a second. I've been a Mac focused tester and programmer for 10 years now. I've used Ruby, Java, Perl, and Python to an extent in those years. Today I'm sitting behind a relatively new Windows 10 laptop running .NET Core, Visual Studio and wrapping my head around C# patterns. Surprisingly, I'm not running for the hills. It's different but it's not fundamentally so. Sure, there's some tooling and practices I have to come to grips with, as the last time I spent any real-time with a .NET application of any kind was 2010. It's all so very weird, like I'm having to speak Dorian Greek... but at least I feel like I'm coming from Ionian Greek rather than from, say, Japanese (weird comparisons but hey, welcome to my brain today ;) ).

Long story short, I just signed up to have my world rocked and I am strangely OK with it.

Creating Quality with Mob Programming - a #PNSQC2019 Live Blog

Thomas Desmond has helped me get my head around an example of something I've been interested in but haven't actually been able to actively participate in... what does Mob Programming actually look like?

I understand it as a concept but truth be told, programming in my organization beyond a pair arrangement is... challenging. The biggest challenge is the fact that we are all distributed. We've tried programming as a group via Hangouts or using tmux but again, it's a challenge to get that done with more than to people. Thomas is showing how is organization sets up these massive systems with multiple big screens, with multiple keyboards on rolling desks that can go anywhere in the office. The key idea here is that all of the people (optimized to four) are in the same place, at the same time, talking together simultaneously, and all interacting on the same computer.

Thomas is describing a situation where they mob program on all production code. As in, they don't have their own desks. They work as a group on a single task; designing, coding, testing, and releasing all together. The thought of being able to do this all day, every day, on all projects both seems cool and a little weird. In the neat way, not the unnerving way.

A tool that they use is called "Mobster" (neat, need to look this up) that has limites on who can be the driver (IOW, hands on the keyboard) and who can be the navigator (guiding direction but not necessarily behind the wheel) at any given time. The goal is that the roles switch and everyone gets their turn. For an idea to be implemented one of the navigators must be able to explain the idea clearly so that the driver can implement the idea. Ideally, everything is explained, everyone else in the group can hear the idea(s), and they can comment on the idea before it actually gets implemented.

I have struggled with where I would be effective as a tester in a Mob Programming environment and now that I have seen it explained as implemented by Hunter Industries. They actually throw new people right into the mix. Counter-intuitively, they come up to speed faster this way than they would if they were to be trying to get up to speed in a traditional development environment.

Thomas emphasizes that the benefits of mob programming are:

- live code reviews
- sharing knowledge
- greater idea sharing
- fewer meetings
- more engagement
- increased code experimentation

I must confess that this is a lot more tangible an idea now and it makes me excited to see if/how we might be able to implement it. Any thoughts on how to mob while fully distributed, let me know, please :).

You Have One Job: a #30DaysOfTesting Testability #T9y Entry

It's the weekend, and I am nine posts away from finishing this challenge. Let this be a lesson to everyone out there, don't let time get away from you. Just because you can write ten blog posts in a day doesn't mean you should. Live blogging is an exception.

My rules, I made them up ;).

Anyway, more "30 Days of Testability". Let's do this.

Unit tests provide insight into an applications testability. Pair with a developer to explore some unit tests.

We have had a longstanding rule that done isn't really done until unit tests are in place. We have a variety of work styles. Some do their unit tests first as a "Test Driven Development" approach and others do them afterward. For those who do the former, they've said that it doesn't save them time up front but it helps them stay focused and they reap benefits down the road. for those who don't do the TDD approach, they typically say that it's mostly because of how they think. They prefer to tinker with ideas and see where they will lead first and that TDD messes with that. Who is right? Probably both of them. Regardless, no stories cross the line without unit tests so they get done one way or another :).

As for myself, I've been experimenting with two unit test runners for the purpose of a new automation framework approach. as we are looking at Cucumber JVM, I've been working with both JUnit and TestNG. Both are interesting in what they do and how they glue things together. I find myself thinking in the JUnit frame of mind mainly because I've used it several times over my career, while TestNG is a newer approach. We also have a variety of unit test frameworks in pay for our front end code (Jasmine and Protractor being two examples). I definitely value looking through them as they give me a clearer idea as to what each method and module is capable of handling. I especially like looking into the error handling, though I wonder if my teammates feel the same way ;).

In any event, if you want to give yourself a boost in understanding your application, unit test reading and discussing is a pretty good approach. 

Write it on Your Hand: a #30DaysOfTesting Testability #T9y entry

The Steve Martin reference yesterday was not a song so that broke my streak. Back to song lyrics/titles and a chance to mix Marvelous 3 with my blog. Can't pass that up. Anyway, more "30 Days of Testability" to savor. Please try to contain your excitement ;).

Share a blog post that you found interesting related to testability. Don’t forget to use the hashtag #30DaysofTesting if you share on Twitter.

Technically I've already done this as I shared Alan Richardson's blog post about Testability versus Automatability in my previous post "A Touch of Evil". I could say "hey, already done!" but what's the fun in that? Thus I'm going to go in a different direction today. It's a bit old now but I still think it has some good points to it.

Guide: Writing Testable Code

Granted this post is associated with coding practices and ways to make the code better suited for unit testing but there's still a lot of good things to consider here from a non-coders perspective:

- are we putting flow control in constructors? If so, why?
- are we passing objects that get defined but never used?
- are we consistent with the objects we are passing?
- can we follow the flow easily for what a method is doing?
- does a single method do too much?

this article covers many more situations but the real takeaway is that these coding warning signs are also things that we as testers can consider when we have testability conversations.

Inclusive Meta Paradox Frameworks: A Little Shameless Self Promotion

I realize I'm terrible at promoting myself and the things that I'm doing. Having said that, I do want to encourage everyone to see what I'm up to and with that, I'm sharing a podcast I recorded with Mark Tomlinson for STPRadio.

Listen to "STPCON Spring 2019 Michael Larsen on Inclusive Meta Paradox Frameworks" on Spreaker.

You know the old saying "When the going gets weird, the weird turn pro?" Well, if you don't you do now :). Seriously, I love this title. Thank you, Mark, this is great.

Also, for those of you who are intimately familiar with my editing style on "The Testing Show", you may think that I am always smooth and flawless in my delivery, without any wasted breaths. Yep, it's true, no one on The Testing Show breathes... kidding, but now that I've planted that little seed in your head, I'll be the next time you listen to an episode you'll be subconsciously dwelling on that ;). My point is, Mark keeps it real and whatever was said as it was said is there in real time, so if you are curious as to how I really sound when I'm interviewed, here's your chance.

In this podcast, I talk about my workshop around "building a framework from scratch" (and yes after I finish this presentation I am going to start unpacking it and posting it here) as well as my talk on Accessibility and Inclusive Design and how they can be used to help Future Proof software.

If you will be at STPCon and you will be in my presentations, here's a taste of what to expect. If not, well, you get that anyway just by listening. Have fun and if you like the podcast, tell a friend about it, please.

What's That Smell? Angie Jones Talks at #BAST (LiveBlog)

Tonight is proving to be an exciting evening for the Bay Area Software Testers Meetup.

Angie Jones has come out to talk to us about "Code Smells", where we have code that "works", but may have some unusual issues that don't necessarily jump out at us.

More than just talk about the issue, Angie is actually walking us through and showing a real project that has some definite issues. The first example she uses is classes that are too long, where there is a lot of stuff put into a single class and it doesn't have a specific purpose. Oftentimes classes grow over time because there's no other logical place to put something. Think of writing a test where you put a lot of browser interaction into a class so that it's readily available. One one hand, it makes sense, but on the other hand, if it is overloaded or the items added to a class can be grouped somewhere else, take the time to put it there.

Another common smell is "Duplicate Code", where if you have an issue where something is repeated in multiple places, you end up having to do what Angie calls "Shotgun Surgery" (I just love that term :) ). Anything being duplicated more than twice is probably a really good indication that a separate class with that information probably makes a lot of sense.

Next up is the 'Flaky Locator Strategy". Oh, do I know this one! Angie is exhorting, loudly, to not trust the Copy XPath option that comes with Dev Tools, and I wholeheartedly agree. This is also something I wrote about in my "Less Brittle Automation" posts, part one and part two. Happy to see that something I found frustrating is also something Angie pointed out :).

Angie calls out the "Indecent Exposure" smell. If you are showing too much of your data, you may allow for people to get to your data and information in ways you may not want to. This is fixed by narrowing the scope of your classes, making certain methods private when they should be and only keeping public methods that actually need to be public that distinction.

Something that I'm all too familiar with is the issue of explicit waits. Yes, I do this. No, I'm not proud of this. Yes, I can do better. Angie encourages us to Wait Intelligently, by either polling for an element or to make sure that the test doesn't move forward until there's a confirmation that an item is present.

Frameworks are supposed to drive the logic of the browser and to create a state condition. Frameworks don't actually test anything, so putting assertion codes into the framework is a problem. Instead, we want to create state conditions that e can evaluate elsewhere. Otherwise, we may find ourselves painted in a corner unintentionally.

This was a really great discussion, and it was made the more effective by seeing the actual code being modified. I'm super happy to have had Angie come out to speak with us at BAST tonight and she has an open invitation to come out and talk any time she wants to :). For everyone else, thanks for indulging me this evening as I got to geek out a bit. 'Til next time!

Farewell, My Dumbledore

On August 7, 2018, the Cosmos reclaimed one of the greatest and most benevolent minds I’ve ever had the pleasure to work with. Granted, the man in question was someone I never met in person but through his books, blog posts and our occasional correspondence over the past eight years, that didn’t matter. I considered him a legitimate friend, mentor and, yes, a wise old wizard who helped me see things differently.

Jerry Weinberg will be remembered for many things. His absolutely prolific writing career. His career as a computer scientist is legendary. He almost single-handedly created the software testing profession (that’s a bit hazier, of course, but it’s hard to argue with how profoundly his effect on the craft and profession of software testing has been). “Perfect Software and Other Illusions About Testing" is my most gifted book to others on the subject. I've read it multiple times and will be rereading it again, along with several other works of his I've had the pleasure to own and read.

My Interactions with Jerry have been varied but I appreciated the fact that, were I ever to write a book review, no matter how old the book, he would always write back with a note of appreciation. If I had a question in the review, he would patiently explain it and help me see the intended meaning or bigger picture.

His “Fieldstone” method towards writing was the single biggest revelation for me and how I could organize ideas and thoughts when it came to writing. Too often I would start something and I’d either consider it not worth continuing or I’d question my direction. He taught me that was fine and perfectly normal. Just like a stonemason doesn’t use every rock they pick up immediately to create a wall, they often store those rocks in a spot so that, when the time comes to use that stone, they can shape it with minimal effort and put it in its proper place. An idea was not necessarily good or bad (well, some were just plain bad) but many ideas just weren’t ready to be put into the wall of my work just yet. Worry not, the time to use it will come.

What I will always remember about Jerry was his immense kindness, to just about everyone. I’ve thus far never met anyone that actually interacted with Jerry and had a negative thing to say about him. His various workshops over the years have been attended by several of my peers and to a person, every one of them said that Jerry took the time to understand them, learn their issues and frustrations, and somehow work beyond them. A phrase of his that I love is “whatever the problem is, we will deal with it.” I’ve taken that phrase and, in my own black humor have repurposed it as “we will jump off that bridge when we get to it” but the sentiment is really the same. Jerry always inspired me to try to solve problems, no matter how difficult.

We have lost a loving wizard, a true Albus Dumbledore in the flesh. That phrase was first mentioned by my friend and colleague Martin Hynie and I realized at that moment that that really was who Jerry was to me. Jerry was my Dumbledore. Always approachable, at times intimidating at a distance but never up close. He always endeavored to make you feel like you could overcome anything and that ignorance was a definitely curable condition. He has left us with a body of work that is frightening in its quantity but as has proven to me time and time again, reading it is so very worth it.

Farewell, my dear wizard. Thank you for making me just a little bit better as a tester, a technologist, an inquirer, a writer, and hopefully as a human being.

Release is a Risky Business - a 1 1/2 armed #LiveBlog from #STPCON Spring 2018

Good morning. Let me get this out of the way now. I'm going to be splitting my mental energy between attending STP-CON and the fact that a new candidate release dropped last night and I need to see how close to shippable this one will be. Splitting my brain is an everyday occurrence, but that may mean I might miss a session or two, but I'm not missing this first one ;).

Simon Stewart is probably well known by those who read my blog regularly. Web Driver guy and a bunch more.  We're talking about the changes and the way that "release" has morphed into faster releases, along with a greater push to automation. Some stuff that fell by the wayside in that change is honestly a lot of stuff that I don't miss. There's a lot of busywork that I am glad has been taken over by a CI/CD pipeline.

Outside of software testing, my professional life has become very closely knit into release. Jenkins is my baby. It's an adopted child, maybe a foster child, but it's still my baby. As such, I tend to spend a lot of time fretting over my "problem child", but when it works it is quite nice. Remind me when I am over the PTSD of the past month just how sideways CI/CD can go, but needless to say, when a tester takes over release management, they go from almost invisible to ever present.

Release is risky, I can appreciate that greatly, especially when we get closer to a proper release. Though I work in an environment where by necessity we release roughly quarterly, in our development and staging environment, we aim to be much "Agiler" and closer to an actual continuous environment (And yes, I checked "Agiler" is a real word ;) ).

Simon points out, and quite rightly, that release is really less about quality and more about risk mitigation. For that matter, testing is less about quality than it is risk mitigation. For that matter, staging environments do not really give you any level of security. Simon makes the point that staging environments are a convenient fiction but they are a fiction. My experiences confirm this. About the only thing a staging environment tells you is if your feature changes play well with others. Beyond that, most staging environments bear little to no resemblance to a proper production environment. If you think Simon is encouraging releasing and testing in production, you would be correct. Before you have your heart attack, it's not the idea of a massive release and a big push of a lot of stuff into production and all bets are off. If you are going to be doing frequent releases and testing in production, you have to think small, get super granular and minimize the odds of a push being catastrophic. Observability and monitoring help make that possible.

There's a lot that can go wrong with a release and there's a lot that can go right with it, too. By accepting the risk and doing all you can to mitigate those risks, you can make it a little less scary.

The Use and Abuse of Selenium - a 1 1/2 armed #LiveBlog from #STPCON Spring 2018

I realized that the last time I heard Simon speak was at Seleimum conf in San Francisco in 2011. I've followed him on Twitter since then, so I feel I'm pretty well versed with what he's been up to, but the title intrigued me so much, I knew I had to be here.

Selenium has come a long way since I first set my hands on it back in 2007.  During that time, I've become somewhat familiar with a few implementations and bringing it up in a variety of envirnments. I've reviewed several books on the tools and I've often wondered why I do what I do and if what I do with it makes any sense whatsoever.

Simon is explaining how a lot of environments are set up:

test <-> selenium server <-> grid <-> driver executable <-> browser 

The model itself is reasonable but scaling it can be fraught with disappointment. More times than not, though, how we do it is often the reason it's fraught with disappointment.  A few interesting tangents spawned here, but basically, I heard "Zalenium is a neat fork that works well with Docker" and I now know what I will be researching tonight after the Expo Reception when I get back to my evening accommodations.

Don't put your entire testing strategy in Selenium! Hmmm... I don't think we're quite that guilty, but I'll dare say we are close. Test the happy path. Test your application's actual implementation of its core workflows.

Avoid "Nero" testing: what's Nero testing? It's running EVERYTHING, ALL THE TIME. ALL THE TESTS ON ALL THE BROWSERS IN ALL THE CONFIGURATIONS! Simon says "stop it!" Yeah, I had to say that. Sorry, not sorry ;).,

Beware of grotty data setup: First of all, I haven't heard that word since George Harrison in "A Hard Day's Night" so I love this comment already, but basically it comes down to being verbose about your variables, having data that is relevant to your test, and keeping things generally clean. Need an admin user? Great, put it in your data store. DO NOT automate the UI to create an Admin user!

Part of me is laughing because it's funny but part of me is laughing because I recognize so many things Simon is talking about and how easy it is to fall into these traps. I'm a little ashamed, to be honest, but I'm also comforted in realizing I'm not alone ;).

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.

The Code Newbie Challenge for 2018 #CNC2018: BLOG MORE: Introduction

Hello to new readers that are coming across this blog for the first time. To those who have read these pages for a while now, this should not surprise any of you at all ;).

I've decided to take on the Code Newbie Challenge for 2018. There are four "tracks" that you can choose. They are:

Start Coding
Code More
Blog More
Get a Job

I have chosen the "Blog More" challenge for a specific reason. Much of the time on this blog I have talked about testing and peripheral topics from a layman's point of view. I've strived to "speak dude" as often as possible, and to that end, I've kept coding specific stuff to a minimum. that sounds like a simple answer, doesn't it? Well, let's get real here. There's a darker secret. Part of the reason why I don't post code frequently is that I harbor a fear that people will look at my code and think it's simplistic, stupid or just plain lame. To tell the truth, that may happen. Maybe it won't. Regardless, I've always been a little leery of posting code samples beyond language tutorials because I've just been concerned about getting it picked apart.

That's the overwhelming reason why I chose this challenge. I can't get better if I don't actually put something out there, right? I can talk a mean game about what I know about things like automation and web development, but does it really matter if my actual code is lacking? More to the point, wouldn't it make a lot of sense to actually talk about code, show examples, explain it from my perspective and let people who do know about code comment on it?

Sure, it might bruise my fragile ego but isn't that the whole point? How do I expect to learn or actually demonstrate I know anything if I'm not willing to show what I actually know and take the chance that someone might be willing to tell me a better way to do it? On top of that, there may be lots of things I may be doing that are actually interesting and may be helpful to others. Finally, if I can explain what I'm doing in a blog post or several, I can explain it to anyone and draw on it when I write code in the future.

Let's get this party started. Each assignment as part of this challenge will be posted here. This is my own preamble to get the ball rolling. Look for the tags CNC2018 and CodeNewbieChallenge to see posts specifically targeted for this challenge.

Exercise Zero: The Pre Mission

Read 3 tech blog posts you wish you wrote. Jot down why you like them and what you'd change.

Find examples of good tech writing to see what you'd like to incorporate into your own posts, and what you might want to avoid. 

You'll refer back to these later in your challenge.

There are three styles that were described for this challenge. First is the "Tutorial", which actually walks through how to do something. Second is the "Explainer", which take a concept and breaks it down. Third is the "Project" which describes how to do something and gives actual examples that you can follow along and build yourself. The pre-challenge is to pick three examples, (one from each category) that I wish I had written, describe what I like about it, and what I would like to see to improve the piece.

Tutorial: "Protractor for Beginners, Part 1" by Hannah Pretswell

Why a tutorial on Protractor? Because it's what we are exploring as a replacement for our current automation framework. Nothing like a pressing business need to get your mind racing and your thoughts flowing. Hey, you know it will come in handy very soon, right? For starters, let me comment on something I really appreciate. Hannah said she struggled with getting the pieces to work together. Hearing that up front helps me in two ways. First, it lets me know that the tasks ahead may be challenging. Second, she also lets me know that she's done her best to document those frustrations and help let me know that I likely will succeed if I'm patient and follow her advice. Too often, I've gon through tutorials that expect a user to jump in and get moving with little concern over the sticking points. Gladly, that's not the case here.

Another positive is the fact that there are a fair number of repetitive steps. It's tempting to spell them all out, but by doing so, it makes updating a tutorial daunting and thus something the writer would likely not do. Instead, she points to a few additional tutorials already written that explain the process of setting up your environment and making sure everything is working correctly before getting started. Additionally, the resources listed point to the protractor GitHub page. This is a good practice because it lets the user get started with the most recent advice from the maintainer of the framework so that if the instructions change, the writer of the tutorial doesn't have to be the one to change the details on her site as well.

So, what would I have done differently? Truthfully, not much. I think it's a solid opener and it goes through the specifics as the first part of a tutorial should. I suppose I would have liked to have seen some example output of the code as displayed and some output of tests as well. For me, with a variety of tutorials, I think this is a good step so as to show what you could expect. I understand why many people don't in that OS changes and formatting details could put images like that out of date quickly, and it does add overhead to downloading what would in many cases be pictures to demonstrate the output. Still, on the whole, this is a really solid example.





Explainer: Test Driven Development in BASH by Torstein Krause Johansen

This is presented as a talk, but in many ways, that's a great way to explain a concept in a few words, with the impetus on the reader to go and learn more if they are so inclined. Specifically, I like the curt and focused content, the way the information is presented and the walkthrough of the ideas with examples. Each slide builds on the previous one and lets you see why the topic makes sense and the reasoning behind Torstein's approach. I was also excited to learn about shunit2 and I must say I'm more than a little curious at this point.

So what would I do differently? Again this is a set of slides from a talk, and at first glance, I'm guessing the HTML code was put there for a reason, but if the point was to demonstrate bash syntax and how it interacts with a testing framework, the HTML was distracting and made the underlying code hard to read. Again, I may be missing a key context here as to why that was presented that way (perhaps to prevent copying and pasting willy-nilly) but if that were the concern, I could see saving screenshots of the code itself and displaying pictures (great to prevent copy and paste but admittedly a nightmare to update and keep current).

Project: 10 Angular and TypeScript Projects to Take You From Zero to Hero by Dan Wahlin

This interested me seeing as I will be doing work with Protractor and Jasime as a testing framework for Angular apps. To that end, it helps to have something to look at, play with and practice on and these ten projects will allow me to do that. I like that the projects start simple and get progressively more difficult as they go. Each project is laid out with sample images of what you will build with links to each of the projects so that the project page is independent of each of the individual listed projects. The projects are lust listed with a title, a basic description, level of difficulty, a link to the files and some pictures of what the project will look like when completed.

On the whole, this is a nice layout and method. It leaves it up to the individual reader to decide where to expend their energy and each project simply links to the necessary packages to get them done. Were I to do it myself, I would probably split each project out to its own page and try to give some instructions about what to do with each. Having said that, the economy of having ten projects to choose from without a lot of navigation and page dancing is a good tradeoff.

There's the start. The assignments proper start on January 22, which is the same day this post goes live. Feel free to follow along and, as I tackle each assignment, your feedback and commentary is appreciated :).

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!

Machine Learning Part 2 With Peter Varhol: The Testing Show

As has become abundantly clear to me over the last several weeks, I could be a lot more prolific with my blog posts if I were just a little bit better and more consistent with self-promotion. Truth be told, a lot of time goes into editing The Testing Show. I volunteered a long time ago to do the heavy lifting for the show editing because of my background in audio editing and audio production from a couple decades back. Hey, why let those chops go to waste ;)? Well, it means I don’t publish as often since, by the time I’ve finished editing a podcast, I have precious little time or energy to blog. That is unless I blog about the podcast itself… hey, why not?


So this most recent episode of The Testing Show is “Machine Learning, Part 2” and features Peter Varhol. Peter has had an extensive career and has also done a prodigious amount of writing. In addition, he has a strong mathematical background which makes him an ideal person to talk about the proliferation of AI and Machine Learning. Peter has a broad and generous take on the current challenges and opportunities that both AI and Machine Learning provide. He gives an upbeat but realistic view of what the technologies can and cannot do, as well as ways in which the tester can both leverage and thrive in this environment.

Anyway, I’d love for you to listen to the show, so please either go to the Qualitest Group podcast page or subscribe via Apple Podcasts. While you’re at it, we’d love it if you could leave us a review, as reviews help bubble our group higher in the search listings and help people find the show. Regardless, I’d love to know what you think and comments via this page are also fine.

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 ;):

Customer Quality Dashboard: #PNSQC Live Blog

OK, the late night flight arrival into Portland and the early morning registration is catching up to me. I will confess that I'm hunting down Diet Coke and alertness aids of the non-coffee or tea types. If I seem a little hazy or less coherent, well, now you will know why ;).

In any event, it's time for John Ruberto's "How to Create a Customer Quality Dashboard" and he started with a story about losing weight, and a low-fat diet that he was on for awhile. The goal was to get less than 20% of his calories from fat. He soon realized that having a couple of beers and eating pretzels helped make sure that the fat calories consumed were less than 20%. Effective? Well, yes. Accurate. In a way, yes. Helpful? Not really, since the total calories consumed went well above those needed for weight loss, but the fat calories were under 20% all the time ;).

This story helps illustrate that we can measure stuff all day long, but if we aren't measuring the right things in context, we can be 100% successful in reaching our goals and still fail in our overall objective.

To create a usable and effective dashboard, we need to be able to set goals that are actually in alignment with the wider organization, focusing on what's most important to stakeholders, providing a line of sight from metrics to goals, and build a more comprehensive view of our goals.

Let's put this into the perspective of what might be reported to us from our customers. What metrics might we want to look at? What does the metric tell us about our product? What does the metric not tell us about our product?

Some things we might want to consider:

Process metrics vs Outcomes: Think vines of code per review hour vs. defects found per review.
Leading Indicators vs. Lagging Indicators: Think code coverage vs. delivered quality.
Median vs. Average: Median page load vs. average page load. Average can skew numbers
Direct Measures vs Derived Measures: Total crashes vs reported crash codes

There are a lot of potential issues that can cause us problems over time. One is gaming the system, where we set up metrics that we can easily achieve or otherwise configure in a way that is not necessarily supported in reality. See the example of the fat percentages. We could adjust our total intake so our fat calories were below 20%,

Confirmation Bias: is a preconceived notion of what things should be, and therefore we see or support results that help us see that reality. 

Survivor Bias: The act of seeing the surviving instances of an aspect or issue as though it's the whole of the group.         

Vanity Metrics: Measuring things that are easily manipulated.


                                                                                                                   

Keep Your Project off the Autopsy Slab: #PNSQC Live Blog

All right, my talk is over, and from what I can tell from the comments back it seems to have gone over well :). Lunch was good and we got to get into the 35th Anniversary cake. The committee also put out cupcakes and I'm pretty sure this had to have been put out there as a joke:

I am happy to hear that no Vegans were harmed in the making of these cupcakes ;).

The first talk for the afternoon is to talk about Pre-Mortems, with the subtitle of "Keep Your Project off the Autopsy Slab". To make it simple, there'are three basic things to consider in a pre-mortem:

1. Something has failed.
2. You and a group have determined and found the issue.
3. Steps are put in place so that the issue doesn't happen again.

Put simply, projects frequently fail, and they fail for predictable reasons. Sometimes they are event-based, such as a person quits, or the schedule changes, or an integration is needed. Sometimes it's people related, such as a skill set is missing, or someone is not dedicated to the project. At times the culture works negatively, such as fostering overt competitiveness or being overly skeptical. Additionally, the goal to get it out there overrides the willingness and ability to do the job right. Technology can be a problem, as in external third party software elements seem great on paper but we end up struggling to try to use it.

One additional issue that can sabotage a project is a lack of knowledge, specifically with the idea of "unknown unknowns" as in "we don't know it and we don't even know we don't know it".

If we are looking at a pre-mortem as a way to get a feel for where things are likely to go, we first have to identify as many risks as possible, but just as important is determining if, and how, it will be possible to mitigate those risks. Mitigation is an oddball term, in that it's not entirely clear as to what we are doing. Are we minimizing risk? Reducing risk? In general, it's lessening the impact of risk as much as possible.

There are eleven ideas to consider with pre-mortems:

1. What is the scope?
2. How do we determine the logistics?
3. What instructions do you send?
4. How can you imagine the project failing?
5. What are the reasons for potential failure (brainstorm)?
6. Now, let's create a master list (consolidate, de-duplicate and clarify).
7. What items can we remove from the list due to low impact (filtering)?
8. What reasons of potential failure could be real risks to the real project?
9. What does the group consider important? Reorder based on importance (VOTE).
10. Action Items to mitigate the top risks.
11. Action items need to actually be done. They are the whole point of the pre--mortem.