Tuesday, April 13, 2021

Starting Over On Twitter with TheTestHead

 It's a strange feeling realizing that ten years of communication and connection can be taken over and made irrelevant.

For those who didn't see yesterday's post, my Twitter account was hacked, and the email address assigned to the person who hacked it. My attempts to contact Twitter about this have been answered thus far with:

"please respond with the email address associated with this account." 

Well, I would if that address was still mine but alas, it is not, and really, I only have myself to blame.

So let's have a little chat about this tale of woe, what I should have done and how I'm going to move on with this.

For starters, my plan to have "mkltesthead" be a ubiquitous tag that was once and done now has run into a bit of a problem. Granted, "mkltesthead" is a bit arbitrary to begin with. I first came upon the idea when I wanted to name the TESTHEAD blog. I really wanted testhead as a Twitter handle and name to use but I couldn't get it as it had already been used.  Thus the convention that started here spread out as a username in many places. During the pandemic, I admit that my Twitter participation was sporadic at best. I just wasn't in the mood to tweet, so I wasn't really paying attention to that account. Well, I paid attention yesterday, that's for sure, when I discovered I couldn't use it any longer!

To be clear, there are a couple things anyone who interacts with me should know:

First, I will not ask you for money, EVER! Granted, I may ask you to go over to Ensign Red's Bandcamp page and buy some music, but that's about it ;).

Second, why would I want to sell my account? For what purpose? Who else would benefit from being TESTHEAD?

Anyway, it's looking less and less likely that the account will be recoverable, so I have mentally prepared to move on. I have created a new account, and it looks like this:

Please note the new name. It's @TheTestHead. Seeing how easy it was to get that, I am a bit chagrined I never tried to change it to that before (LOL!). 

In any event, I will tell you what I suggest everyone do and what I should have done:

- update your password regularly. Even if you think you have a wildly creative password no one else will figure out, you may be surprised how easily passwords can be cracked nowadays.

- do an audit and see what devices and apps have access to your account(s). The more avenues for data flow, the more likely you will be a victim of a breach.

- if you have been delaying setting up multi-factor authentication, do so now. Make sure that you create barriers to people taking over your stuff. It may feel like an annoyance but trust me, having your account lifted and having to explain to people "no, that's not me asking for money" is much more annoying.

One might think that a seasoned software tester should be well aware of stuff like this. Just because We should be aware doesn't necessarily mean we always follow our own advice or everyday practices. We can get lazy as well. This is just an example of how getting lazy can come back and bite us.

 In short, learn from me ;).

Monday, April 12, 2021

mkltesthead on Twitter has been Hacked

I am sorry that this gets to be what breaks my radio silence on the blog for 2021 but I guess if it motivates, it's a good thing, in that sense.

If you interact with me on Twiter with my account of "mkltesthead", please be advised that that person you are communicating with as of some time today is not me. It is someone who hacked and has taken over my account. I'm in the process of trying to see what I can do to get it back but there is the distinct possibility I may not be able to.

Interestingly enough, the person who currently has it is willing to sell it back to me or anyone else. The only problem with that is I have zero interest in doing that. It would be sad to lose a ten-year and running account and one that's associated with my name so thoroughly but if I must start again, then I shall start again.

Hopefully, it won't come to that but please, if you see @mkltesthead for the next bit, and I haven't updated this page or made a new post, please assume the hacked account is still hacked and in the hands of the hacker. Also, if you'd like to do me a solid, call the hacker out and let them know it isn't me and you know it isn't me.

Thank you all very much!!!

Thursday, December 31, 2020

Summing Up "The Ludicrous Year" that was 2020

 I had a feeling that my run of the joke that was the lyrics of  "Once In A Lifetime" might come to an end in 2020 after ten years but frankly, nothing in those lines can be used that can sum up this year that absolutely redefined reality for so many. The only line that matches would be a repeat anyway... "well, how did I get here?"

It started out with my looking forward to a lot of new opportunities. My band, Ensign Red, had just recruited a new guitar player to replace our longtime outgoing guitarist. We were looking forward to a year of a new infusion of ideas, of songs, of shows, and other avenues to perform. I was just coming off of a string of dates with the Sea Dogs/Paddy West School of Seamanship during the Dickens Faire and I was looking forward to a year of performances where I'd be able to show versatility and get to perform in more places. 

