Forem: Ania Gajecka

Please, make your product accessible for everyone

Ania Gajecka — Thu, 20 May 2021 21:57:20 +0000

Did you know that people with some kind of disability constitute about 1 billion of the population? Today is the Global Accessibility Awareness Day (GAAD) and I would like to share some useful resources with you.

According to Directive (EU) 2016/2102 of the European Parliament accessibility

should be understood as principles and techniques to be observed when designing, constructing, maintaining, and updating websites and mobile applications in order to make them more accessible to users, in particular persons with disabilities.

You, as a software developer, may come across many disabilities, when thinking about potential users of your product:

vision impairment
deaf or hard of hearing
autism spectrum disorder
physical disability
cognitive impairment
mental health conditions
intellectual disability or acquired brain injury

This year on Polish track of A4Q World Congress Radek Smilgin, in his presentation Accessibility for all platforms and all people, mentioned that everybody was / is / will be "disabled". He evokes the example of an aging society - in 20 or 30 years our eyesight will deteriorate, our motor skills will no longer be fully functional, etc. If we all accept that at some point in our lives we will be disabled, our perception on the matter changes. Disability is no longer personal health condition, but mismatched human interaction with their environment or various interfaces. Designing our products for inclusivity not only opens up to more people with a wider range of abilities. It also means more potential clients for the product and in effect bigger return of investments.

After going through ischemic stroke of the left side of my brain in 2015, which caused temporary loss of speech and the paralysis of the right side of my body, I am one of these 1 billion people. I was 27 then, so thanks to the relatively young age, I mostly recovered. My motor skills however worsen in compare to times before-the-stroke, e.g. using a computer mouse with my right hand became very frustrating, with frequent tremors of my fingers, causing many unnecessary clicks. I learned to operate the mouse (or the touchpad in my laptop) with my left hand. Also, the Tab key was my new best friend. It's sad, that before the time of my own incapacity, I did not pay that much attention to accessibility.

But what can you do to include everyone in your application? According to Microsoft inclusive design principles you have to:

Recognize exclusion
Solve for one, extend to many
Learn from diversity

If you would like to learn more about the accessibility, here are some additional resources:

Accessibility for beginners with Elizabeth Fiennes (you will have to create a free account on Ministry of Testing, worth it!)
Web Content Accessibility Guidelines, WCAG 2.1
POURing Over Your Website: An Introduction to Digital Accessibility a TED Talk by Ashleigh Lodge at TEDxWinnipeg
a11y project checklist that will help improve the experience for everyone who uses your site
guidelines that can be applied to non-web Information and Communications Technologies (ICT) specifically to non-web documents and software

The paralysing fear of failure, part I

Ania Gajecka — Sun, 16 May 2021 21:55:07 +0000

I've been a manual tester for over 6 years now. I've been thinking to learn how to program since 2018. To take the next step in my testing career.

Disclaimer: I don't believe that every tester must know how to code to advance in their career. Testing itself covers so many areas that I don't think knowing how to program is the only way. It is just the chosen way for me.

As a graduate of language & literature studies, not knowing where to start learning, I first decided to ask for an advice on a Facebook group - Programuj, dziewczyno (Polish is my super power). Back in 2018, I only had an experience in testing desktop applications that was written in the C#/ .NET framework. I even started reading C# for Dummies book, but I gave up on it rather quickly.
However, almost every job advertisement for a software tester position stated "knowledge of Selenium framework".
I was in between jobs, studying for the ISTQB Foundation Level certificate, which for many companies in Belgium is a must-have; especially for a foreigner, that is not fluent in any of the three official languages.

The girls from the group said to try Python, because it's a beginner-friendly language.

But where to start? I was being overwhelmed by the information you can find on the Internet. I was watching many videos and reading many articles titled "How to learn how to code" etc.
I was used to a structure of a school or university course, where you start from some piece of information, and you build your knowledge on top of it, as you go. In the end, I felt swamped by the information overload.

