How important is finding an UI bug?

There is often a debate among the testing community, which bugs have more value , a UI bug or a functional one? Most of the QA folks have this opinion of functional bugs being more important than a UI bug.In general UI bugs are more important for consumer applications and functional bugs for the enterprise applications.A functional bug is considered more important because that is what is expected out of the system and if it fails there is no point in having a system. Not everyone is tech savvy nor everyone will check for the functionality when you ask them to use it for the first time. Let us for example consider someone using an e-commerce website. When users click on the link,they would first look at it for its aesthetic appeal. It doesn't really matter to them if the site's functionality works fine, the transaction works fine etc etc.,  The first few seconds to minutes  the site should be appealing for the end user like showing the latest collections, the current offers,a catalog of the products listed etc. If this part has any issues, then it is going to screw up the organisation big time. If clicking on any of these links, takes the user to some 404 error or 500 error, then the user would no longer remain in the site and would move to some other sites. The next important thing is how good is the usability of the website. When I say usability, it means that how easily can someone use the website to perform any transaction. The functional part comes after all these. Adding/Removing any item to a cart, proceeding to checkout, making payments etc come under the functional part. All these are expected to work fine as they are the basic features of the e-commerce website. Any website that makes a user to stay on it for a long time is sure to have a good user interface.  Even minor  UI bugs can make or break opinion on any product.It is therefore very important that UI bugs be given equal importance when testing any application. 

Lesson Learnt: Art of passing the buck

This is one of the good lessons that I learnt from one of the project managers that I worked with.
It was a completely different work that had just come to our team, and I was selected for it. I was in the training period. I had all sorts of audio, video sessions, conference calls, everything that a normal IT person would use for having a KT session. The real work started. Since I was new to the task, a person in US was supposed to monitor my work for initial one-two months. After one-two weeks, I gained confidence about the work being done, and my peer in US had the equal confidence in me, that he stopped monitoring me on a daily basis. I would complete the task and keep it, and he has to change the status each day. The work would be done by me in his name, and he just has to change the status in simple terms. In that way, we would be covering India-US time zones. The US peer was actually working at the client place, and we were the offshore team. Things were going fine , until one day this happened. I just got a call and had to leave home for some urgent reason and there was one pending task. I wanted to mail my US peer about the task and leave home. But since it is all about dollars, my PM suggested that I complete the task asap and leave. Without checking too much, I just completed the task and left home. As usual, my US peer changed the status once he came online. Next day morning there were lot of escalation mails waiting for me in my mail box. I did not know what to do and how to deal that. In came my PM and I told him about the escalation. There were no smart phones or personal laptops even for PM's that time.He had to come to office as well to check his mails. He immediately called me, asked me if I changed the status. When I said no, he just smiled and said, this is simple, you don't worry. Go, have some coffee and cheer up!, I was shocked that he took it so lightly, then after 5-10 minutes he sent a mail. The mail stated that the onus lies on the person who changed the status as the training period is still on, and that we are not responsible for what happened. A typical response from an offshore PM. The client couldn't argue much as there was nothing incorrect about the statement. My US peer was at loss of words and he took the blame upon himself. I somehow felt really bad as someone else had to take the blame for the mistake that I did. But then I realized, just like taking up responsibility for mistakes, one should also learn to pass the buck when required.  

Work Begins and initial lessons learnt!

1. After training for a couple of days in few Ad servers and the process, I was assigned the first task, QA of tickets. Just like ad trafficking, QA also requires good knowledge of ad servers. Impressions, Ad size, Ad targetting, Type of Ad, many more to know. It was a good experience that doing QA for each ticket was a challenge by itself. Getting an issue was not so easy, but there is always a chance of missing something, and unlike other software , you do not get a second chance to test it. Testing is only once and therefore it requires an eye for checking even the minutest detail. Different regions have different terms, for one region what looks like a jpeg ad would be a xml ad in another region. This was a simple point during training. But I learnt it the hard way during my first QA week. Since there was resource shortage, right from day one, there was no one to even check if my testing was proper. I still remember my first big flaw. It was 234x60 size ad , that was supposed to be a xml in APAC region, was displayed as a JPEG ad. Both trafficker and QA passed it and the ad ran as JPEG. First escalation mail, and still I remember the shiver that I had that day. The person who trained me was the one to handle it. He just smiled at me and said , that's ok, this is how you learn things. I still remember those words and his smile. It was he who gave me the confidence, and made me believe in myself. It was that day , that I realized being a QA is no ordinary job. Though a QA doesn't do things like ad trafficking or coding,he/she can greatly influence things and the buck stops with the QA!!

First few days in office

A day after receiving my offer letter, I joined my first company. I still remember the date, 23rd Aug. No matter how many years pass by, first job is always special. True that, I still remember the days when I used to address my colleagues as sir and madam :)

Being a fresher, it is quite natural to feel uncomfortable with seniors or interact with them. But I was lucky to be part of a very friendly team. Within few hours, I was able to interact freely with almost all.

Adops QA-First training

As mentioned in my previous post, Adops- QA was my first job. I was given an informal training on the very first day of my joining(on the day of my interview actually!). The project manager explained what the project is all about with few block diagrams and flow charts. Getting out of the interview room and before getting the offer letter, attending a training, just imagine my plight! Seated next to me was another colleague who was planning for a team change then. I had to show that I understood everything because only then I would be able to leave atleast around 8 pm that day. After having convinced my manager that I understood everything, going back home, I wondered if I really did?

By Chance or by Choice?

It is neither by chance or by choice that I happened to be in a field where I am now. Yes, software QA was neither my first job nor my first choice of job. Just like any other Computer science Engineering fresher, I joined my first company as a Trainee. My first project introduced me to the world of QA. It was an interesting, but intense job. The QA has to ensure the ads run successfully in many websites. To check that, a QA must learn and understand the process of how ads run, about ad servers etc. This job evoked a sense of interest in me towards software testing and I joined a course to learn what is software testing. This course made me change my career from a Adops QA to a Software QA.

Saying a hello..

This blog is about my journey in the field of software testing.  I hope to keep the blog as simple as possible. Hope you folks like it :)