Use Design Thinking and Gut Brain for Agile Teaming: an #InflectraCON2023 Live Blog

 

Jenn Bonine

Founder and CEO, Valhalla Capital and COYABLU

I confess I'm stealing these graphical assets from the InflectraCON site but they make things nice and easy to associate a face with a name and a talk with a byline. Jenn and I have spoken at a variety of conferences together over the past decade and it's always fun to catch one of her sessions. Also, I'm proud to announce that the pink lion she gave me at last year's InflectraCON sits proudly on my guitar amp at home (LOL!).

One of the ways we tend to create or develop things is that we make them based on what "we" want. "We" means the people who are making it making it for themselves. However, Design Thinking goes beyond that, in the sense of designing something that will affect and influence many people, perhaps millions or even billions at the outer edge.  

Design thinking incorporates elements of imagining the future. What will this thing look like a year, five years, or ten years from now? Can we speak to what that future might look like? More important, can we actually shape that future? This is the FORESIGHT aspect necessary for Design Thinking. Often, we have to get out of the ways that make sense to us and see if we can make sense in a way that works for many people. 

Apple is a good example of a company that started as one thing and then over time grew into and developed markets that not only were not their specialties earlier but didn't really exist prior. Just think about the way that we interact with our phones today (and for that matter what phones look like today). There is a dividing line between pre-iPhone and post-iPhone coming on the scene. Cell phones used to have wildly different design aspects prior to 2007. Now, almost every phone we see is the ubiquitous "black mirror", regardless of who makes it. 

ChatGPT is the new design thinking brainchild that is capturing everyone's attention. We now have the job description of "Prompt Engineer" which, unless you are an AI nerd, was something you may have never even heard of or considered but now will likely become a prevalent focus. This has come about because ChatGPT has considered the breadth of who their potential customers might be. You may think to yourself that there is a limited level of use for this technology but given some time and experience, you realize there is a lot that can be done provided you know what to ask and how to ask it. That's prompt engineering in a nutshell.

So how does Design Thinking fit into all of this? In art, it means that we need to look beyond our immediate needs and our immediate bubble. Too often, we only focus on the areas that are either our specific pain points or our immediate sphere of influence. While that's a great approach for inner peace, it's probably going to cause us to fall behind if we don't look further afield. Heck, as a person that does automation, we can often get used to the patterns that we have determined that work. Once we do, we can do a lot of work and be seen as effective. That may work for a time but if we don't continually look farther afield, we will effectively be working feverishly on yesterday's problems. Taking a bigger picture look to see what can either make things easier or, barring that, may pay off years down the road can be a big step. 

Design thinking principles (originally from Nielsen-Norman Group)

The ideas behind design thinking fall into three broad areas and six efforts that support those areas. First, we have to understand (discover) a problem, explore our options (create) , and then materialize those results (deliver). Often, we start with one idea but in the process, if we are open to and see the interactions with other people, we may develop something different than what we originally envisioned. Each of the big areas can be broken down more, such as Empathize and Define for Discover, Ideate and Prototype for Create, and then Test and Implement for Deliver.

The next step is to look at what is called the "Gut Brain" (And while we're not talking about specifically the microbiota that resides in our digestive tracts, it absolutely plays into this ;) ). This sense of "Gut Brain" is delving into our intuitiveness and looking at things that hit us viscerally and deciding to use those intuitions and interactions to look farther afield of our immediate considerations. In short, this is a way of tapping into our playful nature and making considerations we might not tap into. Sketch notes are examples of this, where a person instead of just writing words includes pictures and other doodles to help inform and nurture further thought and understanding. In some ways, it requires visualizing a different world than the one others see. I'm reminded of the woman that finally beat Ken Jennings in Jeopardy years back. How did she do it where others failed? In part, she didn't go in thinking Ken was unbeatable. She visualized herself being able to beat him and used that gut instinct to get the better of him. I'm spacing on who it is but I always loved her statement that so many people thought, "It's such an honor to even compete against him" but she said, "He's beatable, I just have to figure out how". She led with that gut instinct and figured out how to prevail.

Lots of neat stuff to consider here as well as a lot of digital tools. In short, explore, discover, consider, play, and see if you might actually reinvent your world.

Into the Depths of Risk Analysis to Improve Your Testing: an #InflectraCON2023 Live Blog

It has been a while since I've done a blog update. Granted, it's been a while since I've been anywhere so reality has been much of the same but I am currently at InflectraCON and taking notes, so you can all come along for the ride if you'd like :).