Then "The Ludicrous Year" took over.

For four whole months, we didn't do anything together as we were under "shelter in place" rules and we did our best to follow them. we invested in Zoom setups. We invested in a shared file store to trade song ideas. We invested in new interface technology to capture what we wanted to record and make it as close to seamless as we could so everyone could work on ideas. We put together a short series of interviews with the band members and we would put some rehearsal footage together to leak out to people to hear what we were doing. I'd Zoom with the members of the Sea Dogs and Paddy West to stay in the loop and hope there might be some performances of some kind (spoiler, nope, there weren't). Still, I feel like I got the chance to get to know the other performers in a way I might not have otherwise and I had the chance to get a better feel for where I might be able to make contributions in some way in the future, whenever that future will be and what it will be.

I started out with a team that I had worked with for seven years, a product I knew well, and a pretty clear path as to what I had to do to keep it going as we expected. 

Then "The Ludicrous Year" took over.

With the need to reposition and reapportion who was working on what, including the tough decision to let go of most contractors,  I was asked if I'd be willing to join a group that needed a tester and hadn't had one before, to go into an avenue of our company that was utterly foreign to everything I had been working on up to that time. There were no familiar faces, no familiar rituals, no familiar workflows to fall back on. I said yes and thus started my learning about a whole new way of looking at testing and also looking at data. I took on an automation project unlike any I had previously worked on. Far less UI focus, much more API manipulation. Less browser interaction, more flat file manipulation. Less "does this look right?" and more "is the data accurate?" challenging, but interesting. I had to say "goodbye" in a way to a long time family but I got to meet a whole new team. The challenge was of course that I struggled to keep up with the people who were my long-time team as we were now focused on different things and my old comfort zone had disappeared.

I had looked at the opportunities for conferences that I was going to take part in for 2020. 

Then "The Ludicrous Year" took over.

I had to adjust to doing conference talks on Zoom. I had to manage rooms of people I couldn't see, record conference talks to a camera with no one watching or listening, and then interact with people via chat to be able to see how well I did or if I did well at all. Frankly, this was challenging as I tend to work off of a room of people and their reactions to see what is needed and adjust my message, even if I have practiced it numerous times. I also got to work with video tools and presentation tools in a way that I hadn't done so before, so there was a lot of learning and new approaches I could look to.

My family reality had looked like it would be productive and fun. Two of my daughters were working at San Francisco International Airport, with carriers working out of countries they were looking forward to visiting and perhaps even working in for a bit. My son was working on setting up a studio with some other friends and investors in Los Angeles. Christina had several opportunities with the law office she works with and on the whole, 2020 looked like it might be an adventurous year.

Then "The Ludicrous Year" took over.

Both of my daughters were furloughed from the airport (makes sense when nobody is flying or flying in such a limited capacity, especially with International carriers). My elder daughter decided to take the opportunity to pursue a cosmetology school program. We set up the upstairs living room area to be her online classroom and her own salon area for learning and practice. My younger daughter found work at a couple of places outside of the airport and has a small recurring role in the airport concierge service that she can do a few hours each week but it's definitely not the career she had been working towards. My son had to hunker down and get creative for ways to work in an industry where performances and recordings and touring were the main bread and butter of the industry. He's said it's been a challenge, added to the fact that he was the one out of all of us thus far to actually contract COVID-19. One of his housemates brought it home to all of them and thankfully his case was mild, though he said he wouldn't want to see anyone go through the six weeks or so that he did dealing with it.

For me as a whole, this year felt like treading water. Much of what I enjoyed doing had to be bottled up and thus I tended to likewise treat myself that way. Still, I could say that there were several neat developments:

- The Testing show returned to twice a month publication, so I was able to keep busy with that.

- I had some opportunities towards the end of the year to write for some publications I hadn't worked with before.

- The fact that I wasn't performing or traveling to festivals meant that the money I would have spent over the course of the year didn't get spent and that allowed me to revamp my studio/rehearsal space and buy new equipment for a guitar rig that I had dreamed of owning for years, and the oddness of "The Ludicrous Year" made that both more possible and actually more affordable, since used gear shops were filling up dramatically this year.

- One interesting development, and for those curious, is that I joined TikTok and started making content about "Heavy Metal Vocal Technique", among other things. That has also caused me to revamp my home studio space (about thirty times) so as to make it more interesting for filming and presentation purposes. If you'd like to see me doing my thing there, it's @mkltesthead :).

