Association for Software Testing

Testers are Gate-Crashers

Tue, 30 May 2023 07:36:00 +0200

The Association for Software Testing is crowd-sourcing a book, Navigating the World as a Context-Driven Tester, which aims to provide responses to common questions and statements about testing from a context-driven perspective.

It’s being edited by Lee Hawkins who is posing questions on Twitter, LinkedIn, Mastodon, Slack, and the AST mailing list and then collating the replies, focusing on practice over
theory.

I’ve decided to contribute by answering briefly, and without a lot of editing or crafting, by
imagining that I’m speaking to someone in software development who’s acting in
good faith, cares about their work and mine, but doesn’t have much visibility
of what testing can be.

Perhaps you’d like to join me?

–00–

“Testers are the gatekeepers of quality”

Instinctively I don’t like the sound of that, but I wonder what you mean by
it. Perhaps one or more of these?

Testers set the quality standards for a product.

Testers make the final decision on whether a product ships.

Testers choose how to trade quality off against other concerns.

I can see from your face that I’m not quite capturing what’s in your head?
Remember that gatekeeping is binary. While the gate can sit on the fence, the
keeper has to choose: in or out.

Yes, I suppose that does sound like testers having control over
business decisions. And, yes, I’m sure you’re right, nobody wants that. I have another suggestion, though!

Testers are responsible for the quality of a product.

OK, you guessed that I threw that one in for a laugh! You’re not high enough
up the greasy pole to believe that kind of responsibility can legitimately
come without a corresponding sackful of authority, resource, and budget.

And, to be fair to you, I know you think that everyone has a role to play in making a product at the level of quality the company wants.

We could go on like this, and it would be fun, but I know you’re busy so perhaps you had something
more like this in mind?

Testers assess whether a product meets quality standards …

You like that one? Less gatekeepers and more box-tickers for you, then, with
someone else to decide whether a customer gets the thing yesterday, today,
next week, or never. But I hadn’t quite finished:

… arrived at through collaboration …

I’m feeling that you’re less sure about this one now, but we’ve already agreed
that the compromise between quality and other factors is a business decision.
And in any case there’s more:

… in line with whatever time and resource budgets have been agreed.

Ah, you’re back onside now! Yes, I thought this was where you were at. You’ve
told me many times that the price of perfect is prohibitive.

While this is certainly within the scope of a testing role for me, it isn’t
quite the Gatekeeper of Quality is it? It also massively undersells the wide range of
benefits that a good tester can bring to an organisation by opening or even crashing through gates rather than standing next to them.
Image: https://flic.kr/p/4MieTg

The post Testers are Gate-Crashers appeared first on Association for Software Testing.

Agile Testing Days USA 2023 – A Lot to Think About

Tue, 30 May 2023 00:25:00 +0200

Last year’s Agile Testing Days USA was full of inspiration. This year, this conference and its community once again gave me a lot to think about.

Before the Conference

Arriving early, I had time to do a bit of sightseeing next to finalizing the preparation for my two sessions. I decided to take it slow and preserve my energy while still checking out some places I haven’t seen yet.

Another benefit of being there ahead of time is to connect with people already before a conference starts and slowly getting into networking and exchanging experiences. So good to see familiar faces again and re-connect – like with Kelsey Schoen whom I met last year. On the evening before the conference started, we had a lovely dinner group which resulted in great conversations. Many thanks to João Proença, Jenna Charlton, Jenny Bramble, Paul Holland and Erik Davis!

Tutorial Day

A dream came true for me: I finally could meet Elisabeth Hendrickson in person! She’s one of my personal heroes in tech. I followed her and her work for a long time via social media and was eager to learn from her in person. So when I realized she’ll be at this conference and also give a tutorial, I didn’t hesitate once to sign up for it. Especially as it perfectly fit my situation: “Doing the Hard Stuff“.

This tutorial was indeed worth it already. It was awesome. I had hoped to get insights and advice for current difficult leadership situations as well as guiding principles for those still to come and I was not disappointed. Elisabeth shared a toolkit of the wisdom she collected over years working with teams and organizations – a toolkit full of wealth of applicable wisdom. Super interesting on a meta level as well, as I am sharing some of my own tactics in my latest talk.

We had a small group with high safety where we could bring our current challenges, think openly together about them using the toolkit, and discuss options to move forward. The self-organized structure of the tutorial made me think of an all-day themed lean coffee session with lots of dedicated time for each topic – wonderful to get detailed thoughts and feedback from everyone, and also be able to contribute! One of my topics got discussed into detail as well and I received lots of input and ideas what to try next – along with validation of my own stance and connecting the dots on what I already knew. Invaluable.

At some point, I really wondered about my own confirmation bias – as I kept nodding throughout. I really related to the toolkit topics shared. Was it because I learned and adapted a lot from Elisabeth and her peers already over the years, or were they really reflected in my own experience? Well, probably a bit of both. Anyways, it was amazing to see lots of the ideas and approaches I had used in my past being validated and built on by a group of peers.

There’s a lot to ponder about and make use of. I’m really grateful for having had the chance to participate, I took a lot with me. I bet more people would benefit from this content, it actually would make a great book.

Every technical problem is, at its core, a people problem. With her tutorial, @testobsessed is giving us insights on how to do the Hard Stuff 🦄#AgileTDUSA2023 pic.twitter.com/UDd58u6mpt

— AgileTD Zone (@AgileTDZone) May 22, 2023

Right after the tutorial, it was time to get together with everyone and mingle for a “Meet the Speakers” event. This meant new people to get to know and connect with! A curious side note was when one person mentioned that they thought speakers would get formally introduced, and then being pleasantly surprised they’re already among the crowd – being just normal humans as everyone else.

Finally, it was time for speakers dinner. My opportunity to connect with Allison Lazarz and catch up with Larissa Rosochansky and Rafael Cintra!

Conference Day 1

The first full day of talks and workshops for everyone was full of interesting sessions. Here are the ones that I joined.

Early Morning Lean Coffee with Janet Gregory and Lisa Crispin. I make it a point to go to at least one lean coffee session per conference whenever offered. Whoever shows up are the right people and whatever topic is discussed, I gain insight from it! If I’m lucky, my own topics are selected and people’s thinking help me move forward with a challenge. Like this time – I’m grateful for the input received. Many thanks to Janet and Lisa for facilitating these sessions and for doing it so welcomingly!

Lean Coffee underway at #AgileTDUSA! 🦄🎉 pic.twitter.com/V475QxZUQ7

— lisacrispin @lisacrispin@mastodon.social (@lisacrispin) May 23, 2023
Keynote “Imperfect Agile” by Jenna Charlton. What a great opening keynote reminding all of us to remember self-care and keep our own boundaries, while also encouraging to resolve conflict in a timely manner and find closure instead of piling onto existing grudges – and emphasizing that impact is more important than intent. All that while following the story of figuring out what agile actually means. Just loved the conclusion of “Take what works, leave what doesn’t, don’t do harm – it works for us is enough”!
Keynote “Bigger than the Box” by Erika Chestnut. Great keynote emphasizing that testing is not all the work even though people try to keep us in the box. Loved that Erika showed ways how we can claim the power in what we do, seize the opportunities around us and let quality shine in a new light together with everyone. Very important messages.
“Stop Making QA The Last Train Stop Before Production” by Rick Clymer. Really related to this talk and think more people need to hear it. I witnessed so many folks being stuck in what they do. This talk showed very concrete and actionable things they could do to get out of their situation and not only provide more value yet also get more value out of their work themselves.
“Business Agility Lab” by Ray Arell, Rhea Stadick, Tobey Aumann and Shawna Cullinan. This was a positive surprise! I didn’t expect much and came to the session as a mere filler. And received a nice hands-on introduction to Wardley mapping, a topic I would have chosen if it had been offered in the program! Loved the examples Tobey provided and the opportunity to try it ourselves. Wasn’t too easy to get started with, yet understanding grew the more we tried it.
Keynote “Focus. Deliver. Learn. Repeat.” by Elisabeth Hendrickson. What an amazing keynote. Just kept nodding throughout, so many excellent points made! Sadly, this could have been given twenty years ago already, and maybe was. Why haven’t we learned this in the meantime? Overall, this was a dearly needed reminder to focus back on XP principles, including the reasoning why. Delivered in a wonderful energetic and authentic way.

My own session on this day was my workshop “Grow Your Technical Confidence“. I had a small but great group, learning together. It’s always fascinating to see people dare to try something new and potentially scary, and then have them figure out what they already know about it and that they can already contribute – hence increasing their confidence for the next step once again.

Shift your perception and focus on learning – enjoy your journey of becoming technically confident with @lisihocke workshop 🦄#AgileTDUSA pic.twitter.com/YdRoJtnsPO

— AgileTD Zone (@AgileTDZone) May 23, 2023

To conclude the day, organizers invited everyone to an Oktoberfest party! Loved the conversations with Melissa Eaden, it’s such a pleasure to reconnect with folks I haven’t met for a while. More exchange followed with Ray Arell, Tobey Aumann, Tara Walton and others before the evening came to an end.

Conference Day 2

The last day of the conference provided further insights and even more to ponder about. Here are the sessions I listened to.

Keynote “Where is testing heading?” by Paul Holland. This keynote provided a reminder on bad trends in testing, historically and current, along with their reasoning. So what can testers do nowadays? Paul recommended to focus on what automation cannot do well, and make use of the tools at hand.
“The dark side of agile implementation” by Lisette Zounon. Just loved the focus on how culture is essential whether people can thrive or literally end up in the emergency room. The audience interaction to openly think about warning signs and anti-patterns was a nice addition. It was quite sad to see how many folks seemed to have endured rather toxic cultures. Yet what makes us succeed is team happiness! Loved the emphasis on taking care of ourselves and practicing self-care – dearly needed that reminder.
“Mobile app testing sucks. Here’s how to do it better.” by Eden Full Goh. This talk provided lots of insights on what we’re usually missing when testing mobile apps. Loved all the examples of new features, device configuration settings, and more things that are too often not considered – especially when it comes to automation. Very tangible and practical advice and new ideas how to test better on mobile, both on exploring more and finding new ways to automate user interactions.
“The WHY you are!” by Dr. Rochelle Carr. What an amazing keynote in content and delivery. Loved Dr. Rochelle Carr’s abundant energy on stage and refined skills to truly engage the audience with the content shared! The messages themselves – they hit home. More than I expected to, this keynote gave me lots to think about my own why and purpose, what drives me – and how it changed over time. Very impactful.
“How we’re setting up QE’s to fail” by Vernon Richards. This talk opened my eyes that should have already been open. I knew about glue work, and I knew about quiet quitting. Yet Vernon made the connection to where testers often find themselves, and that all of our work is indeed technical leadership – whew, that blew my mind. I think I heard this message before, yet this talk delivered it to me just at the right time to truly understand it. Gave me a lot to think about!
“Building a Culture of Accessible Software” by Jon Hussey. This talk provided a lot of actionable advice on how to increase awareness about accessibility, a topic that is very relevant to me right now. I loved how Jon connected this to his own story, what he tried, what didn’t work and what did. His one request was for each and everyone of us to ask for more accessibility – something we all can do. A very important topic we all need to hear more of!
“Feedback Techniques for Transparent Teams” by Dee Ann Bernau. We all need to learn how to receive and give better feedback as it’s essential for learning. This talk gave models to help our thinking about feedback as well as tangible steps to take and improve on feedback ourselves. One point caught my eye that I would have loved to hear more about: Creating a system to call out bad behavior in your team. More to think about.
Keynote “The Secret To My Success” by Melissa Eaden. This keynote was amazingly brave. Mel shared her personal story on stage which allowed me to realize how many more people are affected by trauma and systemic issues than we might realize from just seeing the “successful” facade. Really appreciate the reframing of what success means for us and finding our own definition of what to work toward. Loved the emphasis on how giving someone a chance can have a life-changing and even life-saving impact on them, and how especially tech can lift people out of a situation they would not have gotten out otherwise. As well as asking for an outside observer view! One more argument to indeed get coaching, or therapy, or both. I admire Mel for her vulnerability and I hope this talk helps more people on their journey towards more good than bad days. It definitely had impact on me, I have lots to think about.

