Category: Testing Challenges

My team is my company – Day 11 of 30 Days of Testing

buggylina1 Comment

TAKE A PICTURE OF YOUR TEAM

I am an only dedicated QA person in my company, but does that mean that I am a team of one? I don’t think so!

My team is every single person who works in my company, because:

  1. We all are working for the same products
  2. We all want our products to be in good quality
  3. We collaborate with each other towards our company’s success

To illustrate it, I can give you a few examples how my work is related to each and every one of my colleagues:

  • Account manager collects outstanding issues, communicates them to the partner, asks for verifications and needs help explaining some of issues.
  • Sales person is preparing for a pitch and jumps into an issue – it gets extra attention if it was reported, if it wasn’t – it gets reported, and, if it’s actually not an issue – it is explained by QA and raises awareness.
  • CEO may as well check the product and doubt quality, QA has to be there to explain if quality did change or not, try to investigate reasons why the change may have happened.

I did not even include some obvious collaborators: programmers and product management colleagues. Every QA analyst works with them closely.

It can be a way different situation in a big company where people are more distinctly working in separate “teams”. This is understandable: after a certain limit of people it’s easier to curate smaller teams and have leaders there who are connected to other leaders of other teams. I have worked in a setting like that, but must admit that I like small company better.

You may be wondering, so how did I manage to get all my company to one picture? Sadly, but I didn’t. However, our awesome front-end developer agreed to represent the whole company and you can see the picture here.

How to find testing (and not only) events to attend – Day 10 of 30 Days of Testing

buggylina3 Comments

FIND AN EVENT TO ATTEND (ONLINE OR FACE TO FACE)

The task for today is clear, but the question is: where can we find events?

In this blog post, I will share where I look for meetups, webinars or other events to attend.

  1. meetup.com Meetups – this website is definitely a winner of all kinds of meetups in one place. You can find meetups from various areas in your own city. Not only that you have a huge selection of meetups to attend, but you can organize them as well (I have a meetup there, too!). It’s a great way to discover like-minded people in your city.
  2. Ministry of Testing Masterclasses – as of today, there is no new masterclass announced, but I have attended the last one and it was a great success. Attending masterclasses is easy, very beneficial and free – you just join them online. Make sure to register and actually attend them, if not – they still will be available, but only for Pro members of the Dojo.
  3. Sticky Minds Web Seminars – there you can find a list of pretty interesting webinars to attend. Don’t get scared of time 2 PM ET, if you are in Europe – it will be your evening, so perfect activity after work. Sticky Minds as well include on-demand webinars which you can just watch when you want.
  4. Test Huddle Webinars – similarly to #3, in this website you can find a lot of useful webinars on various testing topics not only live, but on-demand also.

My choice for the event was found in #3 site:
Test Data Playbook: Create a Winning Test Data Management Strategy for Application Testing

I don’t really have much of test data usually, but I believe it’s a useful topic to hear about and learn new things. Feel free to join me!

7 bugs out of 5 will do for Day 8 of 30 Days of Testing

buggylina1 Comment

DOWNLOAD A MOBILE APP, FIND 5 BUGS AND SEND THE FEEDBACK TO THE CREATOR

With so many apps in the market, it can be tough to choose the one you would like to test: should it be a known and stable app, a small hobby app which you would like to use or an unknown app? This definitely can be overwhelming.

I have realized that there is no need to look too far to find an app to test: my colleague is creating apps, so maybe he would have something new bubbling up in the lab. So, why not to help someone you actually know and give some useful feedback?

The beta app I got to test from the creator himself is called MoveRite. This app helps to learn how to do exercises correctly with videos and detailed instructions. You also can track your workouts and purchase extra exercise sets.

It is an iOS app which I tested on iPhone 6. I explored and familiarized with the app by creating random workouts, checking out functionality. It is in quite good condition, so no major bugs were encountered, but it’s not totally bug-free either (but who is?). Enormous help was that creator could give me test user for purchases, so I could test a lot of areas.

