Do you not want to be a developer instead

This last week I've been doing a little scripting to help me create test data. It's given me a very good reminder of why I'm not a Software Developer.

I can 'code' to a certain extent. I know the fundamentals: I did a computer science degree so I can come up with three languages I know I don't like. But I just don't find a great deal of joy in writing software.

I've not yet finished the tool I'm building and though I enjoy every time bits of it work, I don't find the formation of the solution as satisfying as maybe I should do. The part that's been most interesting so far has been finding that a piece of software I'm testing doesn't do what I assumed it does. In fact it does something weird and that's potentially a problem. Finding that quirk felt rewarding in a way that deciding how to do things in a reusable, maintainable and understandable way just doesn't.

Over my career so far I've been asked the following question at least a dozen times "If you can write code, why not be a Developer rather than a Tester."
I've given plenty of answers in the past but none of them feel as complete as the following painfully extended metaphor.

(Firstly, understand that I know almost nothing about planes, guns, war or medieval carpentry. And one of those things isn't relevant.)

When people ask a Tester whether they want to be a Developer instead they're sometimes making a fundimental mistake. They think I'm a copilate, but I'm not, I'm a gunner. The developer is flying the plane, sure, and I'm along for the ride but I'm not wishing I could fly the plane. I'm shooting down issues and doing something totally different. Sure I could fly the plane if really needs be but it's not what I'm good at, and I don't think I'm ever going to care that much about it. I like the shooting stuff part though. In the same way the pilot could man the guns but they're not going to be as good at it as me and they are always going to wish they were flying instead, because it's a different role.

Without a gunner, you can still get to your endpoint and maybe your copilate will hit a couple of targets due to luck. But what you really need is someone dedicated to it. You want someone who loves the miticulous work of thinking about the best way to hit the target, sitting in the plane whilst it flies, and truly nailing it when the time comes.

The guilt of the stopping plates

I believe that Testers can be involved in the development process in a miriad of ways. But does this cause me to feel guilty sometimes? Wait, this might not make any sense. Let me explain.

Testing for me can be a whole host of tasks. For instance I enjoy doing exploratory testing and I can sometimes find some pleasure in running prescribed regression tests. I love getting involved in the early discussions of a piece of work and I understand the importance of supporting a feature going live. Investigating issues in the software, whether that is preshipping or in live, can also be a great thrill.

I've worked on teams when I've been involved with looking at the monitoring and I understand the benefits of engaging with customer feedback. I've written integration automation tests at multiple different levels of the software stack and I can frequently be found advocating for good build pipelines.

Whilst I am talking about advocating for things, I believe that testability is everyones responsibility because it benefits everyone when it is done well. I've dabbled with contract tests and I think performance testing is important too. Which leads us on to security and privacy, which I wish I spent more time on.

Above I've listed at least 15 separate elements of testing, and I'm sure if I sat for long enough I could come up with 15 more. That is a dangerously large number of plates to keep spinning at once. Try visualising keeping that many plates spinning. See, it's foolish right?

But I think all those things above are really important, I think that if I didn't at least think about them I'd be a bad tester. In fact, it's disingenuous to speak about that as a hypothetical. It's not that I imagine I would consider myself a bad tester if I dropped any of the plates. I know for a fact that whenever I catch myself not having done one of them I do more hand wringing than is sensible. I blame myself and believe I'm terrible at my job if any of those plates stops spinning and hits the floor.
 

What I should do is consider that if I tried to just do those first 15 things every day that would allow for around 30minutes for each task. Clearly it's unreasonable to expect anyone to achieve that level of context switching. I wouldn't expect it of anyone else, but I always expect it of myself.

Maybe in this world where testing means a lot more than running manual test scripts we should sometimes remember that it can't always mean engaging in all of the practices all of the time. It would be more realistic to just keep some of the plates spinning and accept that the others aren't in play. Or delegate them, get a developer to spin some of them most of the time and you just check in every now and again. Or maybe just forgive yourself sometimes for only being human.

Even as I write this I know when that next performance bug or hole in coverage is noticed I'll forget this logical reasoning all over again. But maybe we should be okay with this because the joy of realising testing can add value in more ways has come with the burden of noticing when you're not playing your part in all of those ways.

It is only words. And words are all we have

Words are important right? The words we use to talk about the things we do are important. They have to be because we spend considerable effort debating them. 

This is something I've discussed with colleagues quite a bit over the last couple of months and I think it's interesting. When you're trying to grow a testing team in a culture that doesn't fully understand what testers do, which is probably every culture in all fairness, being able to have an agreed understanding of your purpose and methodologies as a discipline is really useful. Obviously, agreeing on things is easier to do when you're all agreed on your vocabulary. This feels to me to be not all that controversial.

However sometimes certain terms can acquire a bad reputation if a team has had a bad experience of them. I know this first hand from seeing how people who've had unproductive encounters with 'BDD' react when you start using some of the associated words. As a result I worked in a team where we'd frequently have 'Kick-off' meetings for a ticket. This would be a process involving multiple disciplines who would sit down and discuss a ticket before we worked on it, collaboratively adding some Acceptance Criteria  to the ticket, discussing what and how we'd develop and test a feature. There were frequently some front end automation tests created and some regression tests to add to a pack that could be used as a kind of documentation of what the feature now did.

It doesn't take a genius to see that although we had very actively dropped the terms '3 Amigos' and 'Scenarios' we were still doing a large chunk of the core elements of a software development practice which a large section of the team had discarded as a disaster. Had this team salvaged the working parts out of a wreckage of a previous practice left burning in the ditch? Or were they basically repainting the car and driving around in it, strongly proclaiming that their previous vehicle had driven itself into a tree and they had nothing to do with why it had crashed and no interest in fixing it (ignoring the fact that they were still using it?) 

Today I was watching Atypical on Netflix, and at one point the father goes to a support group for parents of kids with autism. He doesn't regularly go to the sessions and therefore gets corrected multiple times for using words in a way the rest of the group sees as unacceptable. They have all obviously agreed on a ubiquitous language over time and the way he was talking about his life and family was deemed to be offensive and lacking enlightenment. Basically he was just trying to help his family and understand his place but he was being judged because he didn't understand how this closed group were using language. The problem he has is that they have grown sensitive to certain words and are unable to see though his phrasing to the intent of what he's saying and so the conversation becomes unproductive.

Is this a problem we have? I certainly know how much the phrase Quality Assurance makes me want to launch into a lecture on how I reject that label. Do we need to be careful about discounting people as 'not our kind of tester' just because they haven't become like linguistical clones of us?

The more I thought about this the more I realised that what's important is to give people the opportunity to explain what they mean. Scratch beneath whatever buzz words people are or aren't using and you may have more meaningful discussions. Yes, it's a bit more work but it's worth it because communication is not aways as universal as we think and not everyone understands the strict lexicon your tightknit group has formed. Whether that is a development team, a testing department in a company or a local test community.

So yes, they are only words. And words are all we have. Use them carefully but forgivingly at they same time. 

How many columns do you need on your scrum board?

How many columns do you need on your scrum board?

I saw this conversation come up on a slack channel discussing Agile Testing and I almost replied, but I realised I was about to rant, so I started putting it into a blog post. Here's the end result. Hold on,  it's predictably ill-informed and rambling.

So... How many columns do you need on your scrum board?

Well, I have worked in a team where we essentially had (TODO, In Progress, Ready for Release, Done). I think in a place where you aren’t in control of releasing whenever you want, that’s the best I would want. I always want to treat (DEV+TEST+CODE Review) as just, ‘Doing the thing.' So that should all be one column, in my opinion, for what it's worth. And it's worth a great deal in this tiny space of the internet remember, because I'm in charge.

So, over time I'd grown to believe that fewer columns meant a team working closer together and that's what I always wanted to strive for. And then I was working with a team where we had (TODO, in progress, Ready to Test and Tested) and  I found myself campaigning for more columns. Which obviously I should hate myself for.

But I had a good reason. The developers would throw everything into ready for test, but the deployment to our test environment required collaboration with other teams and a bucket load of manual steps. As a result, we would have things which had been put into ready for test which would sit there for almost a week before they were even built never mind deployed to a place testers could see them.

It was frequently being stated that we didn’t have enough testers, or that we were being made to work on other things. Basically, according to this point of view Test was proving to be a bottleneck in the process. From my perspective, our main problem was that we couldn't actually get our hands on things to test.

So we introduced discussing separating up the board to distinguish between dev finished and ready to test. Normally I would be arguing for just getting the team to work closer or get everyone in the team understanding what could be done to make it quicker to get things to test after the development was finished.

Sometimes, however, some people in the team are reluctant to change, and your last resort is to get the board to accurately reflect reality. This can help highlight issues. You can strive in general to work a certain way but certain circumstances lead you to want to something totally opposite to that.

Can I tell you that this worked, that the team worked better? Actually, it's difficult to say. The end result wasn't where I learnt my lesson.
Can I tell you, with hindsight, that I support my decision to argue for this change to the board? Yes. Totally.
Did the situation mean that I think that every board should have separate 'ready to deploy to test' and 'ready to test' columns? No, not at all.

So, how many columns do you need on your scrum board?
As few as possible, until you need more than that.

Bug Shaming. Is it helpful and does that matter?

There’s a thing you see on social media sometimes where people call out bugs they’ve found in other people's software. Okay, maybe I see it more because I follow other people in tech but if you’ve read this far so I reckon you move in the right circles to also see this behaviour as well.  I don’t know if this has an accepted name but I’m going to refer to it here as Bug Shaming.  I’ve done it myself in the past and I’m sure I’ll do it again but I think it might be an unpleasant habit. I found myself wondering why people do this, because I think it’s unhealthy.

When people do this is it so the company can fix the bug? If so then really you should try and direct it to the correct account and fill it with enough details for someone to investigate it. If you are a tester, there is no excuse for not treating this like a real bug report. If you truly are trying to help a company improve their software or hardware, you would want to utilise your known skills to increase their understanding of what you’ve found.

Unless you don’t want them to fix it. If you haven’t included the known ‘Support account’ in your public message then maybe the right people won’t see it. Or if you’ve tweeted at the general company when you know that your bug lives in a specific product with it’s own more niche address then maybe you want it to be seen by more people rather than the right people. So if you aren’t trying to get it resolved is your intent to show how clever you are? Is your aim to highlight how you are better at finding the bug than the team who worked on it were? Are you vocalising how appalled you are at the team who allowed the bug to get out in the world? Or are you just showing off? Because I think it might be okay if you are.

Lots of people do this and why shouldn’t testers be allowed to highlight bugs they’ve found in the public? More importantly who do I think I am with the authority to tell people what they are and aren’t permitted to do? Obviously I can’t stop people from doing this, and neither would I want to, remember, I still want to retain the right to show off myself occasionally. There is a type of sentiment which appears in Bug Shaming which I specifically dislike though, phrases such as; ‘Which idiot tested this?’ or ‘Why wasn’t this tested?’

If you’re an old fashioned software developer or a civilian (normal human who lives outside the software industry) then you are probably forgiven for doing this. Like you even care about my forgiveness. However if you’re a professional tester or an enlightened developer, (a test ally if you like), who works in a slightly modern agile environment then I think maybe you should avoid Bug Shaming testers. Be passionate to your fellow tester.

Here’s why I think this. If you are a modern tester then you’ve probably practised risk based testing in the past. You’ll know that you can’t test everything. Or you may work in an environment where the tester is not the sole quality gate. It’s fairly common for a product owner or the team as a whole to prioritise issues found in releases, deciding sometimes that bugs which have been discovered should be permitted to be let loose into the outside world.

I would guess that every agile tester out there has been aware of bugs going live that they really wish could have been fixed but which they have been told aren’t high enough priority.

At which point we should each of us be aware that sometimes bugs go live and it’s not because the tester was an idiot or that it wasn’t tested at all. Maybe the bug was a perceived edge scenario not worth running or the cost of fixing it was deemed too high.

So I suppose what I’m saying is, finding bugs in other people's software is fun but calling out the testers is mean. Let’s not be a mean community, let’s support each other. The people we should really hate are the developers who put that bug in there to start off with, right? I am of course joking with my last remark. Oh, you know what, live your own lives and do whatever you want, it’s just my opinion.

A Tale of Two Products

The following story is not wholly based on any singular experience but rather a conflation of multiple real situations in order to create a compelling enough story to discuss. (Any resemblance to real life people or products is largely coincidental.)

Premise

Product A has a pretty strong team who work on it. Everyone on the team has been specifically recruited because they’re good at the technologies it uses. They are all experienced in the tech stack and though some of the devs would like to rewrite sections of it they are mostly bought into it’s worth. It is the primary focus for most of the Developers, Business Analysts and Testers in the team and they commit as much time to it as possible. The more experienced members of the team are passionate in improving the quality of the code in Product A, taking every opportunity to get newer members of the team involved in their endeavor.

Product B is ostensibly owned by the same team as Product A. None of the strong developers work on it and it is primarily coded by those with less programming experience. It is written in a very different tech stack to that of Product A and as such only a small portion of the team are interested in understanding the languages and technologies used. At least one of the developers in the team refuses to look at the code at all, arguing that the amount of context switching required is unreasonable. It is difficult to improve the code because the stronger developers are reluctant to get involved in it.

The Product Owner is in constant communication with stakeholders and works closely with Business Analysts, Developers and Testers to shape Product A and set a strong roadmap. Changes are undertaken with as much understanding as possible of the scope and the dependencies involved. If bugs arrive they are prioritised to get them fixed as quickly as possible. The Product owner is occasionally frustrated at having to spend time on refactoring Product A but understands it is the cost of doing business.

It is difficult to get the team’s product owner interested in Product B. He has been told that it belongs to him but he resents spending money on something that doesn’t seem to help him achieve any of the wider organizational goals being set for him by the management team. Product B is intrinsically linked with Product A and almost all of the changes that come in are caused by that of Product A. The Product Owner gets frustrated if people discuss bugs in Product B and frequently brings up the possibility of scrapping it altogether arguing that his team would have more time to spend on Product A without Product B. As Product A grows, Product B becomes much bigger too and is frequently accused of being unwieldly and difficult to run. It is rarely discussed if Product B is actually helping to improve Product A, which should be the intention.

Everyone understands what Product A does and why. It was largely designed by a couple of developers who had built things of a similar size in the past and even though one of them has now left the team people agree that some of the foundations seem to work. Only one or two people understand how Product B works and in fact it was largely designed by a developer who hasn’t built a piece of software this large before. There is a similar Product (Product X) which was written by a developer who has since left the team and so it has been decommissioned. It performed similar functions to Product B, but no one understand how it worked and when there were problems in it is was decided to simply replace it. This took a great deal of time and effort and delayed the development of Product A.

A lot of time and effort goes in to understanding how successful Product A is proving to be and a great deal is invested in coming up with new ways to improve it. It’s actually quite difficult to measure what success means for Product B and occasionally some of the Developers who never touch Product B will get frustrated with its existence and the fact that they need to consider it when they make changes.

Conclusion 

Is it any surprise that Product B is a failure? The game has been rigged against it. I’m betting that it was obvious within the first couple of paragraphs that Product B is an automated test suite.

I think sometimes people don’t treat their automation tests like their other software, but if you look at it as just a different product it all becomes almost absurd how we act towards it. It is sometimes a product without a clear roadmap or obvious metrics. Dependant on another product, with frequently only testers working on it who let's face it,  are rarely hired for their software development skills alone. It is rather more likely that they’re being expected to be good at a whole host of other things at the same time.

If we accept just the premise that Product B is worthwhile what could we do to try and solve this problem?

·      Try and get all of the team to love both products.

·      Find out if Product B is actually providing benefit to Product A and in fact what benefit would be worthwhile.

·      Discuss what would make Product B more tolerable for the Developers to work on, as it’s currently only the testers who work on it.

o   Maybe building Product B in the same languages as Product A as possible to facilitate reduce context switching.

o   It could even be an idea to try the risky approach of allowing Product B to incorporate shiny new technologies that get the strong developers interested.

·      Try and identify what success means for Product B and always optimize for success.

·      Try and get everyone in the team to understand and agree on what Product B does and how it can improve Product A.

·      Maybe limit the scope of Product B and accept that it can’t do everything. This may help it to be considered alongside Product A when changes are suggested so the Product Owner grows to understand that it is part and parcel of making changes. In time you may even get the Product Owner to appreciate the benefits it gives him to Product A.

30 Days of Accessibility testing | DAY NINE

https://dojo.ministryoftesting.com/lessons/30-days-of-accessibility-testing

1. Disable images in the browser. Can you understand the page?

This one's hardly gonna be a challenge at all. Or at least that's what I thought to myself. Except it was harder than it first appeared. The first thing that I decided to  was look at the above link without the images on and see how that appeared. Actually did pretty well.

The next thing I decided to do was look at Gmail without images.  This was not so ideal. So it turns out that apparently Gmail uses images for all it's labels.  Naughty Gmail. Although just navigating around my inbox was not as bad as if I tried to access Drive or my account or go back to the Google homepage because apparently all of those links are, you guessed it, images which don't seem to really have alternative text so you get a little bit lost if you turn the images off  period. You pretty much don’t get warned what you’ve lost.

OK let’s test  Google a little bit more, how  does Blogger cope? Actually the answer to this seems to be that it does ok.  Then just to make things more exciting I decided to type this up as I went along.  Of course I'm yet again trying to do one of these one-handed though so I decided to go all out accessibility and try and use speech to text. Blogger doesn't seem to support  speech to text and to be honest I'm not that surprised or really that disappointed. I decided to go a bit hacky and type in Google Docs and copy and paste.  Google Docs does  have speech to text, but saying his perfect would maybe be over stating it.  I have ended up going through and editing this some typing these are acting it as I go along so you might find that there's a couple of things that don't make perfect sense that all adds to the accessibility experience and hopefully you'll be able to identify which things are poor accessibility tools which things are we just not being able to use computers properly. Whilst using the speech to text there were a couple of  I wasn't sure how to do so I used the question mark button brought up to help. That was great until I tried to get rid of it . Turns out the X button is an image so I couldn't find it .A little bit of clicking about the area I guessed it would be in solved the problem but it was an interesting unexpected issue which really made things harder.

So let's do a couple of other popular websites with the images turned off and see how they fare.

First stop the BBC homepage. Actually not too bad. With the exception of the BBC blocks not being visible or having alternative text, at a rough glance it feels as if you could probably navigate this page quite happily.

Ok next up was to go look at Facebook and see how that survived without images. I didn't really imagine it was going to be particularly well.  So there's no profile pictures and any posts that are simply images leave a bit to be desired. But the main problem really was that without the images I didn't really  see the point. It did’t fall over in a heap though.

One last stop at social media to post to Twitter. Actually  coped quite well without images. I didn't do  an awful lot of with it but it did seem to cook quite well. I suppose this is because it is largely text. I would imagine it would have been even better in the old days before the extended support for anything other than a micro blog post.

So to summarise it's been an interesting little exercise.  It's definitely something that's worth doing on websites I’m working on as it really highlights areas where we may have dropped the ball.  I found it worthwhile and I suppose that's the most important thing.

30 Days of Accessiblity Testing | DAY SEVEN

https://dojo.ministryoftesting.com/lessons/30-days-of-accessibility-testing

Day 7. Unplug Your Mouse, leave your touchpad alone and navigate using the keyboard.

So, I did that, and then I started trying to write this blog.
This first thing I realised was that I couldn't remember how to toggle between tabs in chrome.
Then I went into my blog editing homepage and found the link for ministryoftesting30days challenge, and that was all pretty easy.
Starting a new post and pasting into it was also quite easy.
I normally change the font to Arial. I cannot figure out at all how to get focus onto the edit controls so that won't happen today.

I decided at this point to do another task. Also by this point I'm doing everything with only my right hand as I was also holding a reluctantly sleeping baby.

I decided to copy four folders of photos on a windows to an external hard drive and then onto my mac. The windows part went fine but ejecting was tricky. I just unsafely unplugged like the dangerous rebel I am in the end.

Copying the photos from external hard drive to my  mac was harder. Finder was VERY hard without a mouse. I had to select using the trackpoint. I tried about 10 key combinations before I gave in but in the end enough was enough.
Moving the images to where I wanted was obviously not going to happen easily.

Starting spotify was a problem because my virus checker always pops up, which is normally fine but can't be closed without mouse intervention. Or at least not in any obvious way.

Okay, trying to navigate spotify app on my laptop with only a keyboard made me almost lose my sh*t. I gave up. I used the trackpad. I know, I'm the worst.

SUMMARY (not a heading because I CAN'T GET TO THE SODDING OPTION WITHOUT A TRACKPAD)

I thought this was going to be easier than it was. I thought I used my keyboard a great deal but clearly not. This was a seriously frustrating.

30 days of Accessibility testing | DAY SIX

Day 6. Learn about assistive technologies, and share one you liked (hardware).

https://dojo.ministryoftesting.com/lessons/30-days-of-accessibility-testing

Okay, so in my Day 4 post I got excited about refreshable braille displays and mistakenly thought I'd never heard of them before. Of course that isn't true, Matt Murdock uses one on the Netflix series Daredevil and therefore as my wife pointed out, not only had I heard of one, I'd seen one in use. Stupid Dave.

Okay, so back on track for today, I found a couple of resources 
http://abilitynet.wikifoundry.com/page/Head+Tracking+and+Pointing
https://en.wikipedia.org/wiki/Assistive_technology
https://www.atia.org/at-resources/what-is-at/

I decided that instead of writing about one I'd try and just briefly list an A-Z of assisted Technologies. Some of these are hardware, some are software, some are not necessarily Web related or particularly technology related but I thought it would be fun. And I really struggled for some letters so please just forgive me, I stretched a little. Also, I threw in the fun game of missing two letters out because I was just done trying to crowbar anymore in. 

A Standing desk
Braille watches (seriously look these up, they're really cool. I have to admit I looked into them because of this blog post http://www.theothermurdockpapers.com/2009/09/assistive-technology-in-daredevil/) 
Coloured overlays (for dyslexia primarily)
Dvorak Keyboard
Enlarging (or Enbiggening as someone I used to work with refered to it as, I wish that was a word) ability on software
FM listening systems 
Gel pads (for mice and keyboards)
Head trackers and pointers
Joysticks
Keyboards of all shapes and sizes 
Left handed mice (I understand that lefhandedness isn't a disability)
Magnifying glasses
Note taking software
Other assistive technologies such as speech to text software 

Puff and sip. (or as it's normally known, Sip and Puff) 
Refreshable braille display
Screen Readers
Tongue control
Unusually big screens 
Voice recognition software 
Workstations designed for standing up.
Xtra buttons on mice for extra functionality 
You've heard of speech recognition right?
Zooming in functionality

30 Days of Accessibility testing | DAY FIVE

https://dojo.ministryoftesting.com/lessons/30-days-of-accessibility-testing

Day 5. Read the 12 guidelines of WCAG 2.0. Write a short post on one of them.

https://www.w3.org/TR/WCAG20/

I struggled for a while to find specifically which 12 were being referred to. That may be because the above linked page seems to have been written specifically to be as in coherent to follow as possible (this could be sleep tiredness kicking in.) So I think I've clocked them from the contents and relisted them here for future use.

1. Perceivable : Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language
2. Perceivable: Provide alternatives for time-based media.
3. Perceivable: Create content that can be presented in different ways (for example simpler layout) without losing information or structure.
4. Perceivable: Make it easier for users to see and hear content including separating foreground from background.
5. Operable: Make all functionality available from a keyboard. 
6. Operable:Provide users enough time to read and use content.
7. Operable: Do not design content in a way that is known to cause seizures.
8. Operable: Provide ways to help users navigate, find content, and determine where they are.
9. Understandable: Make text content readable and understandable.
10. Understandable: Make Web pages appear and operate in predictable ways.
11. Understandable: Help users avoid and correct mistakes.
12. Robust: Maximize compatibility with current and future user agents, including assistive technologies.

Now I have already talkeed about this but I'm a big 'Keyboard' advocate, I find it weird that peoople make things that cannot be worked only by the keyboard. This especially true of very specific use software. I think that by taking this into consideration you're designing and getting your solution working for a whole host of people: power users, blind people, people with mobility issues. There are such a vast number of reasons why mouse and tracker ball usage can exclude people that I always think this seems like a no brainer, however it's not always easy to convince a team.

30 Days of Accessibility testing | DAY FOUR

Okay, we're on Day Four,
https://dojo.ministryoftesting.com/lessons/30-days-of-accessibility-testing

4.Research the benefits of inclusive design.

Inclusive design. Okay, I have no idea what that is, so I did some reading and watched a couple of videos. I have to be honest, I only spent an hour or so because I wasn't blessed with abundance of time to spend on this today.
So I looked at a couple of pages. Some of which I really just skim read.
https://www.w3.org/WAI/users/
http://www.inclusivedesigntoolkit.com/whatis/whatis.html

On the second link I got some good take-away points. So firstly, according to a Microsoft survey (admittedly in 2003) only 21% of people have 'No disability', and it's more of a scale rather than a simple black and white. Okay, that has me thinking a bit more about how really, is accessibility really just usability with a wider understanding that people are all different. Also it makes me ask questions like, how much do I trust this data considering it's over ten years old, doesn't tell me how many people it's sampling or really any thing at all about their sampling and is Microsoft, who I obviously inherently distrust.

I had to parse the section on 'Universal design' a couple of times, and then I realised it states at the end, that due to the nature of the web, Universal Design and Inclusive design are effectively the same in that situation.

I wonder how as a tester I can use inclusive design, especially considering the things I currently work on don't really have any UX design. Although, then it got me thinking that maybe it's my job to ask the kinds of questions relevant to inclusive design, because there's no-one else to ask them? Hmm, interesting.

Also I watched this

Inclusive design and testing: Making your app accessible - Google I/O 2016

https://youtu.be/SOZwfQO4rVM
This may be trying to sell a google product but some of the things they talk about are quite interesting.

Also as part of watching this video I got distracted when I learnt about refresh-able braille displays, which I didn't even know were a thing. Although at way over 2 thousand dollars a piece, it's clear why they aren't a thing tonnes of people are designing for yet. https://youtu.be/IIQNhFpbbEI

So maybe in summary I was a bit unfocussed today and may have not definitely achieved the goal today that well. However I believe I learnt some new things about accessibility, and I had fun doing it and really that's the only thing that matters in the end.