On this day, I gave my brand-new talk “Team Transformation Tactics for Holistic Testing and Quality” for the first time live on stage – in its most condensed short form. According to feedback it seems people got something out of it to take with them, what more can I want?

@lisihocke sharing that while implementing holistic testing for team transformations can take longer than expected, the benefits are worth the journey. #AgileTDUSA pic.twitter.com/eHr5rH8ka3

— Tristan Lombard 🇺🇦 (@TristanLombard2) May 24, 2023

Share access, share knowledge, share pain, share glue work, and share the credit.
– @lisihocke

Step by step tips on team transformation.. amazing 😍#AgileTDUSA pic.twitter.com/NNOmKjqVCn

— Tara (she/her) (@TaraWithTiaras) May 24, 2023

A great bonus this day: Ash Coleman was in town and stopped by to say hi! Such a pleasant surprise, was so good to see her again, even if only for a few minutes.

When you accidentally crash a testing conference and run into all of your friends! 🤩🤩🤩 @AgileTDUSA 🦄 @heather_reiduff @theBConnolly @elmoray @testobsessed pic.twitter.com/ouI6PCGIHo

— Ash Coleman (she/they) (@AshColeman30) May 24, 2023

Right after the conference ended, the social closure began with food, games and even more conversations. I joined a great dinner group with João Proença, Melissa Eaden, Jenna Charlton, Jenny Bramble, Tara Walton, Vernon Richards and Tristan Lombard.

I’ve been kidnapped for dinner (And dessert)! @lisihocke @melthetechie @TesterFromLeic @jennydoesthings @TristanLombard2 @TheyWrestleTest @jrosaproenca #AgileTDUSA #fieldTrip pic.twitter.com/WvNf7fVhMH

— Tara (she/her) (@TaraWithTiaras) May 25, 2023

Afterwards I ended up in storytelling conversations with Elisabeth Hendrickson, João Proença, Ray Arell and Kirtika Dhathathri. Really loved the chance to talk with Elisabeth once more – I really appreciate her for being so approachable, with people all the time and so authentic – very appreciated and amazing to see.

Post-Conference

After a conference is over means the start of digesting everything. There’s overcoming the post-conference blues of having had to say goodbye again to many dear people, there’s follow-up to process all the gained insights and notes and everything, and there’s rest to catch up with. And some more sightseeing to do to make best use of the efforts of traveling!

Once more I realized how much time and effort the conference follow-up tasks that I do take. This made me think about what I could cut down to make it less burdensome and tedious, and grant more capacity to work on other opportunities. One particular task stood out for me: processing my sketchnotes. Not only do they eat up a lot of energy to take during the talks, I also spend lots of time to take good enough photos of them, then transcribe them to get good enough alt texts for increased accessibility (kudos to Cakelin (Kaitlin) Marquardt for demonstrating how to write alt texts for sketchnotes!), then to create threads with the sessions and alt texts on both Twitter and Mastodon. Phew. Lots of time and energy goes into all that and it’s often exhausting to do after a conference when I am tired anyway. I realized that nowadays sketchnotes don’t save me time anymore, which was the very reason I started sketchnoting in the first place. So I felt maybe it’s time again to for the next experiment to find a more effective way to take and share notes. And guess what? Shortly after considering that, I received abundant positive and grateful feedback on my sketchnotes, including personal messages on how impactful they are and suggestions that I could even make a book out of them. I’m feeling honored! At the same time, I guess I have to really think about how to best move forward from here.

In any case, I was leaving yet another Agile Testing Days USA with a full heart and mind, lots of insights to ponder upon and ideas to try next. Many thanks to organizers and volunteers for creating this space and making this edition run so smooth, and to my fellow speakers and participants for learning so openly together. Now I have a lot to think about.

The post Agile Testing Days USA 2023 – A Lot to Think About appeared first on Association for Software Testing.

So…, I got a bit rusty lately

Fri, 26 May 2023 20:24:55 +0200

I recall discussions in the early software craft days on the mailing lists. One thread, in particular, comes to mind today, that was about whether a good crafter should learn a new programming language every year to learn new coding styles and paradigms, and maybe bring those back to their usual work environment.

Last year, Craig Larman recommended learning the programming language Rust to help, especially with embedded programming. Linus Torvalds also allowed Rust as a third language in the Linux kernel development around the same time. It took me a while to actually try it when I found the perfect for me pet project to dive into.

Over the next couple of blog entries, I want to dive into some of my learnings and approaches. Today, let me give you an introduction to the project I picked for my personal Rust learning curve, where I am, and maybe give you an update now and then about the things I still have open to learn.

Project Introduction

For a while now, I have been playing a bit of Quake Live, a first-person shooter. I was amazed when I found out that there is a server extension that allows you to customize the server experience by writing plugins in Python. minqlx which stands for Mino’s Quake Live eXtension (I think, and found out way too late) is a C-to-Python bridge that preloads (with some Linux LD_ magic) on the server side, and offers such extension possibilities. Since the server behavior has at times been a bit buggy, and I heard lots of things about Rust’s speed and stability, that project came into consideration for me. Maybe I can manage to port all this C stuff over to Rust, and maybe I can extend what’s already in there with some additional functionality. Yeah, I oftentimes consider myself better at taking another one’s initial idea and thinking it further.

Let’s take a look into the different parts and tricks used in minqlx before trying to port some or maybe all of it over to Rust.

Library constructor

minqlx runs as a library pre-loaded before the actual game server. So, the library gets constructed before the game server loads, then finds interesting game functions to hook into and replace the default behavior with additional functionality, like forwarding stuff to the Python world.

In dllmain.c right at the bottom of the file, there is the main entry point to the minqlx library:

__attribute__((constructor))
void EntryPoint(void) {
	if (strcmp(__progname, qzeroded))
		return;

	SearchFunctions();

	// Initialize some key structure pointers before hooking, since we
	// might use some of the functions that could be hooked later to
	// get the pointer, such as SV_SetConfigstring.
#if defined(__x86_64__) || defined(_M_X64)
    // 32-bit pointer. intptr_t added to suppress warning about the casting.
    svs = (serverStatic_t*)(intptr_t)(*(uint32_t*)OFFSET_PP_SVS);
#elif defined(__i386) || defined(_M_IX86)
    svs = *(serverStatic_t**)OFFSET_PP_SVS;
#endif

    // TODO: Write script to automatically set version based on git output
    //       when building and then make it print it here.
    DebugPrint("Shared library loaded!\n");
    HookStatic();
}

There is not much in here. serverStatic_t is a Quake struct where the static contents of the server will be placed in. HookStatic() is the first entry point for the real magic later on. I will spare you the majority of code snippets from here on, as the blog entry would become too long.

Hooks

Quake Live has some static portions, but the majority of the server runs on a virtual machine in memory. minqlx first of all hooks into some static functions, in order to be able to hook into the VM functions later on. While trying to understand the logic in the C-world in order to replicate it in the Rust-world, I learned that you can replace function calls in libraries with your own functions by just replacing the pointer to the function called in the lookup table. (Yeah, it’s more complicated than that, but for brevity, we’ll leave it at this explanation.)

SearchFunctions in the main constructor looks up the addresses of the functions we want to hook into, while HookStatic hooks into the static functions of the server library. Later on, there is a similar approach taken for finding the various VM functions we would be interested in, and hooking into these as well, replacing the original call with our own delegate, i.e. ideally calling the original function alongside with triggering some logic on the python side to have plugins notice things, or react to game events. Let’s see how this is done.

Python embed and Python dispatchers

python_embed.c and python_dispatchers.c are responsible for the majority of the work here. The different replacement functions will translate the C types into suitable Python types and then make them available to customize game logic in the Python plugins.

The various dispatchers consist of a bridge between our hooking functions that we intersected in the game server, and the Python world, while the embed functions provide additional functionality on the Python side via direct Python functions that can be used in your plugins. For example, in python minqlx.player_state(player_id) will return you a Python object reflecting the current state of the player with that id that is derived from the various Quake Live structures and translated in the according Python embed function.

Quake structures

In the source files, one header file holds type definitions of all the different Quake types and enums. That is quake_common.h. The majority of the types in there have probably been reverse-engineered from open source counter-part games, and probably lots of hours of tinkering.

There are more source files in there, but these will be the main focus for my efforts on transforming the C-world of minqlx towards Rust. But hold on, there are a few different goals a Rust implementation needs to serve while I am underway.

Project goals

There are many useful plugins for minqlx out there. I don’t want to have to port all of them over. So, a backward compatibility to minqlx would be ideal, so that plugin authors don’t need to re-write all their useful plugins.

The resulting library should also be comparable in size to the C one. As it stands, the 64-bit release version of minqlx has roughly 120kB in size. We certainly should not waste several megabytes with our version.

Speaking of 64-bits: minqlx also provides a 32-bit product in the compilation process. Yeah, this is an old game. We will try to focus on 64-bits, the standard nowadays, but if we can also provide the ability to run this on a 32-bit machine, that would be ideal.

Oh, and finally, the result should have at least the same stability as the C version, or players and server admins will not want to use it.

Let’s see how far we can take this.

The post So…, I got a bit rusty lately appeared first on Association for Software Testing.

On ‘best’ practices

Thu, 25 May 2023 02:00:00 +0200

This blog post was published earlier in my (now defunct) weekly newsletter on March 28, 2023.

In this blog post, I want to spend a bit of time discussing one of my (apparently many…) pet peeves. This time, it’s one that keeps coming up regularly in emails and LinkedIn DMs I get, but also in my training courses. The discussion often goes something like this:

Them: _“I want to learn how to do well”_ (this is good!)