Here are my findings:

  1. No weight exercises have weights assigned to them and there is no 0 to choose.crunches with kilos
    At this stage of the app, all exercises require weights. What should be the weight for your abs exercises? The smallest you can put is 1 kilogram for crunches.
  2. About the app section contains default text filler
    loren ipsum
    This is rather expected in an early stage of an app – text will come later, so just a minor detail. So, let’s move on to better findings.
  3. Same weight numbers are shown for both kilograms and pounds

    This was achieved by changing measurement in the Settings and comparing same data as was obtained in kilograms.

  4. Kilograms are still displayed in selector with pounds being default measurement
    1) Change measurement to pounds instead of kilograms in Settings.
    2) Create a workout (or edit existing one)
    3) Try to select a custom weight amount
    Verify that even if selected numbers are shown in pounds, but custom selection still includes kilograms.
    kgs not changed in selector
  5. App closes after first purchase
    1) Navigate to App Purchases in MoveRite
    2) Click to purchase one of the exercise packs
    3) Sign in to your iTunes in pop-up dialog
    4) Confirm that you want to buy the app
    Verify that MoveRite closes and you are left in Home screen with Thank you message. You need to reopen the app. 
    app_off_on_purchase
  6. After purchasing second exercise pack it does not change to Owned
    Precondition: you just reproduced bug #4 and have one of packs purchased.
    1) Reopen MoveRite (you may need to sign in on launch, so do that)
    2) Go to App Purchases
    3) Click to purchase pack you do not own
    4) Confirm the payment
    Verify that in App Purchases Pack remains with the price which did not turn to Owned even if you did purchase that other exercise pack.
    after second purchase not owned
  7. After purchasing both exercise packs and reopening app – both packs still have prices and trying to purchase you get a message that you already own it
    Precondition: make sure you have both exercise packs purchased and encountered bugs #4 and #5
    1) Reopen the app
    Verify that both packs are with prices again and not marked as Owned
    2) Click on price to purchase it again
    Verify that message appears that you already have purchased this
    IMG_0058

To comment more on the purchase bugs, I am not sure maybe some of purchase bugs were actual limitations of sandbox user that I was given as creator said that it may cause some problems.

Conclusion: it turned out to be 7 bugs and I enjoyed this challenge a lot.  Exploring a new product is a great feeling. The best part is that I am giving feedback to the creator and a little bit contributing to the product.

P. S. MoveRite is open for Beta testing so feel free to join as well and help it improve!

 

 

Testing web accessibility – Day 7 of 30 Days of Testing

buggylina1 Comment

FIND AN ACCESSIBILITY BUG

Accessibility refers to the design of products, devices, services, or environments for people who experience disabilities. – definition from Wikipedia

There are various kinds of disabilities and points to test web accessibility in. I found a website with a variety of articles on web accessibility called WebAIM. Introduction to web accessibility listed 4 major categories of disability types (taken from WebAIM):

  • Visual (blindness, color-blindess, low vision)
  • Hearing (deafness, hard-of-hearing)
  • Motor (inability to use mouse, slow response time, limited fine motor control)
  • Cognitive (learning disabilities, distractibility, inability to remember or focus)

Keyboard accessibility can be considered as a low-hanging fruit because definitely not all websites are keyboard-friendly. Thus, it did not take me much time to check a few websites and learn that:

  1. My company’s product is not keyboard accessible (this turned out to be a never-defined requirement which may never become defined)
  2. Yahoo’s Home site does not create a hover effect when you tab on article’s Comments. It does tab nicely and gives impression of working on all other icons (like Love):
    Screen Shot 2016-07-07 at 4.46.11 PM

These issues are rather minor, but I would expect Yahoo (being such a giant website) to make Tab accessibility rather more user-friendly and create hover effects on all items.

On Twitter I noticed Visual accessibility‘s bugs. It intrigued me and I checked out Spectrum Chrome extension. This rather simple tool allows you to see instantly how people with different types of vision deficiency see the website.

I thought of games including many colors and checked Bricks Breaking. With normal vision it looks like this:
Screen Shot 2016-07-07 at 6.53.43 PM
A person with achromatopsia could hardly play this:
Screen Shot 2016-07-07 at 6.53.51 PM

For Hearing Disabilities screen reader tools can be used. One example could be NV Access free tool. I really wanted to try it out, but it supports only Windows OS.

Challenge like this raises accessibility awareness. It is very important to build your product smart and accessible to all kinds of people. Living with a disability already makes life more difficult, so let’s try to work on making the Web a friendly place to everyone.

Pineapples do taste sweeter with salt – Day 6 of 30 Days of Testing

buggylina3 Comments

PERFORM A CRAZY TEST

Today’s challenge made me think hard and do a lot of googling to find my crazy test. I even looked up the definition (mad, wild, unusual or extremely enthusiast). Colleagues also couldn’t think of anything particularly crazy. Only one developer required me to listen to Britney Spears – Crazy while doing the test. I completely forgot during execution, so I am listening to it now (makes it more challenging to put thoughts together, indeed!).