In the meantime, I passed the ISTQB FL exam in Paris (that's a story for another blog post 😅) and found my current job in a governmental institution, where I am testing web applications.

In 2019, during my daily 2+2 hours long train trips to Brussels from West Flanders, I was surfing the Internet. I came upon a book, one of the Head First series: Learn to Code: A Learner's Guide to Coding and Computational Thinking by Eric Freeman. The book used Python 3 to introduce certain concepts and said that the activities are NOT optional - they’re part of the core content of the book.
I remember enjoyment in writing in IDLE Rock, paper, scissors game, and later, Rock, paper, scissors, lizard, Spock, inspired by The Big Bang Theory. And then I got stuck somewhere on the for / while loops, then on the functions... all the time I was thinking that I just must be not smart enough, if I don't understand such simple concepts.

In April, I got accepted for a free Selenium 2-day workshop, organized by Geek Girls Carrots in Wrocław, Poland. This was my first encounter with Java.

Then, some months later, on the way home, my work laptop was stolen and with it, my miniscule coding progress. I was totally discouraged - I wish I wasn't scared of command prompt and knew how version control worked back then...

End of part I.

All possible loopholes

Ania Gajecka — Tue, 04 May 2021 20:42:31 +0000

It is safe to say, that I don't know much about network security, nor security testing. With computers and phones connected to the Internet, becoming crucial parts of our life, now it would be hard to imagine inability to display or log in to the chosen website.

Belnet, one of the operators of internet traffic in Belgium has fallen victim to a cyber-attack. People attempting to visit websites on the Belnet network, including government and police services, universities and vaccinations centres, were being met with error messages due to a DDoS attack. As I happen to live in Belgium, and work for governmental institution as a software tester, I was one of the victims as well... which basically meant some extra frustration of something not working for unknown reason (a well-known feeling to a tester) and extra-long break around lunch.

A DDoS, denial-of-service attack, is a cyber-attack in which the wrong-doer seeks to make a machine or network resource unavailable to its destined users. How? By briefly or continually disrupting services of a host connected to the Internet. Denial of service typically occurs when multiple systems flood the bandwidth or resources of a targeted system with useless requests causing websites to not load.

In a distributed DDoS attack, the incoming traffic flooding the victim originates from many different sources. This effectively makes it impossible to stop the attack simply by blocking a single source.¹ Dirk Haex, a co-general director of Belnet, said:

It was a cat-and-mouse game all afternoon with the perpetrators of this gigantic attack. They are constantly changing their tactics. Our network is still under attack, but since 6 pm. The attack seems to be diminishing. The Belnet teams are doing everything in their power to fully restore connectivity for Belnet customers as soon as possible and are continuing to monitor the situation closely.²

Altogether, about two hundred institutions would have been affected. No data has been stolen (or so they say).

The main goal of security testing is to identify all possible loopholes and weaknesses of the software system. Uncovered, they might result in a loss of data, earnings or reputation. Maybe my next ISTQB exam should be the one for Security Tester?

¹DDoS, denial-of-service attack
²VRT news

Exploring possibilities?

Ania Gajecka — Tue, 27 Apr 2021 12:28:38 +0000

The Agile manifesto states in one of its points: working software over comprehensive documentation. Do you know those companies that claim to be Agile, but in reality that usually just means no documentation?

I once had the pleasure of working in such a company - there was either no written specification of the developed product or the documents were not updated for a year or two. It sucked, especially for the tester, who came from a waterfall project, where everything was tick-tick like a Swiss watch, especially documentation-wise.

I had to resort to troubling programmers (I regret nothing) and to my testing skills. I was travelling through an unfamiliar area (aka software under test) in order to learn about it. I mostly used exploratory testing. As the ISTQB glossary defines it, it is an informal test design technique where the tester actively controls the design of the tests as those tests are performed and uses information gained while testing to design new and better tests.

Yesterday kicked off the Exploratory Testing Week, hosted by Ministry of Testing (my favourite testing community). It began with 99-minute workshop session titled Learn How to Test Before a Line of Code Has Been Written by Dan Ashby.

One of the exercises presented by Dan was to share ideas of the products and let the group work on testing approaches for 5 minutes, on Miro board.
Let's visit one of the ideas:

Context:
We are employees at Amazon, and are working on the Echo¹ product. The idea is for a cool new feature for the Echo to recognize a child's voice and restrict content to be appropriate for the age of the child. It would prevent the child from purchasing things; it would prevent any explicit content or certain apps from loading. It would also require a child to say please and thank you to help teach good manners.

I think my 7-year old nephew would be all over that device. But, seeing as I'm originally from a non-English speaking country, Echo can be inaccessible to some children. Even the variety of English speakers' accents would cause potential problem.
Testers were the most concerned about the child's voice:

do we need to include children to test it?
Would there be a voice tune-in for the initial setup?
How do we define child's age?
Do race and gender create additional challenges?
How do we determine if this is a child speaking?
Do we consider pitch, higher frequencies or vocabulary?
What if the child's voice is altered due to illness?
What happens when the child alters their voice on purpose, to unlock some inappropriate content?
How will the Echo recognize the child's voice as they grow?
What if there is more than one child?
What would be Echo's response to lack of good manners or some snarky comments?

There were also some concerns about data and privacy - could parents consent to storing child's voice in the cloud without children consent?

How would you explore it? What other cool features would you add to Echo? Share it in the comment :)