Me: “What have you been doing in the past, what worked and what didn’t?”

Them: “We’ve tried implementing it before but it got messy” or “We hired some experts to do this before but it got messy” (not uncommon)

Me: “How can I help you to do better?”

Them: _“We need to learn the best practices around “_

Me (actually): “So, I can teach you / tell you about some common practices, but …“

Me (in my head): “Please no, not this again”

Needless to say, I struggle with the term ‘best practice’ and with people asking for them. I’m finding myself becoming the archetypical ‘consultant’ in response, saying ‘it depends’ far more often than I really want to…

Jokes and stereotypes aside, though, one of the things I’ve learned over the years in this business is that there are very few universal truths in testing and automation. Yet that’s what I think something worthy of the term ‘best practice’ should be: something that can be applied to some sort of benefit all the time.

However, for most of the things that people call ‘best practice’, there are always situations where those practices aren’t actually the best. So much of whether or not a certain technique, tool or approach works depends on context that calling it ‘best’ is just a lie.

Sure, there are quite a few things that are generally considered to be useful, e.g., making your tests as small as you need, but not smaller, but these are typically pretty abstract observations and not tangible enough by themselves to be actionable.

An example: the Page Object pattern isn’t a ‘best practice’. It’s a very useful pattern, and it is generally very helpful in separating the ‘what’ from the ‘how’ in your UI automation, but that doesn’t mean that you can always apply it without further thought. Sometimes, a different pattern, like the Screenplay pattern, simply works better. Other times, it might be the other way around.

Now, ‘separating the what from the how’ is already much more universally applicable as a piece of good advice, but that’s an example of a pretty abstract observation, as it doesn’t tell people how to do that exactly. Plus, there might still be situations where you don’t even need to go through the effort of doing so, for example if your automation code is expected to be short-lived only.

So, whenever I get people asking for ‘the best practice’ on something, I typically respond with an explanation that involves talking about context. This involves a lot of follow-up questions, such as

What do you want to achieve?
Who’s going to do the work?
What information are you looking for when you perform tests X, Y or Z?

and much, much more. Sure, that sometimes disappoints people, as we tend to look for bite-sized answers that can be applied everywhere. Unfortunately, that’s not how testing, automation or the world in general works. There are very few universal ‘rights’ or ‘wrongs’, and I typically am very cautious of people saying ‘you should always do this’ or ‘that is the best option out there’.

To wrap things up, here’s a recommendation: instead of asking ‘what’s the best practice on this?’, ask ‘what would work well here?’. I think that’s a much healthier way to approach a problem or challenge.

How about you?

The post On ‘best’ practices appeared first on Association for Software Testing.

The Different Dimensions of Accessibility: Cognitive: Training for Accessibility (Part 6)

Wed, 24 May 2023 20:09:00 +0200

While often overlooked, cognitive disabilities are perhaps one of the most common yet least seen of the disability families we have discussed. Cognitive disabilities are varied and present some challenges that can affect how navigate and interact with online content.

word cloud for cognitive disabilities: words include cognitive, disability, area, attention, experience, fatigue, Hemingway, memory, situation, stress, user

Cognitive disabilities cover a broad range of conditions. Memory, attention, comprehension, and problem-solving are all affected, and for some people, all of the boxes are checked.

Primary Disabilities

Down Syndrome: a genetic condition where people have an extra copy of chromosome 21. Cognitive impairments, delayed development, and distinctive physical features are often seen in this condition. Levels of cognitive impairment can vary from mild to severe.

Dyslexia: a learning disability that can affect reading, spelling, and language comprehension. They may swap letters or read certain characters out of order or need to step back and slowly read the text to process what they are seeing.

Dyspraxia: Also referred to as Developmental Coordination Disorder. While often considered a mobility disability, dyspraxia can also have an effect on the actions of writing and typing and cause stress to cognitive functions as well.

Traumatic Brain Injury: A sudden impact to the head such as a concussion or bone breakage in the skull can cause long-term issues with memory, attention, and problem-solving.

Fetal Alcohol Spectrum Disorders: people exposed to pre-natal alcohol in high amounts during their development in pregnancy can develop a range of disabilities. these can affect memory, attention, impulse control, and social skills.

Secondary/Situational Disabilities

Cognitive disabilities are perhaps one of the areas where situational disabilities may be the most prevalent. There are numerous situations that can put a strain on our mental faculties and can cause us issues that are not necessarily long standing. Many of these share similarities but these are all situations any of us could find ourselves dealing with.

Cognitive Overload: stressed, fatigue, or just having a million things coming at us all at once. These situations can make it more difficult for us to process information and make decisions.

Reduced Attention Span: again, stress and fatigue can contribute to this, as well as side effects of medication or recreational alcohol or drug consumption.

Memory Impairment: there can be a lot of situations that lead to this. Again, stress and fatigue but also just being in an unfamiliar or foreign environment, especially one where the language that is spoken/written is foreign to you.

Design Considerations for Cognitive Disabilities

When we want to address Accessibility and accessibile design for cognitive issues, it’s important to realize that each area is unique, and individuals within these categories can have varying strengths, challenges, and needs. This is definitely the area where one size will not fit all and a lot more judgment calls are required. Still, here are several suggestions that should help considerably and make the experience better for all users.

Avoid Complex Navigation: having multiple layers of nested content or menus of menus is not ideal. It’s easy to lose track of where a user is and then trying to get back to that location could be challenging if not impossible. Try to limit menus to one layer at maximum if possible.

Avoid Overwhelming With Information: A wall of text is not welcoming to anyone and for people with cognitive disabilities it is even more daunting. Try to use space, break up large paragraphs, and aim for a simplicity of message where it makes sense.

Allow for Longer Time Limits: Aim to make it so that timers or time pressures are minimized. Some systems require this but make it so that the value can be adjusted reasonably

Provide Alternative Means for Content Display: Have clear labels and do not assume that users will get by inference what is meant by using a color in isolation or a metaphor that may be well known but some people may not be aware of that meaning. Provide clear labels and alternatives that will provide more context if necessary.

Avoid High Contrast or Flashing Content: this is an example of where a suggestion that works well for one group could be a distraction or a problem for another. High contrast screens that help those with vision issues could be too stressful to read or look at for people with cognitive disabilities. Having the ability to easily adjust the contrast can be a big help. Overly aggressive flashing and strobing is just a bad approach overall, IMO.

Use fonts that are not overly busy or decorative: font choice can have a profound effect o the readability of online text and for people with cognitive issues, overly fancy fonts can be a struggle to read. aim to make sans-serif fonts and typical typefaces a standard or make it easy for these typefaces to be selected.

Write For Everyone (and Learn to Love Hemingway): this is perhaps one of my favorite cognitive tools to use, the Hemingway Editor. I get occasional raised eyebrows when I mention that I think of Hemingway as an Accessibility tool but I really see it as such. Hemingway is designed to help you improve writing from a clarity standpoint and also to help fix/avoid overly complex prose or impenetrable walls of text. You can also set a reading comprehension level and see how well your writing falls into that level (or doesn’t).

As I stated at the beginning, cognitive disabilities are perhaps the most common and also the most neglected because we don’t necessarily “see’ them. Understanding how many there are and how varied they are, we can see a lot of areas that we can do better and can look out for to help make the experience of being online and using digital products better and more usable. Again, it doesn’t take much in this stressful and fast-moving world to feel overwhelmed. These additional Accessibility features might be the ticket to making better interfaces and experiences for all of us.

The post The Different Dimensions of Accessibility: Cognitive: Training for Accessibility (Part 6) appeared first on Association for Software Testing.

Mitigating Risks Through Testing: Understanding and Addressing Different Types of Risks

Tue, 23 May 2023 17:25:18 +0200

Unsplash image credit Loic Leray

In every project, the element of risk is inevitable. Risk is an integral part of business operations, which, when not effectively managed, can lead to significant loss and failure. This is especially pertinent in industries that thrive on innovation, such as technology, where new software and applications are constantly being developed. The role of testing in mitigating these risks is paramount, and an understanding of the different types of risks can help streamline this process.

1. Business Risks

These are risks that can impact the business outcomes. They could be due to market dynamics, changing consumer behavior, regulatory changes, or competition. For example, a software application might face the risk of being outcompeted by a better product in the market.

Testing can help mitigate business risks through methods like Market Testing. By releasing a minimum viable product (MVP) to a select group of consumers, businesses can gauge the response and acceptance of the product in the market. This helps identify potential pitfalls and provides an opportunity to pivot or modify before a full-scale launch.

2. Technical Risks

Technical risks involve problems related to the technology being used in the project, like software bugs, system failures, or hardware issues. For instance, a software application could have a glitch that causes it to crash frequently, affecting user experience and trust.

Technical risks can be mitigated through rigorous testing. There are several types of software testing, such as functional testing, non-functional testing, regression testing, and more. Each is designed to identify different potential problems, from ensuring that the software functions as intended, to confirming that updates don't break existing features.

3. Operational Risks

Operational risks are associated with the day-to-day operational activities of a business. They might include human error, system failures, fraud, or external events affecting business operations.

These can be mitigated through Operational Testing. This is done by simulating various operational scenarios and observing the system’s behavior. This type of testing can include load testing (to see how the system handles high traffic) and disaster recovery testing (to ensure that the system can recover from catastrophic failures).

4. Compliance Risks

Compliance risks stem from the possibility of violating laws and regulations. An example could be a software application that doesn't comply with data protection laws, which could result in hefty fines and reputational damage.

Mitigation of compliance risks can be achieved through Compliance Testing. This involves checking whether the system follows industry-specific standards and legal regulations. For instance, in the case of data privacy, tests would confirm that personal user information is adequately protected and that the system complies with regulations such as GDPR.

5. Reputational Risks

Reputational risks involve potential damage to a company's reputation. In a software context, this could occur if a security flaw leads to a major data breach.

These risks can be mitigated by Security Testing, where testers aim to identify potential vulnerabilities in the system that could be exploited. Penetration testing, for instance, involves attempting to breach the system in the same way a hacker might, to find and fix vulnerabilities before they can be exploited.

6. Product Risks

Product risks arise from potential issues or faults with the product itself. This could range from product failure to meet customer needs, defects in product design or functionality, or even user safety concerns.

Testing is an essential step in mitigating product risks. User Acceptance Testing (UAT) is a common approach here. In UAT, actual users test the product in real-life scenarios to ensure it meets their needs and expectations. This gives an accurate picture of how the product will fare once it’s in the market. Any issues identified during UAT can be addressed before the product is launched, reducing the risk of poor user reviews or returns due to a product that doesn’t satisfy user needs or expectations.

7. Project Risks

Project risks are uncertainties that can impact the timeline, budget, or quality of a project. They can include factors like underestimating resources needed, changes in project scope, team member turnover, or unanticipated technical difficulties.