Bob Crews

CEO, Checkpoint Technologies

Our first talk is with Bob Crews and is covering Risk Analysis to improve testing. Interestingly, we have seen the complexity of software development explode over the past couple of decades. Web sites and apps have matured significantly and what they can do has increased exponentially and continues to do so. By virtue of that, sites and apps are becoming more challenging to test every day. We can't test everything, no matter how delusional we believe ourselves to be. Thus, we have to apply a different metric. We have to consider what is critical and of most importance, and then work our way down from there to "nice to have" long before we ever get remotely close to "we've done verything" (trust me, no one gets to that point, ever).

With this, we need to make sure that we have a clear understanding of what areas are most important, what risks we face, and how we are able to mitigate those risks, to the best of our ability. We can't prevent risk but we can do some mitigation in the process. By analyzing what the potential threats are, we can make sure that we put the most important situations at the forefront. Elisabeth Hendrickson often led with the idea of waking up and seeing your company on the front page of the local newspaper. What would be the most terrifying thing you could see in those headlines? If you can envision that, then you can envision what the potential risks are if your product were to fail. Odds are, we will never face anything that dire but it illustrates the critical elements that we should be alert to. By putting those horrorshow examples front and center, you have done a simple risk analysis of what could go wrong. From there, you can start to consider what would be next in line, and then consider how to mitigate those potential issues.

To be clear, risk assessment is a time-consuming process and can be as formal or informal as you want to make it. It can be an enterprise-level operation and exercise, or it can be a personal and singular effort just for our own benefit. I'm not sure how many people have pipeline CI/CD systems but much of the time, we have created tests that are independent and can run in any order. That's great for parallelization and speed but it may not be the best approach for risk mitigation. In a randomized, parallelized environment, every test is basically considered equal. Every test has the same potential to be a pass or fail and every test can stop the pipeline until it is resolved. How often do we find ourselves working on trivial tests that stop the system while something major doesn't even get run? There are possible ways to set up a prioritized run and make those the tests that get run first and cover the broadest area possible. By doing this, we can schedule and structure our tests so that they run in a criticality order. Think of it as placing your tests in folders, where those folders are rated by priority. We would of course want to run the tests in folder #1 before we run the tests in folder #9. To determine what those tests are based on that kind of hierarchy, we would need to evaluate and assign a risk assessment to each test.

By taking the time to look at a test, giving it a risk impact score, a likelihood that it might happen, and the possible frequency that it might happen, we can determine which bucket an item falls into. Also, high impact is subjective much of the time, but there are places where that subjectivity can rise from annoyance to a critical issue. Over time, we can get to the point where we might assign a weight to these tests, let's say that 99 is a top weight and 10 may be a minimal weight (I'd argue anything less than 10 may not even be worth running, at least not daily or as part of the full CI/CD commitment).

The fact is, we often look at risks as being "Acceptable". For years, Accessibility and Inclusive Design are low priority items unless legal action pushes them to the forefront. Accessibility may be seen as a low-priority item unless a big client demands it to buy your product. Then Accessibility rapidly rises to the top of your risk list. Security is always a top-level and critical area but how much is critical? If everything security related is critical, then nothing really is. Of course, we want to keep the system secure but what level is intelligent and prudent coverage and what level is overkill? To that end, we create a Risk computation, based on the classic four quadrants (urgency and impact, meaning we have at level 1 high risk and high impact, level 2 being low risk and high impact, Level 3 being high risk and low impact, and level 4 being low risk and low impact). Level 1 is of course the most important and arguably Level 3 is the next most important. Level 4 is probably not even worth our time but again, circumstances can move any of these situations into a different quadrant. This is why risk assessment is never a "one-and-done" thing.

There's a phrase called the "wisdom of the crowd" where the idea is a large group of people can determine what is important. If enough people consider an issue to be an issue, it will be addressed. It may or may not make a lot of sense on the surface but if enough people consider it important and make known the fact it is important, best be sure it will be considered and worked into whatever process is necessary to have it be addressed. The crowd is not always right but it is often a good indication of conventional wisdom. Usability often falls into this. While we may decide that a process is logical and rational, if enough users disagree with us and decide they will not use our product because of it, it will become a talking point and possibly a critical one if enough people voice their displeasure. 