The closest to crazy test for me is stress/security testing. However, it already is a way of testing and it’s not really mad or unusual. As well as, bounds testing, monkey testing, cats testing – you name it. Believing that it still can be a usual tester’s activity, I decided to test a hypothesis and found one experimental fact to test:

Pineapples taste sweeter with salt.

Not everyday I eat pineapples with salt – in normal conditions I would not do that, but have to try to be crazy for a day!

DSC_0005-002.JPG

Requirements:
Pineapple
Salt

About the test:
Test passes if hypothesis is proved with at least one specific condition. The condition should be specified. Testing is not limited by any specific way of eating, the amount of salt can be variable in conditions and test products should not be mixed with any other products.

The first step definitely was to check the sweetness of pineapple alone. How do we rate sweetness? Well, I may have a large human error, but I had to trust my taste buds. I made sure that I did not eat anything a few hours before, so I could taste it well. The inital sweetness was rather a mild sweetness, not too sour, very mildly sweet.

Bounds of adding salt had to be defined. Hypothesis did not have anything about it: what should be the amount of salt for the hypothesis to pass?
I decided to check 3 salt amount cases: 1) Minimal amount – a tiny bit on the edge of the pineapple; 2) Average amount of salt – all edge is covered with salt; 3) Maximum of salt – all “open” pineapple parts are covered in salt.

Test results summary:
DSC_0007-001.JPG
Salt did affect the sweetness compared to the initial tasting. The amount of salt affects taste receptors, so best conditions to pass the test are #1 and #2 – from little to average salt. Salt plays with taste buds and mixing up with pineapple’s sweet/sour, it can create an illusion that pineapple is sweeter. Especially nice/clearer taste is when salt affects the tip of the tongue – part responsible for sweet tastes. However, too much of salt can overrule sweet and make it taste salty.

Conclusion:
I did end up eating almost half of pineapple, but this challenge was definitely something interesting to do and experiment. Yay for the crazy!

 

Why you should improve your test automation code – Day 5 of 30 Days of Testing

buggylina3 Comments

READ AND COMMENT ON ONE BLOG POST

Did you know that it’s quite easy to find great testing blogs following just one blog? 5 Blogs is the one! Everyday there is a post with 5 best blog posts read. This blog has been a huge help for my 5th day’s challenge. I got a big list of great articles and chose Learn Development Practices To Improve Your Test Automation Code by Jeroen Mengerink.

This article pretty much expressed what I’ve learned myself. I started coding at my current job wanting to automate some Web UI tests with Selenium. In first month I was googling a lot, reading practical examples and playing around with code. My main focus was to make it work: if I want it to click on a button, it should do that.

I was glad to have something to show: I could run my code and a lot of operations I used to do manually would quickly be executed in the browser. However, even if my code worked, but it was not scalable at all.

After seeing my interest in coding, company’s developers decided to help me and move my project of automated tests forward. This is how my code started to be reviewed. I must admit that I was terrified. My first pull request got around 30 comments about structure, naming, all kinds of conventions. The main advice from the developer was to read “Clean Code: A Handbook of Agile Software Craftsmanship” by Robert C. Martin.

With time passing, I did read bits of the book and started noticing patterns of what mistakes I usually do and a lot of comments under my pull requests would be known conventions which were mentioned in the book. I improved my tests according to feedback I got and… it felt great. I really value all kinds of comments as usually they are helping me and my code to be better.

Thus, I definitely can say from my own experience, that if you want to do test automation, then you have to learn some software development practises as well. This is exactly what article I’ve mentioned in the start is saying: software development conventions are very beneficial to you. I cannot agree more.

Development practises ease your automation work: it is easier to add new tests, you don’t get lost in your own code (with time it’s going to expand), it is easier to refactor your code and change it when the need comes.

Code improvements even become like an addiction in the end – you want to refactor more and more to make your code cleaner and nicer to work with. Do not forget to invest some time to that because if you don’t – you will lose way more time trying to maintain messy code.

are-you-too-busy-to-improve2.png

It’s wonderful to work in a great team – Day 4 of 30 Days of Testing

buggylina1 Comment

SHARE A TESTING BLOG POST WITH A NON-TESTER

Yesterday night, soon approaching midnight, I have noticed that one of my rarely online friends (database developer) got online and thought of using a chance to share an article with him. I was searching quickly to find an article which would be understandable from many professionals’ perspectives, so my article choice was rather a ‘controversial’ topic in a way: more detailed (could say that it was a second part of a previous version) article by Anne-Marie Charrett called “Nuance on leaving testing to the experts“.