To mitigate project risks, a common approach is Risk-Based Testing. Here, testing efforts are prioritized based on the severity of the risks involved. For example, features or components of a project that are deemed high risk due to their complexity or the potential impact of their failure are tested thoroughly and early in the project lifecycle. This ensures that the most significant risks are addressed first, helping to keep the project on track and within its budget and timeline constraints.

Proactive Risk Management is another important tool in project risk mitigation. This involves identifying potential risks at the outset of the project, and continually monitoring and managing these risks throughout the project lifecycle. Proactive risk management can help avoid surprises, ensure that contingency plans are in place, and enable the team to respond quickly and effectively if issues do arise.

Understanding and identifying the various types of risks that your project or company may face is the first crucial step in effective risk management. Once these risks are identified, employing appropriate testing methodologies can help mitigate them, ensuring the successful implementation and execution of your project. The key lies in systematic risk identification, prioritization, and applying the right testing technique to counteract each specific risk. Remember, a stitch in time – or a test in time – saves nine!

The post Mitigating Risks Through Testing: Understanding and Addressing Different Types of Risks appeared first on Association for Software Testing.

The Different Dimensions of Accessibility: Mobility: Training for Accessibility (Part 5)

Mon, 22 May 2023 19:10:00 +0200

When we think about accessibility and people with disabilities, mobility is the area that we are most familiar with and the most obvious of disabilities. We also refer to these as physical or motor disabilities. Most of the accessibility options that we see in public and in infrastructure are specifically for mobility disability. This is also the disability family we are most familiar with and can most readily see.

Word cloud related to mobility and motor disabilities.

There are many aspects that create unique challenges when it comes to mobility disability. On one hand, you could have someone with paralysis from the waist down with a spinal injury. this person will need to use a wheelchair to get around but they have full use of their arms, hands, and fingers, as well as eyesight and hearing. In the digital world sense, they are as able-bodied as anyone else. That is not the case for a person with severe arthritis, cerebral palsy, or paralysis that includes their arms or hands. In addition, limb amputation or missing limbs or parts of limbs create challenges in interacting with devices.

Primary/Persistent Mobility Impairments

There are various mobility or motor disabilities that fall under the category of primary or persistent issues.

Spinal Cord Injury: Individuals with spinal cord injuries may experience paralysis or limited mobility in their limbs. This can range from paralysis in their legs only but full control of arms, torso, hands, neck, etc., and then variations that also include fingers, hands, arms, neck, etc.

Cerebral Palsy: Cerebral palsy is a neurological condition that can result in difficulty with moving or coordinating limbs and extremities. Fine motor control or the ability to use fingers independently may be limited or not possible.

Muscular Dystrophy: This is a range of genetic conditions that often result in muscle weakness or limited dexterity due to difficulty in movement. It’s a progressive condition that gets worse over time.

Multiple Sclerosis: This is a disease caused by an attack on the central nervous system, specifically the myelin that coats the nerves. It can impact the brain, spinal cord, and optic nerves. MS is an issue for visual and cognitive disabilities as well as mobility.

Arthritis: This is inflammation and pain in the joints. Holding onto items or typing on individual keys with multiple fingers or moving around and navigating a touch screen can be painful.

Amputation: A loss of limbs due to amputation is a significant issue when it comes to inputting information or navigating on systems, especially those designed around a keyboard and mouse or touch screens.

Tremors/Convulsions: Tremors can be caused by a number of conditions, Parkinson’s Disease being a common and well-known example. This makes fine movements or steady controlled touch or sliding motions challenging.

Secondary/Situational Mobility Impairments

Injuries: fractures to the arm, hand, or fingers can hinder the ability of an individual to perform tasks that they might otherwise be able to were they not injured. The same goes for post-surgical procedures. These are situations that can render our extremities in a limited range of motion or in some cases no motion at all. On the plus side, we may be back to normal in a few weeks or months but during that injury/recovery period, we may have little to no use of our arms, hands, or fingers.

Otherwise Engaged Hands: This may sound silly but numerous situations would fall into the category of secondary or situational “mobility impairment”. Some of these situations could be as temporary as “my hands are full” or “I’m driving a vehicle”. We don’t often think of these as impairments but they are situations where the user may not be able to use their hands or otherwise interact with a product when necessary.

Adapting to Mobility Issues

There are a range of methods to work with that will allow individuals who have mobility issues to better interact with their devices. There are numerous examples of methods and tools that can help with mitigating mobility issues such as:

Alternative Input devices: These can range from joysticks, to blow tubes, to software that tracks eye movement, to capacitance devices that can be held in the mouth, to large button arrays that will allow individuals to more effectively press and order button pushes to enable certain command sequences.

Voice Recognition Software: In certain cases, controlling the system with voice directives will allow hands-free operation. Additionally, screen readers can also be helpful with mobility accessibility.

Ergonomic devices: These can be specialized or split-level keyboards, larger buttons, or alternative layouts. Large trackballs are also commonly used as input devices where using a mouse would not be possible.

Some additional factors worth considering are:

– Make it possible for actions that can be clicked to have large buttons on the screen or to have the ability to access via the keyboard (press Tab to highlight the item and press Enter to perform the desired button click)

– make it possible to allow for multiple keystrokes to be seen as a more complex action or one where the need to hold down multiple keys simultaneously can be performed in another manner.

– use dictation software or other means to allow the user to speak workflows and have the system respond to them.

– provide space on the screen so that form fields can be accessed and do not require the user to have to pinpoint exactly where they need to focus their attention.

– ensure that workflows can be accomplished without the need for a mouse or multiple nested steps.

– make it possible for users to set longer timeouts if they are needed at all as many mobility issues may require a longer time to accomplish the steps necessary.

Individuals with mobility or motor disabilities can have a variety of issues and therefore may need to have a variety of tools to enable them to perform key tasks and interact with online content. It may be a challenge to have a testing situation where all of the possibilities can be tested but there are many ways to simulate these scenarios. It may take some creativity and imagination but I strongly encourage modeling and thinking about how someone would interact with your systems and applications were they unable to have full use of or full control of their hands. Learning to adapt to and putting yourself into these situations will likely provide you with many suggestions you can bring back to the design and code teams to help ake these interactions better for people with mobility issues and by doing that, help make products that are more usable for everyone.

The post The Different Dimensions of Accessibility: Mobility: Training for Accessibility (Part 5) appeared first on Association for Software Testing.

Have a Slice Day!

Mon, 22 May 2023 06:53:00 +0200

I demoed some of my testing to
Maaret Pyhäjärvi the other
day. She asked a bunch of incisive questions, offered some helpful ideas on
framing my results, and then suggested that I should consider speaking and
writing about how I partition the testing space when I work.

She
followed up on Mastodon:

… I learn so much hearing how [James] dissects the exact necessary
information and combines it with an approach that provides better results than
what is usual for testing.

Which, naturally, made me blush, but also reminded me that others have
observed similar things. Back in 2016, during
my presentation at MEWT #5, Iain McCowatt
tweeted this:

[James] wields distinctions like a surgeon wields a scalpel.

So now I am wondering about how I can begin to externalise more of this aspect
of my approach to testing.

I don’t have the answer yet. Today’s task is to collect some data on what I’ve
said in the past. I’m listing it in the order I found it, with some
commentary.

I have written and spoken a lot about how I test already although I would
guess it’s largely in the context of specific projects. Off the top of my
head,
How To Test Anything
is more generic than others but, interestingly it doesn’t talk specifically
about this topic.

However, a term that comes to mind immediately is
factoring. I searched for a definition of it in software testing and
came up with
this post by Rikard Edgren
which also uses the term fractionation after Edward de Bono in
Lateral Thinking.

I have read Lateral Thinking and recall that I
wrote some notes about it. Skimming them now, I see that I didn’t pick fractionation out, but I did
say this:

Over the years I’ve come to value up-front exploration … to build a model of
the problem space before implementation. Frequently, even where the budget for
a project is tiny, I’ll try to isolate some time, however small, for it.

That post also mentions humour and triggers the thought that I mentioned
factoring in my first talk,
Your Testing is a Joke. This is from
the paper that went with the presentation:

… I will often pick out … entities and then look for concepts …
related to them … and then see whether any of those concepts could link to
one another or something related. I call this expansion and it feels like a
close cousin of factoring. But where factoring is a process which seeks to
list the intrinsic dimensions of a thing that may be relevant to the task in
hand, expansion additionally looks for more general properties, instances,
sub-parts, synonyms, antonyms and other related terms.

I had forgotten that I called this expansion at one point.

As I move through this thread of thoughts and think that I might have
something to say about it,
The Dots
popped into my head. It seems like, as so often, I have already said
something about it.

Side note: one of the reasons that I find blogging valuable is that I can
search and see what I think, or thought.

In this case, I still think idea strings are relevant to the topic at hand: an idea leads to an
idea leads to an idea, or more than one idea. The challenge, as in testing, is
to decide which thread to pull, and how far, and when.

In this case I didn’t pursue that line further. I instead searched Hiccupps
for other mentions of factoring and found a post I’d forgotten about,
The Anatomy of a Definition of Testing. If you take a look at it, you can see that I’ve tried to group ideas
together to understand the space I’m looking at and then chosen a piece of it
to attack. That’s an example of exactly the concept we’re talking about.

Tracking back, that post comes from another,
Testing All the Way Down, and Other Directions
where I said:

I am testing the definition of testing in [Explore It!] using my testing
skills to find and interpret evidence, skills such as: reading, re-reading,
skim reading, searching, cataloguing, note-taking, cross-referencing, grouping
related terms, looking for consistency and inconsistency within and outside
the book, comparing to my own intuition, reflecting on the reaction of my
colleagues …, filtering, factoring, staying alert, experimenting, evaluating,
scepticism, critical thinking, lateral thinking, …

That may also be the first post where I talked about the non-linearity
inherent in our work. We rarely discover all that we need to know at the time
we need to know it in the order it makes most sense that allows us to get to
some mythical right answer.

I’ll stop there for now. It’s nearly tea time and I feel like this is a good
start. I have identified some points in the space I’m considering and some material I can review
in more depth if I want it.

To be honest, I like to leave a task at this point
and let my subconscious work on it for a while. What else do I already know
here? What ways can I classify these things? How could I connect these ideas?
How could I rearrange these things to make a contradiction?

I also like that I’ve captured something of the way I work here, so this post is itself an example of
the thing I’m trying to think about. As I write that, a phrase arrives in my fingers: collect, arrange, slice. I don’t know quite what I mean by it yet, but I’ll keep it with the rest for now.
Image: https://flic.kr/p/owvFxg

The post Have a Slice Day! appeared first on Association for Software Testing.

Yes, you can test anywhere, even the gym

Sat, 20 May 2023 20:47:00 +0200

Taking a short break from the Accessibility content to ask some “what if” questions. Note, I’m not doing this to shame anyone or make broader comments, just to show that interesting things can be found everywhere :).

Thankfully, my gym is not very expensive, and during this “semi-enforced woodshedding period” I am getting to experience, I can still go to my local gym and get some much-needed body and mind adjustment. In any event, there’s a lot of equipment in the gym with a mix of free weights, machines, cardio, and other apparatus to take advantage of.