Over time, we can get pretty good at looking at the risk areas we face and weigh them in order of how critical they are. We may never get to a perfect level, but we will come closer to a workable risk assessment that will help us address the most needful things and prioritize those areas over just trying to be thorough and cover everything.

Value Streams, Quality Engineering And You: a #PNSQC2022 Live Blog

Wow, it's been an eventful couple of days but we have reached the end of the formal talk phase of the conference. This is the last talk before the festivities that follow and we get to go out and have fun in and around Portland. With moderating talks and being called in to pinch hit for a session, this has definitely been an eventful conference. Still, all good things must come to an end, and with that... 

Kaushal Dalvi, UKG

Today we have a new "D-D" to add to our list. Specifically, Value Stream Driven Development. So what does that actually mean?  We have a vast proliferation of development methodologies, so what does VSDD add to the DD nomenclature? Better yet, what is our value stream to begin with? Basically, our software's availability, robustness, performance, resilience, and security all add to the value stream. Anything that has an effect on any of those aspects can degrade that value stream. Thus, if we are looking at Value Stream Driven Development, what we are aiming to do is make sure that any change, any update, or any modification effectively adds to the overall value of your offerings. Additionally, as Lean Engineering concepts point to, we also want to eliminate waste wherever we can. 

When we take on a new approach, or a new library or framework, we can often be enticed by "the new shiny". I get this. Tools are awesome, they are fun, and they are nifty to learn. However, there are costs associated with these tools and changes. We have to ask ourselves what the actual gain is by using or implementing these tools, libraries, or changes. Can we vocalize or express what we are doing effectively? Does what we do benefit the entire organization? If not, can we explain why we are doing what we are doing and how those changes will benefit the rest of the organization?

Value is a subjective term. We could say anything that makes us money adds value. We could say anything that saves us time adds value. Additionally, anything that makes our product safer, more resilient, or perform better could be interpreted as adding value. Also, what may be seen as valuable to one part of the organization may be seen as less valuable to another part. What is valuable to the organization may be negligible to the customer or even detrimental. Thus value is context-dependent. 

The lean principles fall into these five areas:

- Specify value from the standpoint of the end customer by product family.

- Identify all the steps in the value stream for each product family, eliminating whenever possible those steps that do not create value.

- Make the value-creating steps occur in a tight sequence so the product will flow smoothly toward the customer.

- As flow is introduced, let customers pull value from the next upstream activity.

- As value is specified, value streams are identified, wasted steps are removed, and flow and pull are introduced, repeat this process again and continue it until a state of perfection is reached in which perfect value is created with no waste.

(Womack and Jones, 1996)

This is a great reminder to help us focus on ways to make sure that we make the main thing... "the main thing". By focusing on value-add and making sure our efforts specifically target value add, we are better able to implement the five Lean principles and make them meaningful and actionable. 

Software Quality As It Relates To Data: a #PNSQC2022 Live Blog

Well, sorry I've been quiet... I was asked to give an impromptu conference talk since the scheduled speaker couldn't attend. Fortunately, I had a number of talks downloaded to my laptop so I was able to pick another talk from a few years back but hey, I had it :). So yeah, just something any and all conference speakers should consider... keep an archive of your talks available on your system or quickly retrievable from the cloud. You never know when you might be needed/asked to give a talk on short notice.

Natasha Nicolai

Back to today's other festivities (woo!)... 

How much thought do we give to  Data Management and Security? What happens to our data as we are trying to perform workflows? Where does our data go on its journey? At what point is our data standing in the line of fire or in a position to be compromised, stolen, or tainted?

Natasha Nicolai is discussing ways in which we can better manage and maintain our data and how that data is accessed, modified, deleted, and secured in the process of us doing our work. 

Odds are most organizations at this point are not using a monolithic data model, where everything is in one place and suffering a single point of failure or where a single vector being exploited could bring the whole system down or compromise all of the data.

I'm somewhat familiar with this by virtue of frequently testing data transformations. Most of these data transformations are being done on actual live customer data. That means I have to be exceptionally careful with this data and make sure that it cannot fall into the wrong hands. Additionally, I need to also make sure that none of the interactions I perform will mess up or modify that data.