After sharing this article with my friend, I have realized that being a developer he’s not particularly a non-tester. So, I decided to ask someone at work what they think of it as well (because database developer went to sleep that night promising to read it in the morning and who knows when he comes back online again with his comments). At work I have found a perfect candidate rather easily – a wonderful outspoken UX designer sitting right in front of me.

The article I shared was rather a more detailed version of “Leave the testing to the experts!” article which caused quite a few comments and Maaret Pyhäjärvi’s response “Work on culture: being told and offering views”.

My colleague not only read the article I sent, but as well the original article and Maaret’s comments. He said that he understands both Anne-Marie and Maaret: “The final decision should be the expert’s, but collaborating with people is a good thing. Sometimes the best ideas come from non-experts. And if you work with competent developers, you can basically be sure that the product they hand over to you for testing should have very minimal number of bugs, so it’s like a trust thing.”

When I asked him  of his opinion on who is responsible for a bug going out to production, he told me that both programmer and tester should be.

This made me quite happy to be working with colleagues who have rather similar attitude to mine. I see Anne-Marie’s point as well and definitely agree with Maaret, for me summary of this would be that: telling what to do may be poison in a team, but offering what to do can help you improve.

I am pretty lucky with my team and company. There was never a saying ‘you must’, my work always involves my own decisions and confirmation. Eventually, it’s me who is testing, so the ways how to do it should work for me to begin with. I definitely soak in all the information I get at work as tips for my testing to be improved. So, in other words:

Please, offer me how to do my work (or rather improve it), all advice is welcome – in the end we are a team even if testing area is my main job

Experience of sharing an article with a non-tester colleague was great: especially to realize that they understand you and your job quite well. Knowledge share is great and we should all do that – because it’s not like in this comic (don’t do that), we all know something that others don’t.

dt000613

TestCast podcast “Testing is Dead”: Day 3 of 30 Days of Testing

buggylina1 Comment

LISTEN TO A TESTING PODCAST

I have never listened to a testing podcast before, so this was my first one ever -testing challenge is already yielding results in teaching me new things.

Not knowing where to start, I created a Google search with “testing podcasts”. One of the first results was a list of Software Testing Podcasts made by Ministry of Testing. I do trust this resource, so without further hesitation, I gave a go to #1 on the list – TestCast. The only problem with the list is that it’s pretty old – dating back to 2011.

I was looking for an interesting title for the first time podcaster and chose Testing is Dead. It is around 30 minutes discussion made by Bruce McLeod and Trish Khoo.

In the very start, they talk about some big names in the industry which claim that testing is dead. For example, Google or Facebook often would give examples in industry where testers are not present and developers do their own testing. Trish and Bruce gave some valid points that giant companies like that can give distorted view to other companies and it should be rather presented as their own way of looking at things and it does not mean that no testers approach would work for each company.

The way Google or Facebook can “reassure” their quality is users. They can be their first testers. If Google search does not work – a user may rather blame her own connection than the service itself. Nevertheless, Google can release their produt to one demographic only (let’s say a few thousands of users) and monitor the change. This approach may not work in other companies where pre-testing and quality is very important.

Later Trish and Bruce moved towards the fact that in many companies people don’t understand what testers are supposed to do. If management just wants a “safe net” because they feel that testing should be a part of the better quality, but they don’t really know what testing is, it may lead to test script writing, amount of work done estimated by checkmarks and actually, not testing, but checking.

To sum up my first podcast experience: it was a bit strange just to listen without seeing the presenters, it could have benefits of doing other task, but I am pretty bad at multitasking. Talking about the content, even if it’s back from 2011, but definitely we have same problems in 2016. Awareness of testing and what testers are supposed to do is a big problem and the approach to work with or without testers is just a choice. So far, testing is not dead and does not seem to be dying.

What I’m doing at work: Day 2 of 30 Days of Testing

buggylina1 Comment

TAKE A PHOTO OF SOMETHING YOU ARE DOING AT WORK

I had to cheat a bit on this one: it’s Saturday today, so I am not at work. I had to take a picture yesterday, however, I’ll share it now.

13570268_10209801873230058_84405356_o

This looks like a wonderful job for a woman – doesn’t it? All day looking at clothing. My boss sometimes remarks “You’re again shopping!”.

I am testing fit solutions and visual similarity algorithm. It is a pretty exciting task to do with many layers and challenges. This picture just reflects a common screen view you can see on my computer when you pass by.