With that, here’s my gym’s kettlebell rack:

My Gym’s kettlebell rack, with medicine balls and slam balls as well

And over here is a bigger apparatus with a number of pulleys and a heavy bag.

Separate equipment rack with pulleys, rope, and heavy bag

What it also has on it are these QR codes.

QR codes on the heavy bag rack

These are used for a variety of functions, including bringing up tracking and exercise routines to use. One of them is for the heavy bag… which makes sense, as there is a heavy bag here.

But here’s something interesting. What other code is here?

Connect Kettlebell QR Code

Huh. A kettlebell code. Okay, so let me scan that and pick up… oh, wait!

Turning from the kettlebell QR code to see the kettlebell rack, on the other side of the gym

That’s quite a distance between the kettlebell code and the actual kettlebells. Is there a problem here?

Again, I’m approaching this as a “what if” and trying to think why this would be arranged this way and it’s not as ridiculous as it looks on the surface. This gym has a sister facility in the East Bay (actually, several) and the one I attend from time to time has both of these pieces of equipment. There, these pieces are facing each other and in that case, having the QR code on the pole and turning around to grab the kettlebell makes perfect sense. However, my resident gym layout doesn’t allow for that, so they had to split these pieces of equipment up.

My point is, there may be perfectly good reasons why something is set up the way it is. Whether or not something is an issue is up to interpretation. I definitely don’t think the distance between the two is a feature. Still, the fix could be easy and inexpensive (heck, next to free). Merely taking a picture of the QR code, printing it, and taping it to the kettlebell rack would be a huge benefit. Ordering a more permanent sticker I could not imagine costing more than a couple of dollars.

So there you go, weird and random quality and testing musings on a Saturday morning. You’re welcome :).

The post Yes, you can test anywhere, even the gym appeared first on Association for Software Testing.

The Different Dimensions of Accessibility: Auditory: Training for Accessibility (Part 4)

Fri, 19 May 2023 00:12:00 +0200

I was hopeful yesterday when I was making my post on the dimensions of accessibility that I’d be able to cover all four of the main areas in one blog post. I could have if I wanted to make a post that was exceptionally long but that’s not my point in doing this. Instead, I realized that it made sense to break the main areas up and look at them independently and consider the realities that each area faces, both in the way of chronic/persistent conditions, as well as those that are transient/situational. If you are enjoying this series, thanks for coming along for the ride, there are lots more coming in the next several days.

Wordcloud for Auditory Accessibility: Keywords include: sound, difficulty, auditory accessibility, hearing, individual, disease, auditory information, person, Ménière’s

Auditory Accessibility

When we are discussing auditory accessibility, we are specifically looking at challenges faced by individuals with hearing impairments. Just as visual impairment is a spectrum, so is auditory impairment. Additionally, there are both chronic/persistent issues that we consider to be primary issues as well as situational challenges that may be transient but certainly matter at that moment.

Chronic Auditory Challenges

Deafness: This term is not as cut and dry as many would believe. Just like blindness does not mean a 100% loss of sight, deafness does not necessarily mean a 100% loss of hearing. The term “deaf” refers to individuals with significant or profound hearing loss. What is significant or profound? A medical Audiologist would consider the severity of hearing loss in decibels (dB). In other words, at what decibel level would a sound have to be for a person to hear it? I am not an audiologist, so do not take what I am saying as gospel but the following values come from the American Speech-Language-Hearing Association (ASHA).

Degree of hearing loss	Hearing loss range (dB HL)
Normal	–10 to 15
Slight	16 to 25
Mild	26 to 40
Moderate	41 to 55
Moderately severe	56 to 70
Severe	71 to 90
Profound	91+
Source: Clark, J. G. (1981). Uses and abuses of hearing loss classification. Asha, 23, 493–500.

To put this into perspective, a person with normal hearing would be able to distinguish sounds within the -10 to 15 dB range, while a person with severe or profound hearing loss would need to have the same sound ramped up to 71dB or above 91dB to hear the same sound. Those people within the severe to the profound range are what we consider to be “deaf”. These are people for whom traditional methods of using devices like hearing aids or cochlear implants will not help.

Hard of Hearing: This is a broader category and may include people on any level of the auditory spectrum. For that matter, hard of hearing can absolutely be situational. People with mild or moderate hearing loss may struggle to understand or interpret sounds in noisy environments or may be limited to the frequencies that they can hear. We can also include conditions such as Tinnitus and Ménière’s Disease. Tinnitus is the perception of sound where there is a ringing, buzzing, or hissing sound in the ears. It can prove to be a distraction when. auditory information is present. Ménière’s disease is a disorder of the inner ear that affects both hearing and balance. People with Ménière’s disease often describe experiencing vertigo, fluctuation of hearing levels, experiencing tinnitus, and a feeling of pressure inside their ears.

Auditory Processing Disorders: these are difficulties in processing and interpreting auditory information by the brain, even when the person experiencing them has normal hearing sensitivity. There are a variety of these disorders. They may include:

Auditory Discrimination Disorder: difficulty in differentiating similar sounds (‘P’, ‘B’, and ‘D’ may sound similar).
Auditory Figure-Ground Discrimination Disorder: difficulty understanding speech/sounds in the presence of background noise or many sources of sound.
Auditory Sequencing Disorder: difficulty understanding and/or recalling the sequence of sounds or words.
Auditory Integration Disorder: difficulty localizing or integrating sounds coming from different directions.
Auditory Closure Disorder: difficulty filling in details of missing or incomplete sound information.
Auditory Memory Disorder: difficulty recalling spoken information or sequences of instructions.
Auditory Attention Disorder: difficulty concentrating on sound/information presentation and keeping that focus for an extended period.

Situational Challenges

While the above examples could be seen as being persistent or chronic issues, any of them are also situational or temporary. More common examples of situational auditory issues would include:

Noisy Environments: Background noise in public spaces, workplaces, or crowded areas. My favorite example of this is trying to take a phone call in the middle of a rock concert. That’s gijg to be an issue for just about everyone, not just hearing-impaired individuals.

Poor Audio Quality: As a podcast producer, I have had occasions where the recordings we had to work with were… not optimal. In some cases, they were downright bad because the technology we had at the time was just not up to the task but we had to run with it anyway.

Multitasking and Distraction: having to divide attention between numerous audio sources.

So that’s a pretty big list of things to have to consider. How do we code and test for accessibility in these situations?

Captions and Transcripts: Provide accurate and synchronized captions or transcripts for audio and video content. Many services do this automatically and the results vary. Still, having a mostly correct transcript is better than not having one at all but if possible, provide a sequenced file that can be displayed in time with the information and that has been proofread and is as close to the audio as possible.

Volume Controls: allowing users to amplify the sound to their specific needs and levels.

Visual Cues and Alerts: Do not rely solely on auditory cues. Create visual options, such as flashing light, varying color or brightness for icons, or allowing for vibration through the mouse or keyboard, if possible.

Clear and Concise Content: where possible, provide simple and clean audio tracks. Avoid the background music if it can be seen as distracting, or allow for an option to separate the vocal track so that it doesn’t compete with other sounds.

Avoid Audio-Only Interactions: Minimize interactions that are specifically sound driven. Make text-based or visual alternatives if possible.

Consider Multimodal Options: incorporate sign language interpreters, transcripts, or visual aids for presentations, conferences, or online events.

Sometimes, addressing auditory accessibility may conflict with other accessibility areas. There is no one-size-fits-all approach here. Changes made for auditory accessibility may not be ideal for visibility, mobility, or cognitive accessibility. This is where we have to make judgment calls and not only focus on compliance from a checklist. Still, by considering and implementing appropriate design and coding, and testing for them, we can ensure individuals with hearing impairments have as much access to auditory information and content as possible.

The post The Different Dimensions of Accessibility: Auditory: Training for Accessibility (Part 4) appeared first on Association for Software Testing.

Effective Technical Investigators

Thu, 18 May 2023 21:50:32 +0200

I was on a panel a number of months back and someone mentioned testers now have to be effective and efficient in their work. I forget the exact context but my first thought was this isn’t new. What might be new is the degree to which your work has exposed you to being an effective technical investigator.

I propose we embrace the idea that testing is an active, skilled technical investigation. Competent testers are investigators—clever, sometimes mischievous researchers—active learners who dig up information about a product or process just as that information is needed.

Cem Kaner in The Ongoing Revolution in Software Testing, 2007

From the moment I read this, I embraced it. Perhaps it’s the image of a Sherlock Holmes-type character trying to crack a case. Or a criminal investigator analyzing computer systems and networks for evidence of wrongdoing. Either way it’s an important concept because it encapsulates the pull and push of investigating things.

Skilled Investigations

Testing is an investigation into technology issues. We combine our knowledge of technology with experimentation, risk analysis, models, tools, critical thinking and many other techniques to understand the state of a product or system under test.

We organize the search, ask hard questions, make observations and look for evidence. We do research into how others might have solved similar problems. We look carefully at the data and parse the results. Finally we report the problems (if there are any) well and harshly enough to convince someone to fix them.

Effective Investigations

Much of our investigation is exploratory. We learn as we go and continually design new tests to reflect our increasing knowledge. Combined with time and complexity restraints, we explore until our results lead us somewhere interesting or to a dead end.

A big challenge is, how to make use of our limited time and resources? It’s a push and pull. We need time to investigate but we also need to be timely in producing insights. This is likely why Kaner later introduced the concept of being effective investigators.

Over the years I’ve developed a quick set of ideas for thinking through effectiveness:

We determine the scope of our investigation. Can we identify the smallest parts of the systems involved to help isolate where to work first? What do we need to investigate and can we break down those into mission statements?
We determine what skills might we need (even if we don't have them or they are currently beyond us).
We apply the appropriate techniques. There are many ways to design, run and interpret tests. Are we running the right ones? Some tests might be re-usable but most won't be, are we keeping the important ones?
We use or build tools as necessary to speed along the discovery process. What are our build systems doing? Can we write a script to filter out data we need to aggregate. Do we have useful automated tests?

Note: This list isn't meant to be exhaustive.

A Useful Concept

This essay isn't about how to be effective. It's about re-introducing and commenting on a valuable concept. Kaner's quote is from 2007 and I likely read it in 2014. It made sense because I was digging up information about a product just as it was needed. I became occupied with being effective and figuring out what it means to design the right kind of tests. Turns out I was being an effective technical investigator.

The post Effective Technical Investigators appeared first on Association for Software Testing.

On (more) meaningful automation

Thu, 18 May 2023 02:00:00 +0200

This blog post was published earlier in my (now defunct) weekly newsletter on March 21, 2023.

In this blog post, I wanted to spend some time diving deeper into a question sent to me by Saifuddin Raj, one of the subscribers to my (now defunct) newsletter. They asked me to explore the concept of ‘meaningful automation’ in a little more detail, and give some pointers on how to make your automation meaningful. I hope this blog post answers that question.

To properly discuss what ‘meaningful’ entails, we first need a definition to work with. I’m not claiming that this is the definitive definition of ‘meaningful automation’, it’s my definition, or at least the one I’ll base my thoughts on in this newsletter. So, let’s start with this:

Meaningful automation is automation that is written to retrieve valuable information about the quality of our product (when we’re writing checks), or to help uncover this information in a more efficient way (when we’re using automation in forms other than writing checks).

Again, it’s probably not perfect as a definition (but when is a definition ever perfect?), but I think it’s a good enough start. Let’s unpack the definition and look at meaningfulness in automation in a little more detail.

When I say that tests should retrieve valuable information, I’m looking to write tests that do two things.

Tests provide me with information about the quality of the product that is important to someone

This follows Jerry Weinberg’s definition of quality being ‘value to some person’. The tests I write should check something that is meaningful and important to someone. This can be the end user (does this widget still work?) or the development team (how are we doing on code quality?), for example.

The test should provide valuable information when it passes, e.g., ‘hey, the properties of our widget that we’re checking haven’t changed since the last commit’, as well as when it fails, e.g., ‘hey, someone introduced some lines of code that do not meet our agreed upon quality standards’.

Tests provide information in a meaningful way

In other words, they present human-readable confirmation in case a test passes, as well as actionable feedback when a test fails. Human-readable confirmation can be as simple as using descriptive test names and descriptions, or as detailed as providing audit logs, including screenshots, for every click and keystroke in a user interface-driven test.

Actionable feedback means that when a test fails, the reason it fails should be immediately clear to a human being, and ideally they should know how to address the issue without having to dig too much deeper. This might mean catching thrown exceptions and providing a human-readable error message instead. This might mean adding screenshots whenever a click or keystroke fails. This might mean lots of other things, but in general, make sure that the information provided by a failing test makes the life of those who read and have to act on it as easy as possible.

But how do we determine whether we need to write a test in the first place? A beautifully written test that provides actionable information that no one really needs is sad, and just a waste of time and resources.

Over the years, I’ve learned to ask myself and others tasked with writing tests and with deciding which tests to write a couple of quick questions that help determine separate the wheat from the chaff. The first question I ask when I need to decide whether to write a test is

“Do we really need the information provided by this test?”

Again, writing tests is only meaningful when the information they provide, on pass and on fail, is valuable to someone. Tests take up time, space and resources, and these are always in limited supply. Choose which tests to write wisely, and please don’t forget to take future maintenance effort into account as well as you can. I know, predicting the future is hard, but be sensible about this.

By the way, if you find yourself, and your team, to answer ‘yes’ to this question too easily, you might want to turn the question around and ask yourself

“What might happen if we did not have the information provided by this test?”

instead. This might help you think even more critically about whether to add a test and the resources they bring with them. Again, take development, execution and maintenance into account. Oh, and if you’re in doubt about whether to add an existing test to a deployment pipeline, here’s a slight variation on the same questions that might be helpful:

“Do we really need the information provided by this test before we deploy?”

and

“What might happen if we did not have the information provided by this test before we deploy?”

So, think hard about the automation that you write, and think harder about whether you need it in the first place. A lot of time and effort has been spent writing, running and maintaining automation that was created ‘just because we could’.

Also, don’t be tricked into writing automation simply because your manager or someone claiming they’ve got more seniority says you should. Sure, they might have a point, but please ask them to explain why they think adding a test, or even an entire category of tests, would be a meaningful thing to do. Their answer to that question should speak volumes about whether they actually have a clue. Don’t be afraid to challenge them.

Finally, don’t be tricked into writing tests simply to attain certain predefined coverage levels, or because your ‘Definition of Done’ claims that a test should be written. These are typically quantitative metrics, which often have little or no relation to the qualitative aspect of a test, which is what you should be much more interested in. They say ‘quality over quantity’ for a reason…

So, to wrap things up, I hope this gives you some insights into how I think about meaningful automation and how to achieve it. I hope the questions and advice I’ve mentioned in here help you take a step, however small it might be, towards more meaningful automation.

The post On (more) meaningful automation appeared first on Association for Software Testing.

The Different Dimensions of Accessibility: Visual : Training for Accessibility (Part 3)

Wed, 17 May 2023 16:57:00 +0200

There are many ways in which we have made great strides in focusing on accessibility. The tools we have at our disposal to both allow for information to be accessible and the tools that are available to help us develop for, test for, and advocate for accessibility are growing all the time. It’s an area that can be as deep and wide as you want to make it.

Word cloud for Visual Accessibility issues. Keywords used: Content, device, eye, images, accessibility, user, visual accessibility, contrast, fact, issue.

One factor that gets overlooked, however, is. that accessibility is not a one size fits all problem. In fact, what may work well as an accessibility fix for one issue may be totally inadequate for another. When we discuss accessibility, we typically group these issues into four main areas: visual, auditory, mobility, and cognitive. We can also consider the fact that there are levels of barriers faced depending on the severity and permanence of a particular disability. These range from total to partial, everyday to temporary, and even situational, where the environment a person is in may benefit from accessibility features that would not be necessary were they not in that particular environment at that time.

Today I’m going to focus on the area that tends to get the most attention, which is visual accessibility.

Visual Accessibility

There is a broad range of visual disabilities and impairments that people deal with. These can range from diminished vision and the way that light hits the eyes. There are a variety of visual challenges people can deal with at varying levels.

Persistent (or Chronic) Issues

At the top end of the spectrum are people who deal with complete or profound blindness. Being blind is not necessarily the total absence of light or color (for some, it is) but there are conditions where the inability to get a clear focus on something is significant enough to be considered total blindness. Less severe but as persistent is color blindness. This is where people have difficulty seeing a specific color or picking different colors from one another. In a world where color combinations are often used to impart meaning, this can lock out certain people or at the least make the intended message ambiguous. Photophobiamakes people sensitive to bright light, so very bright backgrounds or flashing content make it challenging to look at certain pages or apps, much less navigate them.

Less severe are conditions such as near and far-sightedness as well as amblyopia (often called “lazy eye”), strabismus (misalignment of the eyes), and astigmatism (the curvature of the eye is off, resulting in distorted vision). Age also plays a factor in the flexibility of the cornea. It’s why so many people have to shift to using reading glasses when they reach about age 45 (perhaps the largest market for accessibility technology is the market for reading glasses).

Situational Challenges

There are also a variety of situations that people may find themselves in where their vision can be affected temporarily. eye injury, surgery, or everyday eye strain can put an everyday person with normative vision in a situation where they need to have accommodations to see effectively for a time.

Often the lighting can change in which if a device or application cannot adjust the brightness or change the size of fonts, it can become a challenge in low or bright light environments. One example that is still common is the fact that many websites are not scaled or modified to work with phones or smaller devices, making the navigation and reading of these sites difficult if not impossible.

Perhaps the most common aspect of accessibility is the use of screen readers and by saying that an application or a service allows a screen reader to work with it, that makes the system accessible. It’s definitely a good start but there’s much more to visual accessibility than using a screen reader.

Some Basic Accommodations

Alt Text: by including alt text with images, the users of screen readers can hear what the image is displaying and can get a better understanding of what the image is looking to convey (note: descriptive text should explain what the image would be trying to convey to a sighted user).

Color Contrast: By making it possible to either have sufficient contrast o making it possible for the user to easily adjust the contrast, we make it so that backgrounds and foregrounds don’t blend together and make the site unreadable to those who would have trouble differentiating the shades.

Use clear and legible fonts: this is an art but having fonts that are easy to distinguish, contrast strongly between letters, numbers, and symbols, and use space effectively will allow for more people to better ready the content that is displayed.

Responsive Design: this is where we can resize and reorder content depending on the display being used (and specifically using and defining an agent that reflects the screen/device being used. Responsive designs allow for a better layout specific to the device displaying the information and eliminate having to resize and zoom in to key areas.

Text Resizing: this will allow the users to adjust the text size easily, either through browser settings or built-in controls on the pages themselves to allow for resizing of fonts and yet and having those resizes scale to the rest of the page elements.

Screen Reader Adaptability: It’s important to make sure that the content that we want to have people access can be understood clearly and that we don’t burden them with words or content that doesn’t matter to them. Also, most visually impaired users will not be able to rely on a mouse for navigation. Using a keyboard or a device that effectively moves focus to different elements is critical. Also, it is important to limit the number of steps required to perform certain actions unless absolutely necessary.

Forms, Buttons, and Sliders: Many of the “eye candy” elements of web pages and apps are difficult to maneuver through when using only the keyboard or screen reader prompts. Make it possible to allow for these interactions with the least amount of interference or the necessity for detailed shortcut steps where possible.

As you can see, there are a number of avenues to consider and situations to get familiar with when it comes to dealing with visual issues. With time and practice, we can all get a better feel and understanding for these challenges and make it possible that there are ways that people can interact with our content when they can’t see it the same way that we do.

The post The Different Dimensions of Accessibility: Visual : Training for Accessibility (Part 3) appeared first on Association for Software Testing.

A Very Quick and Somewhat Incomplete History of Accessibility: Training for Accessibility: A Series (Part 2)

Wed, 17 May 2023 00:13:00 +0200

As I’ve been thinking about Accessibility and how I might construct training for it, I figured the History of Accessibility, at least as it relates to the United States, would be interesting. As the digital world has been with us since the end of World War II, many of the adaptations that are discussed came about after that, specifically starting with the 1960s.

In the 1960s, researchers began exploring accessibility for people with disabilities. Early efforts focused on creating hardware and software adaptations for individuals with limited mobility or vision.

In 1973, the U.S. passed the Rehabilitation Act and specifically Section 504 was passed. This was an important step in that federally funded programs could not discriminate based on disability. Anyone who knows anything about federal programs gets that they can have a tremendous impact on software development, even back in the 70s. We see this today with the fact that lots of software get purchased by the federal government and they can often demand that certain requirements be met and companies will jump to make sure they are able to get those dollars. In this case, it made for a marketplace where accessibility technology had a chance to make money.

The 1970s and 1980s were a time where Accessibility products and projects made a big jump. IBM introduced ScreenReader in the mid-1970s. While only available for IBM computers, it was still a working example where on-screen text could be reliably converted into recognizable (albeit synthesized) speech. Apple OutSpoken provided a similar product for the Apple II, providing access to text-based applications.

The Refreshable Braille Display was another big jump, allowing users to type in to their computers and then read back the responses or actions from a flat display that would raise and lower small nubs that, when the user passed their fingers over them, would represent braille and allow blind or sight impaired users to “see” through touch, and moving to the next line would refresh all of the characters.

A variety of alternate input devices became commonplace in the 1980s. An example I remember seeing early on in my late teens was a large trackball where the spinning ball was the size of a softball with large buttons. Sip-and-puff switches allowed users the ability to control devices and access switches by inhaling and exhaling.

In addition to the refreshable Braille Display, braille translation software made it possible to print off documents that were translated to braille.

A big step for Accessibility came with the popularization of the World Wide Web and other countries also stepping in and making laws that fought against discrimination of disabilities, as well as providing incentives for developing standards to help people with disabilities get access to information.

In the U.S. the Americans with Disabilities Act (ADA) of 1990 was passed and expanded on the Rehabilititation Act of 1973, though this was more of a physical infrastructure focus. In 1998, Section 504 got some additional strength with the passage of the ADA and Section 508, which specifically dealt with requiring federal agencies to comply with regulations making information and technology more readily available to people with disabilities.

The UK passed the Disability Discrimination Act (DDA) in 1995. The EU likewise took center stage with the Web Accessibility Initiative (WAI) in 1997, sponsored by the World Wide Web Consortium (W3C). Australia introduced the Disability Discrimination Act (DDA) in 1992.

The EU took steps to establish the World Wide Web Consortium (W3C), an international standards organization. It created the Web Content Accessibility Guidelines (WCAG) 1.0 in 1999, providing a framework for creating accessible websites. Today, most people who look at and consider Accessibility look at the WCAG requirements first, because if the WGAG requirements are met, a large percentage of any other country’s Accessibility laws are included there. The WGAG standard continues to be debated and refined, and additional coverage has been added over the years. WCAG 2.1 is the current fully supported version but WCAG 2.2 and later versions have been in the works for quite some time.

As time goes on and interaction with products becomes more defined by portability and touch, more accessibility features are being developed and are coming for mobile devices as well. Speech recognition, which has been an add-on for most home computer systems, is built in with most modern cell phones. Pinch to zoom and resizing are also tools that are accessible if not specifically designed for the purpose. Responsive Design is also a later development that helps considerably with accessibility. I’ve long said that the benefits one gets from examining agents and resizing for the display available get us 80% of the way to more accessible designs, as many of the elements needed to display the content also help with formatting data in a more accessible manner.

This is just the tip of an iceberg that could go on for a. considerable amount but this paints with a broad brush and gives some of the significant developments. I’m sure I missed several. If you feel there are some additional items or milestones I should have included, please let me know :).

The post A Very Quick and Somewhat Incomplete History of Accessibility: Training for Accessibility: A Series (Part 2) appeared first on Association for Software Testing.

Learn how to apply the Holistic Testing Model

Mon, 15 May 2023 23:39:34 +0200

The Holistic Testing Model has been one of my favorite topics to talk and write about since Janet Gregory dreamed it up in 2021. There’s a good reason. People frequently contact me to with a question along these lines: “My team has agreed that we want to take a whole team approach to quality and testing. We’re having trouble figuring out how to put together our testing strategy. Where can we learn good ways to get started?”

The Holistic Testing Model reflects what high-performing teams do to succeed with quality and testing. It’s a thinking tool to visualize testing activities all the way around the infinite software development life cycle. It helps teams release small chunks of value for their customers frequently and safely.

Janet Gregory and I wanted to explain how to apply the Holistic Testing Model to create a testing strategy. We started out to write a white paper about it. We ended up with a mini-book – 37 pages, still a quick read. It’s called Holistic Testing: Weave Quality Into Your Product.

Janet Gregory and I just recorded a new episode of our Donkeys and Dragons video chat about our new mini-book. We talk about what motivated us to write it. We explain that we wanted to show ways to build quality in step by step, layer by layer, stitch by stitch, comprehensively. The book also highlights the important role leadership plays in achieving quality goals. We made this ebook available for free, because we think the model can help so many teams.

It’s a mini-video chat too, just 12 minutes long! Please give it a watch. We hope you’ll read the book and use the Holistic Testing Model to help your team develop an effective strategy for testing and quality.

To download the free mini-book, go to our Agile Testing Fellowship website, scroll down a bit and click the Download button. No email or other information required!

The post Learn how to apply the Holistic Testing Model appeared first on Agile Testing with Lisa Crispin.

The post Learn how to apply the Holistic Testing Model appeared first on Association for Software Testing.

AST Election Nominations are Open!

Sun, 14 May 2023 22:36:21 +0200

The Association for Software Testing is looking for new board members and one of them could be you!

Ooh, I quite fancy that!

Great! To nominate yourself or someone else for the upcoming election you need to know that:

nominees must have been AST Members continuously since 7 August 2022, and
all nominations must be seconded by another member of AST.

We also expect that effective board members:

have a track record of supporting the mission of AST, and
do not own or operate conferences or initiatives that compete with AST programs.

OK, what does being on the board look like?

You’ll be actively engaged in the leadership of the AST including, but not limited to, the following:

participation in monthly video calls
attending 3 board meetings per year – 2 in-person with 1 being at CAST
involvement in day to day operations
involvement in current and future projects

As an organisation we prefer to talk things through respectfully and hope to arrive at consensus on most things. We strive to give opportunities for our board members to follow their interests and energy in ways that benefit AST.

Being on the board is a public service to your profession and your fellow testers. It requires dedication, sacrifice, and commitment.

Sounds good! How to I get nominated?

Get a seconder and add your names to this google form.

Closing date for nominations is 15 June 2023.

And what happens next?

We’ll check your eligibility and be in touch.

There’ll be a candidate questionnaire where you get to make your pitch, and then a round of voting.

Is that all?

Just one more thing: we look forward to receiving your nominations!

The Elections Committee (Louise Perold, Trisha Chetani)

Photo by Glen Carrie on Unsplash

The post AST Election Nominations are Open! appeared first on Association for Software Testing.

Training for Accessibility: What Would I Say and How Would I Say It? A Series (Part 1)

Fri, 12 May 2023 18:37:00 +0200

Without going into details, I had a conversation about the possibility of doing training related to Accessibility and Inclusive Design. I’ve given talks about these topics and I’ve delivered workshops on them as well but I’ve always done so from the perspective of a software tester. Granted, that provides a lot of focus on advocacy but more times than not, it really comes down to “Here’s what Accessibility is, here’s why it’s important, and here is how you can test for it.”

A simple word cloud with some aspects just from this article.

I am realizing that there is a much bigger conversation we could be having here and with many more people. Since I keep saying I want to focus on Accessibility going forward, maybe I should put my money where my mouth is and go on record with some things. Maybe this could become the basis for a book, a training course, or some other set of strategies that we could use and leverage. Maybe this will give me a chance to talk out some ideas while I’m in that in-between phase of being gainfully employed and in what capacity. So if you will indulge me, I’m going to embark on a series of articles surrounding my thoughts on what I would say if I were to be your Accessibility Coach and Trainer.

Ready? Let’s go!

Defining Accessibility

Every first module in training tends to start with a definition, so that we can all be talking from the same place and with the same ideas. To that end, I have historically focused on digital Accessibility but of course true Accessibility goes well beyond the digital realm.

If we are serious about delivering Accessibility, we should start with the premise that Accessibility means we (collectively) work to create a world and an environment where everyone, regardless of their visual, auditory, cognitive, or mobility abilities, can fully participate in and enjoy all aspects of a meaningful and purposeful life. A bit heavy? Maybe but work with me here. Are we looking to say that we wish any less for those of us who are not blessed with the genetic lottery or have through no fault of our own had to deal with a physical or mental impairment? We live in a world where, too often, the normative folks get to have all the perks of their situation, while those who have disabilities often get second-level consideration, f they receive any consideration at all.

Accessibility simply means we need to work to remove barriers that prevent people with disabilities from interacting with and enjoying the opportunities that life offers us. The first step in doing that is understanding that there is a divide between those who are fully able-bodied (or the phrase I like to use, “normative“) and those who need some adaptations to participate at the same levels. What is seen as normative is often the path of least resistance. If any effort due to physical issues has to go into doing something, then that may often be the first line of focus to see what and why that is the case. Also, let’s not kid ourselves, normative is often crowd-sourced and broadly agreed upon. Over time, disabilities get focused on or dismissed because enough people pay attention to them and it becomes an everyday part of life. If the community of Crossfit enthusiasts was to, for example, become the litmus test for the normative, we would see a lot more people suddenly identifying with and feeling as though they were dealing with disabilities. Seems a stretch, right? No pun intended here. My point is that normative is what people agree it is and the broader population agrees with that, the more likely it will just be a standard part of life for everyone. Normative people don’t have to think about if the world is built for them. It just is, by default. For those who have a significant disability (whether it be a chronic and permanent situation or one in which we find ourselves temporarily inhabiting) we start to see the world differently.

Focusing on Accessibility means that we aim to identify barriers that could or would prevent people from accessing and enjoying the experiences and opportunities that others have, and then work to remove or at least mitigate those barriers.

In terms of the physical world, we see accommodations such as ramps leading into buildings that allow wheelchairs or walkers the ability to move effectively. We see and feel braille in items such as check-out kiosks and ATM machines, crossing signals, etc. We see closed captioning for the hearing impaired. All of these are accommodations that we have come to expect and consider part of everyday life but many places and organizations are not set up for this. In many ways, that is understandable. It would be tremendously expensive to retrofit every home to be accessible for everyone but we don’t hesitate to make those accommodations when we are the ones that have to use them ourselves. I had the chance to experience this firsthand back in 2011 and again in 2013 due to a severe tibia break that had me unable to walk for an extended period. My house became a nightmare to navigate. My upstairs was effectively off-limits to me for six weeks. On the occasion I had to go upstairs, I had to literally sit on each stair and hoist myself via stair dips and shuffle to get to each stair. I recognized that, was I to have been in this position for a more permanent reason, the house would have to be retrofitted with a stair lift of some kind, or I’d have to accept the fact that I would lose access to anything happening upstairs in a meaningful way.

Why did I walk you through that? I did that because at times that’s what it takes for us to come to grips with the fact that what works for us one day may not work for us another and at some point what we took for granted as an everyday experience may not be available to us AT ALL at some point. In physical spaces, this can be a real challenge but in digital spaces, we have a lot more flexibility in the nature of how digital products are designed. The barriers to accommodation and accessibility are much lower.

At the digital product level, accessibility means we take into account the various ways in which people can, or can’t interact with devices like computers (and applications, websites, etc.) smartphones, and the media which is produced for each of those. Think of people who are completely blind or have any number of reduced vision issues. Think of those who are deaf or have hearing loss. Think of people who have moderate to profound mobility issues, everything from rheumatoid arthritis to full limb paralysis or absence. Also, there are a variety of cognitive challenges people can face and they can especially become apparent as people age.

One key area people often miss when talking about Accessibility is that it is too often framed around people with chronic or persistent disabilities. Yes, it is absolutely important we consider them in our design choices. It would be in my mind literally immoral not to. However, accessibility often benefits completely normative users in a variety of mundane situations. Have you ever been to a concert and received a phone call? Hard to talk with a sound system at full volume. Also, kind of hard to take that call if you have no real effective means to move to a quieter place. Here’s where the ability of your phone to handle texts is not just a chance of application but it’s also an accessibility hack. “Oh, you can’t hear me? I understand. Then let me text you instead.” Accessibility in action :).