Needless to say, this was not the year I had hoped for and I do not want to make light of the fact that people lost loved ones this year or literally died this year. I have seen both the best and worst of human behavior. I have celebrated highs and dealt with crashing lows. Still, I am here, all of my family is still with me, I'm gainfully employed while many others aren't, and I can look forward to 2021 that I am again hoping will prove better than this year now closing down. 

Be excellent to each other :)!!!


Thursday, October 15, 2020

Get the Funkify Out: A Neat Accessibility Tool/Disability Simulator

 Are you all sick of me yet? Wow, that was a lot of writing/typing/conferring this week. to be honest, I've really missed it. I was happy to participate in PNSQC this year even in the unusual circumstances and challenging technical issues we went through. I will talk more about that in another post and also in the next The Testing Show podcast but for now, I want to share something a little new for me and maybe new for a lot of you all, too.

While I was developing my "Add Some Accessibility To Your Day" workshop, I reviewed the tools that I use regularly and looked to see if there was anything interesting out there I hadn't played with recently. Many of you know my general toolkit:

  • WAVE Browser Plugin
  • AXE Browser Plugin 
  • Accessibility Developer Tools
  • VoiceOver and NVDA Applications (MacOS and Windows 10)
  • NCSU Color Contrast Analyser
  • Hemingway Editor (yes, it is an Accessibility tool. FIGHT ME ;) )
I of course discussed these but I also found a newer tool that definitely interested me and that I've been having fun working with. That tool is called Funkify.

Funkify is a Chrome Extension and it is a little different than the tools mentioned above in that this doesn't really call out errors or find bugs... at least not in the traditional sense. This is a simulator that puts you in the driver's seat as any number of people with disabilities so you can experience your site through their eyes/ears/hands.

Funkify modifies your site so that you can see it as these personas see it. You also have the ability to create your own personas based on criteria that you deem important and you can adjust the level of challenge/disability.

For example, let's look at the W3C Before and After site.

How might this site look to someone with dyslexia? Funkify can give us an idea. Just press the toolbar and select the defined persona (in this case "Dyslexia Dani") and expand to see the options.

You can adjust the amount of jitter/scramble of the letters. Make it mild or severe.

Onvce you've dialed in the level you are interested in, let it run until you are satisfied (or dismayed, or annoyed, take your pick):

There are a variety of disabilities that can be simulated: color blindness, astigmatism, jittery hands, high distraction, macular degeneration, or you can create your own agent/persona with the criteria and level of disability that you are interested in simulating.

Give it a name and a description and save it. It's ready when you are.

This is not too far from my own visual situation. In fact, this looks very much like the page without my reading glasses.

In any event, if you want to have a simulator that will put you in the shoes of a variety of users, specifically those with disabilities, Funkify is worth a look. to be clear, the free version is limited, if you want to have all the options you will need to pay for the Premium version. still, if you want to have the opportunity to see what your site looks like in a variety of Accessibility scenarios, this might be just what yo uare looking for.

Wednesday, October 14, 2020

PNSQC 2020 Live Blog: Diversity in Testing and Technology: A Moderated Panel


Wow, three days go by fast when you are typing like mad. This is the last formal talk before my workshop and after my workshop, the conference will be over.

Tariq King is moderating this panel discussing the diversity in testing and technology and he's leading with "is it important if people aren't doing anything to promote it?"

Lisette has built several teams and she says that the teams need to match the users. If the users are diverse, then the teams need to likewise be diverse. Tariq also commented that diversity additionally means that designing for our users is often a way to drive revenues. 

Raj pointed out that the world of work has changed, with teams spread out all over geographical areas so diversity is of course important because diversity exists somewhat by default, even if it's not intentional. even with that reality, there is still a lot of work that needs to be done to more effectively represent our customers and to have their involvement in the engineering and testing process. 

Hussain In the individual contributor roles, there may be an overrepresentation of some groups but that definitely is not the case in management. Management skews heavily white and male. In ways, Education requirements can be a barrier, so google as an example is looking to offer a certificate program that, if implemented, will count the same as a degree. Rebecca mentioned that while this is a step, the question is how will that create new pathways up the career ladder.

