Bug hunt. Bugs in real life – Sleepbot.

In these series of short blog posts I intend on showing some bugs in applications I use – web or mobile and how I got them. This week’s winner is – Sleepbot.

One thing I need to say – I don’t try to commercialize anything, I don’t try to get credit for anything related to those apps, normally they are free to download and I am just documenting what I’ve found from user/tester perspective. I normally wont dive into what heuristics and methods used to find bugs, because I didn’t used any, they just showed up at some point and I was aware enough to catch them.We can make some important conclusions though, which will be valuable for us as testers.

What is Sleepbot?

Sleepbot is a mobile application which is used to track your sleep and wake you up in its lightest phase – when it’s most likely to wake up easily. It has Android and iOS version and I encountered a couple of issues on the Android version with the Samsung S5 and Android Lolly. Here’s the official site of the app: https://mysleepbot.com/

Issue #1: Add alarm keyboard hides “Ok” and “Cancel” buttons.

Basic view sleepbot add hour

 

Sleepbot add hour main view-keyboard

Sleepbot main view landscape

This is a classic usability issue, in fact it’s one of the most common that a “bug hunt” for when I am performing testing on a mobile device. Very often when you change orientation while having open keyboard there are problems with information being hidden or important navigation buttons like enter, back, ok, submit, etc. As you can see on the screen shots, the “Ok” button isn’t visible in portrait mode, while it appears in landscape. It might have been intended this way, I figure out it might be quite hard to make these buttons appear, due to their dimensions, but there had to be a way, to provide the user with an option to close the keyboard or at least a scroller to scroll down and reach them. So, I changed the orientation of the device to landscape and we come into:

Issue #2: Value in the hour picker gets duplicated on change of orientation.

Yes, it’s not a mistake in the screen shot, it actually clones values on change of orientation. It’s not only that, but it has a pattern of doing it – it always copies the minutes value in the hours, so if the time is 20.21 and you change from portrait to landscape or landscape to portrait, you will get value 21.21.

 Key takeaways from bug hunting Sleepbot.

Of course, there’s couple of other issues, but I only picked the ones that had some visual presentation – for blogging’s sake. So, what are the things we need to remember from the issues found here – one very important part of mobile testing is changing orientation. And it’s not only the case if the app supports two orientations. Sometimes the devs leave a screen or two without locking the orientation for testing purposes, sometimes just by mistake, sometimes stuff like these pop up. It’s important to remember simple trick that might expose some problems:

let’s say you have screen 1 and screen 2:

  1. Go to screen 1 and memorize what you have there.
  2. Move to screen 2.
  3. Change orientation.
  4. Go back to screen 1.
  5. Verify what you see is correct.
  6. Repeat that transitioning all screens.

I guarantee you that some really weird stuff will appear while doing this and it’s almost certain. I hope this post will be helpful and useful for you.

If you liked it, don’t forget to comment and share with your friends. Thanks 😉

 

Quality means bugs

No, not that little fellow, I mean software bugs 🙂Scared bug

Introduction

I’ve had a lot of conversations with co-workers on whether a bug should be logged or not, and I really enjoyed some very creative excuses on skipping the defect tracking part of the debugging process. I don’t know if it’s ego, or simply attempting to make the work less formal or fear but in my honest opinion it’s a huge mistake and it could pretty soon stab you in the back.

Insectophobia or defectophobia

I mean, there should be a proper name for “fear of software bugs” or may be “fear to admit you are a human and you make mistakes”. I can’t say for sure it is exactly fear, but it’s in most cases some kind of discomfort when a person doesn’t matter if QA,  developer or even a project manager, has to report an issue. And this is where the silly excuses start:

“I’m wondering if it’s an issue or it’s the way it works” – well newsflash – wondering wont make it any better so read the requirements and if they are not clear enough, just ask, developers don’t bite… normally.

“If it’s not an issue I will look like an idiot” – but if it happens to be an issue you will be an idiot for sure. You will never learn anything if you don’t try. We as testers make mistakes, too. And this is how we learn.

“It’s a minor bug, we can skip it for now and log it later” – this is kind of tricky, because what’s a minor bug? Google says nothing, because there’s no theoretical definition on what’s minor… well of course it’s a bug with low importance but what’s low importance, then. If you are making a video game some of the NPCs might behave a little bit moron-ish and this might be completely fine if it doesn’t affect the overall experience – Assassin’s creed 3 had a lot of these, but let’s say you work on a medical software for brain surgery or autopilot on an airplane – what’s minor bug there? Just a small crash, I don’t think so…

“Don’t log this one it’s an easy fix” – You will hear this a lot during your QA career from the developers and you will know that they do it because they want to reduce the formal stuff of reading and writing solutions in bugs, because it’s really boring, but hey we are all humans, are we … and we all forget. And if you forget to log it and they forget to fix it, it will be all your fault when the client finds it and asks why. And one more thing, what will happen if you keep that work flow but you work in a huge software project with a lot of issues? You will find a developer with incredible memory or you will just log the issue so you are sure it’s there waiting for solution ?

“I don’t want this to affect my defect trend” – this is a good one, well to have a defect trend you need defects, right? And it’s purpose is to actually measure how well you are going on fixing them. So if you don’t log any or if you log only the “important ones” you will corrupt your results, which will make the trend totally useless.

No bugs doesn’t mean high quality product

If you use more man to man approach on reporting your bugs, let’s say via skype or by personal meetings, that’s also good, this way you improve your skills as a team, but this isn’t always the optimal solution to achieve high quality product.
Once I asked a co-worker “Why aren’t you logging any bugs, but reporting them via skype?” the answer was “Because it’s faster”. So I asked “How are we going to prove we’ve done any work on this if there’s no hard evidence for it, like bugs found?” the answer was “By a high quality product”. Now, this is misunderstanding – I wouldn’t consider a product that has 0 bugs in it’s bug tracking system a  high quality one, but rather a timer bomb waiting to explode. It’s very important for the QAs to realize that from the perspective of a non-technical user/client if a software product goes well and has no bugs, it’s always due to the developers’ amazing coding skills, but if there’s some bugs after the release – it’s always QA’s fault. It’s life, you may disagree, but you can’t change it. So, save yourself some pressure and log your bugs where they belong – in the defect tracking system.
Yes I know what many of you will say: “What if I work with amazingly skillful hyper-ultra-uber-senior-master developer that never makes mistakes?”. Well, I’d say, I will really like to meet this Obi-Wan Kenobi of software development myself, but until than, they are all under suspicion. It’s simple, until there’s people writing the code and people testing it, there will be mistakes, it’s up to us to find ’em and fix ’em, or leave them and look like fools.

Don’t get me wrong, not that we have to be proud of how many defects we’ve fixed, that wont make us look professional, too, but having bugs is part of the developments process, don’t be afraid to deal with it.

29169214 And that’s true, too. You will never be able to find all the defects and fix them, but at least give it a good try and make sure you are releasing a good quality product.

Conclusion

“There is no war without victims” they say and I will add “and there’s no software without bugs” and during your career as a software quality assurance you will have to find them and report them, this how it works. There’s no silver bullet for it, but try to follow the workflow, people didn’t invented the bug tracking tools just because they are cool, but because they are useful. And after all we are all humans and we make mistakes and by finding them and fixing them, we improve and go forward. Don’t be afraid to face issues and fix them, this will make you only a better professional.