It can be as simple as TikTok including captioning by default or making it so that captioning is available. Many times I have found myself in situations where I am seeing a video but I am not in an environment where I can readily hear what is being said. With captioning, I can work with that and read what the person is saying without having to hear their voice.

Here’s my quick and dirty definition of and the importance of Accessibility, what it is, and why we might want to care about it. Next time, I’ll go into a little more depth on the history of Accessibility, how we got where we are, and how we might go forward from here.

The post Training for Accessibility: What Would I Say and How Would I Say It? A Series (Part 1) appeared first on Association for Software Testing.

Guess what? You’re a developer

Thu, 11 May 2023 02:00:00 +0200

This blog post was published earlier in my (now defunct) weekly newsletter on March 14, 2023.

I’ve said it before, plenty of people have said it before I did, and hopefully plenty of people will keep saying it after me:

“Test automation is software development.”

In and of itself, that’s true, but I feel that without context, it’s also somewhat of an empty statement. It looks good in a Tweet or a LinkedIn post, but that’s about it. Which is true of a lot of social media content in general, but I don’t want this to turn into a rant on social media and the quality, or the total lack of it, of the content on there. I’ll probably get to that another time.

Back to what I do want to talk about today. And that’s the feeling that not a lot of people really dive deeper into the consequences of test automation ‘being software development’. I touched on it a little in earlier blog posts, mainly on why I think it’s a good idea to learn a little more about fundamental programming principles.