Natasha is sharing a variety of strategies to make sure in production environments and specifically in Cloud environments like AWS. She makes the case that we want to make sure that the data that flows through our apps and what is visible is appropriately given permission to do exactly that. She refers to the s steps and gates as "data pillars" to make sure that we are allowing visibility to just those who need to see it and hiding/protecting the data from all who do not. The idea of "data lakes" is again ways to make sure that we maintain data integrity but to also give us the ability to store data and pack it away so as to not be accessed when it isn't meant to be.

There's a lot here that I must confess I have limited exposure to but I'd definitely be interested in seeing ways to learn more about these data security options.

Digitizing Testers: A #PNSQC2022 Live Blog with @jarbon

I must confess, I usually smile any time I see that Jason Arbon is speaking. I may not always agree with him but I appreciate his audacity ;). 

I mean, seriously, when you see this in a tweet:

I’m sharing perhaps the craziest idea in software testing this coming Tuesday. Join us virtually, and peek at something almost embarrassingly ambitious along with several other AI testing presentations.

You know you're going to be in for a good time.

Jason Arbon 

I'm going to borrow this initial pitch verbatim:

Not everyone can be an expert in everything. Some testers are experts in a specific aspect of testing, while other testers claim to be experts. Wouldn’t it be great if the testing expert who focuses on address fields at FedEx could test your application’s address fields?  So many people attend Tariq King’s microservices and API testing tutorials–wouldn’t it be great if a virtual Tariq could test your application’s API? Jason Arbon explores a future where great testing experts are ultimately digitized and unleashed will test the world’s apps–your apps.  

Feeling a little "what the...?!!" That's the point. Why do we come to conferences? Typically it's to come and learn things from people who know a thing or three more than we do. Of course, while we may be inspired to learn something or get inspired to dig deeper, odds are we are not going to develop the same level of expertise as, say, Tariq King when it comes to using AI and ML in testing. For that matter, maybe people look to me and see me as "The Accessibility and Inclusive Design Expert" (yikes!!! if that's the case but thank you for the compliment). Still, here's the point Jason is trying to make... what if instead of learning from me about Accessibility and Inclusive Design, *I* did your Accessibility and Inclusive Design Testing? Granted, if I were a consultant in that space, maybe I could do that. However, I couldn't do that for everyone... or could I?

What if... WHAT IF... all of my writings, my presentations, my methodologies & approaches, were gathered, analyzed, and applied to some kind of business logic and data model construction. Then, by calling on all of that, you could effectively plug in all of my experience to actually test your site for Accessibility and Inclusive Design. In short, what if you could purchase "The Michael Larsen AID" testing bot and plug me into your testing scripts. Bonkers, right?! Well... here's the thing. Once upon a time, if someone were to tell me that I could effectively buy a Mesa Boogie Triple Rectifier tube amp and a pair of Mesa 4x12 cabinets loaded with Celestion Vintage 30s, be able to select that as a virtual instrument and impulse controllers, and get a sound that sounds indistinguishable compared to the real thing? Ten years ago. Impossible. Today? Through Amplitube 5, I literally own that setup and it works stunningly well.

Arguably, the idea of taking what I've written about Accessibility and Inclusive Design and compartmentalizing that as a "testing persona" is probably a lot easier than creating a virtual tube amp. I'm not saying that the results would be an exact replica of what I would do while I test... but I think the virtual version of me could reliably be called upon to do what I at least have said I did or at least what I espouse when I speak. Do you like my overall philosophy? Then maybe the core of my philosophy could be written into logic so that you can have my overall philosophy applied to your application.

I confess the idea of loading up the "Michael Larsen AID" widget cracks me up a bit. For it to be effective, sure, I could go in the background and look at stuff and give you a yes/no report. However, that skips over a lot of what I hope I'm actually bringing to the table. When I talk about Accessibility and Inclusive Design, only a small part of it is my raw testing efforts. Sure, it's there and I know stuff but what I think makes me who and what I am is my advocacy and my frenetic energy of getting into people's faces and advocating about these issues. Me testing is a dime a dozen. Me advocating and explaining the pros and cons as to why your pass might actually be a fail is where I can really be of benefit. Sure, I could work in the background, but I'd rather be the present Doctor as we remember him on Star Trek: Voyager.

Thanks, Jason. This is a fun and out-there thought experiment. I must confess the thought of buying me as a "Virtual Instrument" both cracks me up and intrigues me. I'm really curious to see if something like this could really come to be. Still, I think you may be able to encapsulate and abstract my core knowledge base but I'd be surprised if you could capture my advocacy. IF you want to try, I'm game to see if I could be done ;).