¹From Wikipedia: Amazon Echo (shortened to Echo) is a brand of smart speakers developed by Amazon. Echo devices connect to the voice-controlled intelligent personal assistant service Alexa, which will respond when a user says the name "Alexa". The features of the device include voice interaction, music playback, making to-do lists, setting alarms, streaming podcasts, and playing audiobooks, in addition to providing weather, traffic and other real-time information. It can also control several smart devices, acting as a home automation hub. The smart speaker needs to use Wi-Fi to connect to the Internet as there is no Ethernet port.

Bearers of the bad news

Ania Gajecka — Fri, 23 Apr 2021 21:40:19 +0000

Testing is often seen as a destructive activity. Spotting and reporting failures may be regarded as criticism against the product and against the author. I, as a software tester, am the bearer of the bad news. We are the messengers of undesired revelations about issues.

Testing is important. It considerably contributes to assuring that the application does everything that it was designed for. Looking for defects requires curiosity, attention to detail and professional pessimism. You probably want to know as soon as possible that something is wrong with your product. Defects found during testing will save time and money later. Win-win!

Hello, police? I see bugs everywhere!

Ania Gajecka — Thu, 22 Apr 2021 22:27:24 +0000

There is a group of testers, that adopt certain behaviours, when it comes to testing.

Sometimes, they are happy they found a bug, just so they can stick it to the person, who wrote that part of the program. Sometimes, they try to impose quality by meticulously entering bugs into a defect tracking system. Sometimes, they tend to keep metrics about the number of defects found in a release, just to stick them to the devs. Sometimes, they reprimand programmers for supposedly poor-quality work or for not following proper procedures or coding standards. Sometimes, they decline testing builds that don't have adequate documentation. Sometimes, they are convinced that programmers need drilling and are there to happily provide it.

Those people are the quality police.

Don't be a quality police officer.

Testing does not automatically increase the quality of the product. Software testers are people responsible for testing software (du-uh). They need to report what do they see and what is lacking.

If errors, defects or failures are communicated in a constructive way, bad feelings in the team can be avoided.

Where You Stand Depends On Where You Sit

Ania Gajecka — Wed, 21 Apr 2021 21:48:51 +0000

Let us come back for a moment to my previous post, where I shared "weird" questions that I was asked on job interviews for software testing role.

Yesterday, during our late evening walk, I asked my partner, a .NET programmer, how he would test a soda machine. Without giving it much thought, he started spilling questions:

does it make soda?
is it refillable, like in Pizza Hut (or any kind of fast food chain place)?
what kind of flavours are there?
when you push the button, does it give you the soda you requested?
is the soda sufficiently sparkly?
is the soda cold?

He didn't even think of a vending machine. I asked him other questions, about the pen, the paper cup and the clock, and his train of thought was slightly different from mine in each case.

To build a shared understanding about the product, that the development team has to deliver, we need different perspectives.
Imagine a simple user story that is two sentences long. Everyone seems to get it, but often it turns out there were some misconceptions, because everyone interprets those sentences differently.
It is important for the team to consists of a diverse people - men and women, people with various cultural background, ethnicity or geographical location, etc. They bring their own perspective, knowledge, insides and experiences to the table.

"Weird" testing job interview questions

