It's been interesting to see how we have seen the world adapt over the past thirty years that I have been in the software testing industry. In some ways, it's a very different world and yet at the same time, not much has changed. When I came into the testing world, there was a need for understanding requirements, there was a need to know how to test and there was a need to execute a certain number of tests, manually if we must but automated would be spectacular.
What I just described was 1991. Does it really sound that much different than 2020? Let's take a look at some other factors. Who is doing the work? For me, I remember thinking about this as I was working for Cisco Systems and I was hearing how few women or PoC were actively involved in tech. I frequently wondered what they were talking about as I was literally surrounded by women as peers and women as managers, as well as a rather diverse team as related to cultural and ethnic background. It would take me several years and watch the company grow to have that lens be changed and see the point. Where am I going with this? It's sometimes hard to see the issues and challenges we face when we think that the world being described doesn't match our experiences. I made the mistake of thinking the early days of Cisco Systems were indicative of the world of tech as a whole.
Again, interesting but Michael, what are you going on about? Well, it's key to understanding Jack and Ying Ki's talk (and Jack is the one delivering it but since Ying Ki helped write the paper, I'm giving him credit, too ;) ). In any event, the point is that we see the world through our lens, and that lens may be accurate or not but we won't know it is accurate if we don't have other points of reference. With this idea, we should also be asking "what does quality actually mean?" It means whatever the team at large decides it means, and then we radiate out from there. However, we are missing a bit of the point that quality is going to be skewed if we don't seek to pay attention to what others think that quality is.
Ha! Communities of meaning using Accessibility. We're in my court now (LOL!). Well, not really but it is interesting to see what examples for accessibility are used and what actually counts. Jack is correct that accessibility often looks at disabilities as a monolith when in reality, there are a variety of unique disabilities that require very different methods of accommodation. I'm all too familiar with the approach of "load up a screen reader, walk the application and call it a day". Yes, I've been there and so have a lot of others. The fact is, that approach leaves a *LOT* of things out of the mix or even giving consideration. Sight issues are not the same as hearing issues, and they have little to do with mobility issues, and those have little to do with cognitive issues, and on and on.
So Standards are often included in these quality questions. Standards can often be helpful but standards also tend to take a prescribed way to identify what makes for software quality. yet the question remains, does a standard take into account cultural differences of other approaches? Jack is arguing no and I'd say I agree with him. Jack just said that Agile Software Development is pretty much Anglo-centric. Yang Ki refutes that the way that agile software development works in the USA would not be culturally acceptable in Honk Kong, for example. The idea that individual engineers would be able to express their opinions or desires about products and openly question management. It also shows that in other cultures the Agile principles can be subverted and exploited.
Again, the question we want to consider is "how does culture affect quality?" The answer is there is really no monoculture in all of this, there is a mixture of cultures that blend together and often help define these communities of meaning. How this is actually accomplished may well be a long and involved process but it is interesting to consider other communities of meaning to address these issues.
No comments:
Post a Comment