Lisette points out that the individual contributor pipeline is relatively diverse but the people hiring are not diverse. When companies promote and help diverse candidates grow, they can become leaders in their organizations and become decision-makers for their companies. 

Raj points out that often, mandates are made to say that "x number of people need to be diverse" but there's little emphasis beyond the numbers. Hiring is great but what matters is the path and opportunities for the hires beyond just filling seats. where will these people go in the future? Will they be seen as valuable team members, encouraged to move up, and rise up in the organization?

I'm happy to hear about Accessibility and diversity including individuals with disabilities. Yes, my wheelhouse, so let me crow a little ;). there are specific and unique challenges when dealing with neuro-diversity and ability-diversity that makes this challenging. If there is an opportunity to interview a hearing-impaired engineer, how will that interview be conducted? Is the burden of interviewing on the interviewer or interviewee. If an interpreter is needed, who is on the hook for that?

Tariq notes that successful teams are gauged on the amount of time they allow each other to speak, as well as to allow for the gender of the team members. It's interesting that successful teams tend to have more women involved. This mirrors my original experience with Cisco when the majority of the testing team was done by women engineers. Was that a fluke of Cisco or was that a broader tend when I hired on? I'll honestly never know but it was definitely an influence on me and my work over the years. I've long said that if it weren't for a cadre of women who helped me over the years, I might not be in this industry at all.

Lisette say that to just assume a woman would be an excellent fit for QA is wrong. It's interesting to me because I had wondered over the years if I was the odd one because I wanted to be a tester over those years I was at Cisco or that I was actively encouraged by women over those years to participate because that was their world and they were welcoming me in. as Cisco grew, it certainly seemed that the overall population of testers that were women was not as pronounced, though I would still say it was significant by the time I left Cisco in 2001. 

As the father of two daughters and a son, I have actively encouraged my daughters to pursue the goals that they want to. One of my daughters wants to work in aviation, ultimately to become a pilot someday. To that end, I have encouraged my daughters every bit as much as my son and I actively want to see them succeed in whatever role they wish to participate in. 

I am curious to see if COVID-19 and the cratering of expectations of working in a specific location long term might have on the overall attitude of who works where and when. Will this help to encourage a more diverse group of people to apply for jobs, especially if the older ex[pectation of packing up everything and moving someplace is not as actively sought after. 

sadly, this is all i can track as I have a workshop to prepare for so I will bid adieu here but a great conversation and glad to hear it while I could :).

PNSQC 2020 Live Blog: Towards A Culturally Inclusive Software Quality with Jack McDowell & Ying Ki Kwong

It's been interesting to see how we have seen the world adapt over the past thirty years that I have been in the software testing industry. In some ways, it's a very different world and yet at the same time, not much has changed. When I came into the testing world, there was a need for understanding requirements, there was a need to know how to test and there was a need to execute a certain number of tests, manually if we must but automated would be spectacular.

What I just described was 1991. Does it really sound that much different than 2020? Let's take a look at some other factors. Who is doing the work? For me, I remember thinking about this as I was working for Cisco Systems and I was hearing how few women or PoC were actively involved in tech. I frequently wondered what they were talking about as I was literally surrounded by women as peers and women as managers, as well as a rather diverse team as related to cultural and ethnic background. It would take me several years and watch the company grow to have that lens be changed and see the point. Where am I going with this? It's sometimes hard to see the issues and challenges we face when we think that the world being described doesn't match our experiences. I made the mistake of thinking the early days of Cisco Systems were indicative of the world of tech as a whole. 