Ania Gajecka — Tue, 20 Apr 2021 21:36:43 +0000

I don't think I had many testing job interviews. Less than 10. I am with my 4th employer. But how many is many?

On my first software testing job interview my future employer did not ask me standard questions related to testing like:

What software development methodology did you use?
What's the difference between validation and verification?
Could you tell us about your experience with automatic testing?
Are you an ISTQB certified tester?

I had a non-tech-related background and the answer to those questions would probably be: "I have no clue, sorry".

The fun began, when I was looking for my next employer.

How would you test a clock? A pen? A paper cup? A soda machine?

When it comes to soda machine, you probably have a rough idea on how to test it. You would possibly like to check at least if:

the alphanumeric keyboard/buttons work as intended
it accepts the currency it was intended for
if it accepts real money
it accept cards?
it doesn't give the soda cans for free
it returns the correct amount of cans for the value of money inserted
it returns the right cans of soda
it returns the correct amount of change (if needed)

But for the other inquires I asked miscellaneous sets of questions in return:

What kind of clock? Digital, mechanical, online or maybe sundial?
What kind of pen? Ballpoint, gel, rollerball or ink pen? Or maybe a quill?
What kind of cup? For hot / cold beverages? How many milliliters will it fit?

Those replies were not necessarily wrong. The first question however should be: "What does the client want to do with that clock / pen / cup?"

Maybe the client intended that the paper cup is not to be drink from, but to be shot at from a rifle in an amusement park?
Maybe the pen was ordered by NASA to be used in space for writing purposes?
Maybe the clock will be a colossal monument of astrological clock, celebrating Richard of Wallingford?

Those "weird" questions' main purpose is to show the recruiter the way you think. But the client's and / or the end user's context is an important factor and it will reflect on the end goal - the quality outcome. Having a solid grasp of the actual product requirements makes the use cases, the entry and exit criteria, and every other testing activity much easier and relevant to the case. As such, the questions that seem strange to ask the candidate on an interview at first, serve their purpose.

J.K. Rowling & blog by a "developer"?

Ania Gajecka — Mon, 19 Apr 2021 13:55:52 +0000

I became a software tester in 2014, with no technical background.
I studied literature, languages and teaching. I'm pretty sure that lack of any engineering degree is the pure reason for my impostor syndrome (yes, it's 7 years later and I'm still dealing with it).

Since I don't have that much experience with Markdown editor, while writing this post, I wanted to add the link above and test, if it works.
The link did not open in the new tab/ new window. It did not work, because I somehow forgot the colon. When I pressed Back in the browser, being used to working on Google Drive or Sharepoint, I discovered that the draft of my first blog post was not automatically saved... so I had to start writing it again.

Instantly, I thought about J.K. Rowling - author of the best selling series of books of our century - Harry Potter - and her four-hour delayed train trip from Manchester to London in 1990. The idea came fully formed into her mind for a story of a young boy attending a school of wizardry. She didn't have any pen and notebook, so she had to think about items and characters, and just remember. When she reached her flat, she began to write immediately. She later said:

I couldn't write it all down, so I had to think about it. And I think it is good. Back then, on this train, I had a lot of details on my mind, so if I didn't remember them, they probably weren't worth it.¹

My mind works in mysterious ways. So, why starting a dev.to blog when being a ~~manual~~ software tester?

Lisa Crispin and Janet Gregory in their extensive book on agile testing define the testing role as follows:

[...] we use the term tester to describe a person whose main activities revolve around testing and quality assurance. [...] We often use the word programmer to describe a person whose main activities revolve around writing production code. We don't intend that these terms sound narrow or insignificant. Programmers do more than just turn specification into program. We don't call them developers, because everyone involved in delivering software is a developer. Testers do more than just perform testing tasks.²

So... why not? :)

How do you define the roles of programmer and tester? Share it in the comment :)

¹L. Fraser. Conversations with JK Rowling.
²L. Crispin, J. Gregory. Agile Testing: A Practical Guide For Testers And Agile Teams.

PS. When I finished this draft, I noticed, that you can see the first, supposedly unsaved, draft when you press the button "Write a post" in the menu on top.
The saved one is in your Dashboard. Bug?