Today, I want to explore the pithy statement that is ‘test automation is software development’ a little further, and more specifically, I want to talk about one of its implications. Because, if test automation is software development, it implies that when you’re working on writing test automation, you are a software developer.

Yes, you read that right. You. Are. A. Software. Developer.

Now, before you all go and start updating your LinkedIn profiles, think a little bit about what that means, being a software developer.

It means you probably should be comfortable using a wide range of tools and libraries, and knowing when to apply which one of them. You wouldn’t hire a developer whose suggested solution to all problems was to build yet another Spring microservice, right? Sometimes, you’ll simply need a different tool or library. The same goes for automation: not every problem is best solved with Cypress (or Selenium, or Playwright, before we get into that discussion again…)

It means having working knowledge of other tools that play a role in promoting code from a laptop to production. Version control, CI/CD pipelines and containerization technologies come to mind here. I would be hesitant hiring a developer who wrote the most brilliant code and then responds with a blank stare when you ask them to make that code a working part of a release. The same applies to test automation: no matter how brilliant your tests are, they’re worthless until they’re running on demand, on someone else’s machine. Do you have what it takes to get your tests there?

It means you’ll need to start learning how to do all those other things you expect developers to do. Pair programming. Contribute to design and architecture discussions (including testability and observability, anyone?). Test your code before you commit it. Yes, you read that last one right. Your test code is code, and it should therefore be tested, too. We’re very good at complaining about developers not doing enough testing, but how many of us can honestly say they properly test their own test code?

Oh, and before you start to wonder: all of this applies to those of you using low code tools for their automation purposes, too. Using low code tools doesn’t make automation any less a form of development, you’re just choosing to use yet another abstraction layer. It’s still code. And in the end, it’s all software, and should therefore be treated as such.

And the list goes on. I’ve already briefly mentioned fundamental (object-oriented) programming skills, for example. But it doesn’t stop there, either.

Yes, I know that learning all of the above skills requires a significant investment for those of you looking to break into test automation, or to grow as a test automation engineer. And this all comes next to, not instead of, growing and honing your software testing skills. I never said that this was going to be easy. As a test automation engineer, you’ll (probably forever) be in that universal split between software testing and software development.

And the ‘test automation is software development’ has implications for teams and organizations hiring for test automation engineers as well. Whenever I speak with companies looking to grow their skill set, I ask them if they know what they’re looking for. Typically, they’ll say ‘someone with 3-5 years of experience in Selenium (or Cypress, or Playwright, … damn this gets tiring!) and Java’. What they often don’t realize, is that knowing those tools and languages alone don’t make a good automation engineer. As I’ve tried to stress in this newsletter, it takes a lot of more fundamental development skills, too. Something to think about for those of you trying to hire automation engineers!

So, wrapping this up, if you want to be, become, or hire a valuable and versatile test automation engineer, it might be wise to start thinking of yourself or them as a software developer, too.

As always, I’d love to hear your thoughts.

The post Guess what? You’re a developer appeared first on Association for Software Testing.

I Guess Nothing Lasts Forever: TESTHEAD At Large

Wed, 10 May 2023 00:01:00 +0200

I’ve recently found myself in an interesting position – after working for the same company for the past decade, I’m now looking for a new job. To be clear, this isn’t entirely by choice. However, I have no ill will or hard feelings for the company that has chosen to put me at liberty. They are making choices that make sense for them and I’ve been here before. Granted, it’s been twenty years since I had to deal with this in such a stark way but this brings me to a realization. For the first time in a decade, I am free to explore and consider whatever career I want. I am literally unsupervised. To borrow from the old joke, yeah, it freaks me out a little bit, too, but the possibilities are endless.

My Motto for today. BTW, this shirt with this motto is available at:
https://www.etsy.com/listing/671632845/i-am-currently-unsupervised-i-know-it

I remember talking many times with people and they asked me if I had the chance and the choice to go into exactly the line of work and the area that I wanted to, what would it be? For anyone who has followed this blog for any length of time, that might seem obvious.

I would like to actively explore and advocate for better accessibility and Inclusive Design, whether that be in the digital or the physical world.

What is interesting to me is the fact that when I started working with my previous company, accessibility was the first major project I was responsible for and worked towards. It developed in me a desire for advocacy and speaking about the topic for the better part of a decade. However, due to shifting needs, I haven’t worked with a hands-on active work project around accessibility since 2018. I miss being actively engaged with this at a level beyond speaking about and writing about it.

Over the years, I’ve seen firsthand how important it is to design and build software that is accessible to everyone, regardless of their abilities. I’ve come to realize that accessibility isn’t just something that’s nice to have – it’s a fundamental aspect of good design. It’s good business and frankly, it’s something every one of us will have to come to grips with at some point in some capacity.

Thuis to that end, I have decided to come back to my old friend, TESTHEAD, and recommit to sharing accessibility ideas, approaches, methodologies, and hey, maybe dive deeper into some programming aspects and ways to make accessibility tools that myself and others might want to use.

I’m excited to explore new opportunities, and if a good one comes along that’s not specifically focused on accessibility, I’ll certainly not dismiss it. However, this is a chance to put that very specific feeler out there, to see if someone out there would be interested in a passionate accessibility advocate and having them join their team or even working peripherally with them. Regardless, this blog has been quiet for too long outside of live blogging of conferences. I hope you will join me in my journey to change that.

The post I Guess Nothing Lasts Forever: TESTHEAD At Large appeared first on Association for Software Testing.

Am I Wrong?

Mon, 08 May 2023 12:17:00 +0200

I happened across Exploratory Testing: Why Is It Not Ideal for Agile Projects? by Vitaly Prus this week and I was triggered. But why? I took a few minutes to think that through.

Partly, I guess, I feel directly challenged. I work on an agile project (by the definition in the article) and I would say that I use exclusively exploratory testing. Naturally, I like to think I’m doing a good job. Am I wrong?

After calming down, and re-reading the article a couple of times, I don’t think so. 😸

From the start, even the title makes me tense. The ideal solution is a perfect solution, the best solution. My context-driven instincts are reluctant to accept the premise, and I wonder what the author thinks is an ideal solution for an agile project, or any project.

I notice also that I slid so easily from “an approach is not ideal” into “I am not doing a good job” and, in retrospect, that makes me smile. It doesn’t do any harm to be reminded that your cognitive biases influence your interpretation, even when you take them into account. I’ll christen that Cogstadter’s Law, maybe.

At the end, too, the conclusions set my teeth on edge. This is not how I see my role: “The primary objectives of QA and testing activities in general are to ensure a sound, high-performance software operation that helps businesses attain set goals and for end users to obtain an intuitive, user-friendly IT product.”

Testing, for me, is the pursuit of relevant incongruity. It’s about taking actions that I gauge will obtain the right kind of information at the right kind of cost at the right kind of time for the right kind of people.

Throughout the piece, there appears to be an underlying assumption that exploratory testing is a luxury, an add-on to scripted test cases, a route to creating scripted test cases, a time-filler, an end-user simulation, or simply something that is reached for when circumstances are outside of the ordinary. It asserts that exploratory testing and automation cannot mix, that learning cannot easily be taken outside of exploratory testing, and that it will be inefficient because the risk of repeating work is high.

That is not the exploratory testing I practice.

My team is building a new service. It’s been running with dummy responses for a while as various layers and other dependencies were refined, fleshed out, and connected. Last week, while I was looking at the latest incremental change in that plumbing, I thought that there might be just enough functionality that I could navigate a journey.

So I did a quick proof-of-concept with Postman, took the requests that worked into Python, hacked in some heuristics and hard-coding for pieces that were still not functional, and was able to write a client that could run through a workflow from near the start to near the end.

I added some randomness to my client and, in repeated runs, it was able to find variant paths through the journey.

I added the ability to visualise the paths taken across multiple runs as a state machine. By comparing that to the state machine that defines the service I showed that, even in this early state, the engine is exposing only legal paths.

I learned about some of the rough edges that our API has.

I learned about problems we’re going to have when testing this service for real, and agreed a debug endpoint with the team that will help to resolve some of them.

None of this work was done because of acceptance criteria or existing
test cases, and none of it has produced test cases for someone else to
run next time.

The code I’ve written is pretty scrappy but as far as I’m concerned it’s throwaway stuff. Despite that, it has value. I’m already using it as a workbench to test the stories that have been finished since and perhaps some of the ideas from it will be taken into more formal test code later.

The work was timely for the PO because he’s able to see that we’re on the path he’s expecting. It was appreciated by the team too, because they can see that their work so far works so far and that I care to look at what they do with a sympathetic but sceptical eye, and without reporting every rough edge.

It was useful for me to have some for-real contact with the API. Now I can begin to get a feel for it so that I can make better judgements in future about where there might be risks and how I could investigate them.

That is the exploratory testing I practice: driven by context, and by proportionate effort, using or creating tools and resources to seek relevant value.

I wouldn’t be so vain as to say it’s ideal and I’m not so naive as to say that others wouldn’t do something different and possibly more valuable. But I’d say that about pretty much any approach to testing anything. (Side note: on some days I might try to argue that doing no testing is the same for everyone.)

Although we have pretty divergent perspectives, I’m grateful to Vitaly for reminding me that it’s worth taking a moment to wonder whether I’m wrong.
Image: https://flic.kr/p/oj6yVS

The post Am I Wrong? appeared first on Association for Software Testing.