Again, interesting but Michael, what are you going on about? Well, it's key to understanding Jack and Ying Ki's talk (and Jack is the one delivering it but since Ying Ki helped write the paper, I'm giving him credit, too ;) ). In any event, the point is that we see the world through our lens, and that lens may be accurate or not but we won't know it is accurate if we don't have other points of reference. With this idea, we should also be asking "what does quality actually mean?" It means whatever the team at large decides it means, and then we radiate out from there. However, we are missing a bit of the point that quality is going to be skewed if we don't seek to pay attention to what others think that quality is.  

An idea that Jack presents is that we not look at trees as a metaphor for meaning but instead look at rhizomes. A rhizome is a plant that spreads out a root system and buds, vines, etc grow out at a variety of points. we might look at these as being multiple plants but in truth, it's the same plant. 

Ha! Communities of meaning using Accessibility. We're in my court now (LOL!). Well, not really but it is interesting to see what examples for accessibility are used and what actually counts. Jack is correct that accessibility often looks at disabilities as a monolith when in reality, there are a variety of unique disabilities that require very different methods of accommodation. I'm all too familiar with the approach of "load up a screen reader, walk the application and call it a day". Yes, I've been there and so have a lot of others. The fact is, that approach leaves a *LOT* of things out of the mix or even giving consideration. Sight issues are not the same as hearing issues, and they have little to do with mobility issues, and those have little to do with cognitive issues, and on and on.

So Standards are often included in these quality questions. Standards can often be helpful but standards also tend to take a prescribed way to identify what makes for software quality. yet the question remains, does a standard take into account cultural differences of other approaches? Jack is arguing no and I'd say I agree with him. Jack just said that Agile Software Development is pretty much Anglo-centric. Yang Ki refutes that the way that agile software development works in the USA would not be culturally acceptable in Honk Kong, for example. The idea that individual engineers would be able to express their opinions or desires about products and openly question management. It also shows that in other cultures the Agile principles can be subverted and exploited. 

Again, the question we want to consider is "how does culture affect quality?" The answer is there is really no monoculture in all of this, there is a mixture of cultures that blend together and often help define these communities of meaning. How this is actually accomplished may well be a long and involved process but it is interesting to consider other communities of meaning to address these issues.

PNSQC 2020 Live Blog: Are You Ready For AI To Take Over Your Automation Testing? with Lisette Zounon


All right! How is that for a title ;)? I give props for coming out swinging and yes, I am indeed curious as to whether or not AI will actually have a long-term impact on what I do as a tester or automation programmer. It feels weird to say that but since "Senior Automation Engineer" is my official title, yeah, I kind of care about this topic :).


Many tools are built around allowing us to automate certain steps but in general, automation excels in the areas of the rote and the everyday repeatable. Automation is less good at dynamic environments and where there's a lot of variabilities. However, perhaps a better way to think about it is that automation struggles with areas that *we* feel are dynamic and not rote. Machine Learning can actually help us look for the repeatable, perhaps more specifically in areas that we are not currently seeing those patterns.
We are seeing the growth of pattern recognition tools and visual validation. As we get further into the process, we see that there are more uses for visual validation tools. It's not just is the picture in the same place. My question would be how can we leverage these tools for more approaches? As in most situations, a lack of imagination is not necessarily a lack of adventure or spirit but more often a lack of relevant experience. We tend to get mired in the specific details and we tend to look at these little tedious issues as taking too much time, requiring too many steps, or not being flexible enough to actually be useful.

Lisette makes the case that AI can help with API tests. Since API tests can be bounded (as in there's a set of commands and those commands can take a set of parameters, etc. So they can be generated and they can be called. In addition, auto-healing tests are often touted as a step forward., I will confess I have seen self-healing tests in only a limited capacity but that has more to do with what we use and what we currently test with rather than what is available and usable. I want to see more of this going forward and interact with it in a meaningful way.

I hear often the idea that AI will help to create more reliable automated tests. This comes down to agent counts keeping track of what is right or wrong by the definition of the software. It sounds cool on the surface but again, I'd love to see it in action. Lisette makes a good point that automation for the sake of automation doesn't really buy us anything. Our automation needs to serve a purpose so putting these AI tools to help us find critical paths or critical workflow steps and processes is worth the time. Again, I'm willing to give it a go :). 

PNSQC 2020 Live Blog: Let’s Focus More On Quality Engineering And Less About Testing with Joel Montvelisky


Joel starts out with a very blunt question... what value do you provide to your company? Not in an abstract sense but in a cash sense. Does your being there benefit the company in a bottom-line manner? It's a tough question in many ways because software testing is a cost center. No matter how we want to look at it, we are a cost of doing business. Granted, that cost may very well prove to be justified, especially if we find something that could be disastrous if it were to get out but it's hard to define how much money software testing earns for the company. truth is, unless our company is in the business of selling testing services, we are not really earning money for the company by doing testing.

this means that many testers often do something other than "just test". that has been the case with me many times, in that I put on a variety of hats when needed. sometimes that hat is tech support, sometimes it's systems builder, sometimes it's build manager, accessibility advocate, fill in the blank. In short, we do our best to add value in a variety of places but unless we are directly connected to the health of the organization and the generating of revenue, we are one step removed from the process and our value is less obvious and sometimes not recognized at all.
Joel makes the case that changing models of software development are applying pressures to the traditional role of a software tester. In the process, many testers are morphing into Quality Engineers. That's cool and all but what does that involve? Ultimately, it's that we work with developers to test and deliver products quickly, get feedback from the field, and continue to help develop software quickly and with high quality. Notice Joel is not saying "stop testing" but focus on additional areas that go beyond traditional testing. 

As I was listening to this, I kept thinking "oooh, this sounds so much like the A/B Testing podcast. and sure enough, that's EXACTLY where Joel was going with this (LOL!). For those not familiar, Alan Page and Brent Jensen host the A/B Testing podcast and they are also champions of Modern Testing (MT). In many ways, the move to DevOps is helping to emphasize the need and focus of testers to move into a more MT paradigm. There is still testing but the testing is less tied to individual testers and testing teams. I've witnessed this in my own organization. We have a testing team but all of us are individually embedded into separate teams. Our focus is less that of a testing team that reports to a manager and is the center for quality. Rather, we are often one or two people embedded in a specific team and while we test, we often work with developers to help them focus on quality and quality aspects. 

As we focus on quality and less on testing, we will find that we may be doing less rote testing but a lot more quality initiatives. We can be there early in focusing on developing quality requirements, we can get involved early and help programmers with questions and considerations as they are writing the code, we can get involved with automation and infrastructure so that much of the rote and humdrum steps can be codified and taken out of our front line attention. We can be involved in the build management and CI/CD pipeline and make sure it is working cleanly. I appreciate Joel including advocating for Usability and Accessibility. He also emphasizes having testers be part of bringing customers into the process, whether that be directly or indirectly. the better we understand the business cases and real-world uses, the more effective we can be at addressing the real quality issues. We also have the ability to teach developers about testing and test principles. I have myself had a number of situations where I've shared testing ideas and the developers have said "oh, that's cool, I've never looked at it that way." Be aware, though, that some developers simply do not want to test. That's OK, but it also needs to be clear that we are moving into other avenues and that if they don't test, there's no guarantee that we will either.

One thing's for sure, the future is going to be fluid, and to borrow from Ferris Bueller, "Life moves pretty fast. If you don’t stop and look around once in a while you could miss it."

PNSQC 2020 Live Blog: Test Engineers are the Connectors of Our Teams with Jenny Bramble


If you know Jenny, you know her enthusiasm and her energy. there's no way I'm going to capture that here, but I will do my best to capture her message at leat. 

Testers are in a unique location to bring the squad together, so to speak. In my musician days back thirty years ago, one of my bandmates said that I was the "psychic glue" that held us together. In many ways, I feel testers can be that "psychic glue" for an organization. However, to be psychic glue, it has a specific requirement and that is that we must be engaged. If we are not engaged with our team and with the other people in our organizations, we lose effectiveness.

Testers can be at the heart of communication but again, we need to make sure we are communicating to be actively involved. We talk about requirements, discuss bugs, present new features, and give the user’s perspective. No one else really has that level of reach, so let's make sure we are aware of that place we hold, and LET'S USE IT!!!

Teams are built on communication and teams fall apart without it. Sometimes I have found myself in situations where I have had to push into conversations. The fact is, we are welcome but we are not always invited. I think at times that's because we are often the bearer of bad news, or to borrow an old quote, no one likes the person who calls their baby ugly ;). that means that the ability to openly and honestly communicate belongs to us and it means we need to be careful but also deliberate in our interactions.
I have had experiences with being a musician, with being a competitive snowboarder, with being a scout leader, with being a husband, and with being a parent. That is on top of being a software tester. those are all contexts that require communicating in a little different. the way I communicate musical ideas is not going to work the same way as I communicate to scouts. Likewise, the other way around. It's not that the method of communication is all that different but it's the familiarity with concepts and approaches. Sometimes, I can just say a phrase, and my bandmates will know immediately what I mean. The reason for that is that we have interacted a great deal so we have stubbed our mutual toes a whole bunch. we've had lots of false starts. Because of that, we have a high tolerance for each other's eccentricities and that helps us communicate quickly. However, I know for a fact I could not communicate that way to the scouts I lead, or with the developers on my team. Familiarity breeds contempt, sure, but there's a benefit to that so-called contempt. I rarely get to that point with my scouts or my developers. thus I need to be a little more reserved in those capacities. On the other hand, I find that I can be more focused and granular with scouts and developers the way that my bandmates would pick me up and throw me out the door. again, style is important but communication is essential.

Jenny is highlighting that some people want a lot of details, while others want a high-level summary. A neat example she shared about how to work with a summary person is to have them review emails you plan to send. Sounds odd and awkward but at the same time, I get how that would work to get their attention and to give you hints as to how they prefer to communicate. Jenny also explains that she is a story based communicator (I love this revelation because it reminds me so much of me). The way she is describing this reminds me a little bit of "it's a baby penguin, caught on an iceberg"... and if you are not on TikTok, that may not make a lot of sense but yeah ;). the point is, invest in people and they will invest in you.

Regardless of how good we try to communicate, we often miss the mark ("What's a penguin? What's an iceberg?!"). It's not because we are dumb or indifferent, it's because we may jost not have hit on their preferred way to communicate. Some people don't like speaking but do great with texts. Some people struggle with email but do great on the phone. You just have to keep trying and find the communication mechanism that works. In short, if you intend to be a good dose of psychic glue, be prepared to communicate and be prepared to put in the time to learn other communication styles. By doing that, you can be that indispensable member of the team that no one could see functioning without you.

Tuesday, October 13, 2020

PNSQC 2020 Live Blog: Quality Engineering – Reflecting on the Past & Present to Accelerate the Future with Dr. Tafline Ramos

Ok, I hereby confess that the last talk was a hard one to wrap my head around so I'm looking forward to getting my head back on straight. Here's hoping this talk helps to do that (btw, just kidding about the last talk but I confess I've never considered floating point in depth in such a manner ever).

Our closing keynote tonight is the evolution of modern Quality Engineering. To understand where software quality is heading in the future, it helps to understand what we thought of Quality Engineering in the past.

It certainly seems that the conversation of Quality is circular. Many of the ideas of people like Deming and his points through to Margaret Hamilton and Glenford Myers. Somehow, the idea of testing being removed from development as a standalone discipline, and now we seem to be working to merge testing back into more traditional quality standards. the problem with having a dedicated tester (and so many of them for specific issues) that we created and refined the role of the tester to be at the tail end of the quality process. This reminds me of the space of testers in the early 1990s and how many there were vs the latter part of the 1990s and how many software testers there were and that specific separate group. 

Granted, I can only talk about the Cisco Systems approach in the 1990s as it was the only tech company I worked for at that point in time. Early in the days of Cisco, the software testers were not a dedicated group. Everyone who was a tester did something else in addition (my early testing years also included me being a Lab Administrator). I didn't get designated a Test Engineer proper until 1994 and that was when many others became branded as testers in a software sense and that being the core purpose for our work.

I've also seen that there does seem to be a divorce between the idea of building in quality upfront, and that there seemed to be a reliance on testers being the main line of defense for bugs. I remember that attitude and approach well, and in many ways, it is still that way. Ideally, we need to create Quality as a process at all levels. we need quality all the way at the very beginning of the story workshop that proposes a new feature. It needs to carry over through development, through having everyone at every level associated with quality and making it a core part of what they do. 

To be clear, I'm not saying people go out of their way to not deliver a quality product, just that our practices tend to make that approach harder than it really needs to be. It's interesting how shifting the word Test to Quality changes the whole conversation.

Cool, so what is a Quality Engineer, how do we become one? we would need a range of skills that are functional, technical, and consulting related, to be able to work effectively with a  number of groups, not just our own and not just related to testing. they need to be effective in methods, techniques, tools, and approaches that allow them to be effective in a variety of areas. A Quality Engineer also needs to beef up skills in technical areas, specifically coding. 

The fact is a large percentage of projects fail, badly enough to threaten a company's existence. A poor scope on requirements and quality overall ranks high in the reasons for this. There are a lot of techniques that can be used to help mitigate these failures. To reduce the overall cost of quality, it would be much more helpful to focus our energies early in the process, and let's stop the idea of testing at the late stage of development. Move the testing further back in the process and make quality the most important discipline in all groups as far back as possible.