Tag Archives: tester

dev-to-qa-300x300

QA Persona

Does designation define personality or  personality defines designation ?  Confused…..?

Either ways you think, you are absolutely correct. Every professional in this world has some sort of personality that differentiates him/her from the crowd. The reason for this may vary, either they have made themselves to appear so or their profession demands it. In this modern IT market, QA engineers are the demand of the growth made in this field. They need to possess most or all of the following traits to be highly successful in this field.

“WHY” factor

I strongly believe that ‘if you have the strong sense of WHY, you can create a beautiful result. Always possess a mind of valid WHY,you should not merely accept anything served in your plate. Try always to clear your WHY card,if that is done you can come up with productive ideas and solutions. You should not pretend as if you are through to any concepts or knowledge transferred,just to leave an fair impression. You should understand that you are here to add value to the project. Ask yourself until you get familiar with every aspect of the project you are assigned with. Remember this simple WHY as the capability to unearth a whole lot of information.

Assumptions:

A QA engineer never assumes anything while performing his task. So he never make an ASS out of U and ME because that is how it is spelled. Since childhood we are used to assume some facts in order to proceed with the problems, even the world’s greatest theorems are formulated on assuming some facts. Let me figure out the things a layman assumes while filling up a simple registration page

  • Name text box should contain only alphabets
  • Mail ID should be in a proper format(mail@domain.com)
  • Fields marked with asterisk(*) are mandatory to be filled.
  • Address line should be separated by using comma or space.

A layman simply applies the common sense which is still not common to find. But just think if the application accepts invalid email ID, mandatory fields can be left blank or if the date of birth accepts future date and many more. This all can lead to troublesome situations. A product is made for the market and you cant expect that he will have the required common sense to use the product. Thus a big question mark arises for the quality of the product, you need to put yourself into various categories of user’s shoes so that you can test the product in all aspects.

 

Down to Earth

A QA Engineer is supposed to be unpretentious, approachable and genuine. S/he understands that s/he is the voice of the end users. S/he is here to make the software better. There are often situations when s/he needs to go against a team of developers. If s/he stops reporting a set of bugs with a assumed notion that development team wont put an eye upon them, then it may lead to troublesome situations in a long run. So in order to deal with such situations he needs to possess strong convincing skills so that he can convince the developers and sometimes clients for the changes to be made in the project.

Eagle’s eye

This analogy works well with QA engineer,he needs to possess eagle’s eye to become super star in the field of Quality Assurance. Many a times most severe bugs surpass our eyesight if we just have an overlook of a product or application and thus risking the product’s quality. As an QA engineer we need to deeply investigate the project in every aspect. We need to uncover the hidden bugs which can have an severe impact later on if it is not fixed in the initial phase of the development cycle. So he needs to be in proper sync with the development cycle so that bugs cannot be carried forward.

Strong Communication:

A QA engineer needs to communicate with various individuals involved in software development cycle in day to day agenda. S/he is involved in communicating the bugs discovered,the enhancements required etc not only to the development team but also to the client. In his day to day curriculum he needs to prepare Test Cases, File and report bugs. So he needs to be strong in written communication. If in any situation there is a deviation from this then it may lead to Communication Gap and thus ultimately risking the product’s quality.

These are the traits which I find most important to be there in an QA engineer. S/he is supposed to wear several hats while working. S/he is the Quality manager, customer service, tech savvy user, non tech savvy user, angry user, lazy user and last but not least the quality assurance engineer. Many a times s/he has to change her/his thoughts mid-stream, and adopt a different point of view in order to get the job done properly. To most extent a company’s brand solely lies upon her/him. So, above all s/he has to work keeping in mind the company’s image.

 

Why Do You Do Things You Do?

Few things to consider before testing any application

I have a wall-pWhy Do You Do Things You Do?aper on my desktop which says: – “Why Do You Do The Things You Do” which forced me to write something like this which i feel should be considered before testing any application: –

1. Learning: – Analyze your test results thoroughly. Do not confuse yourself with ‘pass’ or ‘fail’ but finding the root reason of ‘fail’ or ‘pass’ will give you an idea for the solution of the problem. Testers knowledge increases by sending solutions for the problem

2. 100% of anything is not possible so having 100% test coverage is not possible but we can try to touch 99% of perfection.

Continue reading Few things to consider before testing any application

Software Testers: Who is your boss?

I was spending some time with a software test engineer (tester) recently and have a simple realization to share.

“How come this runs so slow?”
“Oh it runs just fine, just some problems only in IE browser”
“Why?”
“Probably IE’s Javascript doesn’t run so well”
“Yes but soooo slow?!?”
“Yes… but my Lead has seen it and knows about it”
“Which means it doesn’t matter?”
“Well not that… client has also agreed to Chrome-only support”
“The site will support only Chrome?”
“Yes, we described the problem and got client to agree to it”
“Do you have it in writing?”
“Yes”
“Very good. But why is this the case in first place?”
Developers told me the 3rd-party component doesn’t run on IE.” (look on face: how does it matter since client has agreed anyway)
“You mean a best-selling web UI component library doesn’t run well on IE???”
“Yes that’s what developers told me”

After some pushing and research, it finally turned out that developers had to use another method of data access and voila! – everything ran smooth on all browsers.

No doubt, the incident above and its subsequent resolution display several best practices. Get acceptance criteria in writing. Make sure client understands limitations. Don’t trust explanations! Be hard-nosed. Use common sense (how can a best-selling web UI library possibly not function well on IE!). Don’t let your personal love override the obvious (Chrome is great but that doesn’t mean you can force users to switch).

An aspect I would like to focus on is: to whom should the tester be responsible? Project Manager? Team? CEO? Entity/person who is paying for work?

In the course of project teams and organization and “reporting structure” and salary and revenue and a zillion other things, we forget what is obvious. In reality, the Lead/Manager doesn’t matter. The developers do not matter. The CEO doesn’t matter. The client doesn’t matter! They are all illusion, maya.

The only person who matters, the only person who finally decides, is the user. A software tester is responsible towards only the system being tested, and users of that system.

In the short run, you can get away by keeping your Lead/Manager happy. You can get away by accepting superficial wave-of-hand explanations from developers. You can get away by getting clients to agree to something illogical. You can get away by using bureaucracy to cover your behind – “I have it in writing”.

You can get away because the short run is imperfect. The short run can hide. But the long run is all about the right thing. The good thing. The correct thing. Quality. Truth. Details. Finesse. Care. The long run exposes everything.

The right thing here is to find and fix the problem, or find a workaround if it cannot be fixed.

If you do not, all might be well at the surface. But when the user rejects it in the marketplace, everyone loses. And why? Because we ignored her when we should have paid attention. We got confused by irrelevant intermediaries (colleagues, lead, client, CEO) and forgot who the software is being built for.

In the example above, the user is taken for granted. The user is actually expected to tolerate slowness, or switch her browser if she wants to enjoy our system. The IE user votes No and many users are IE-only. Yikes, that pinched!

As a software tester (whether for a web site or web application or desktop system or mobile app or server software and so on), you are the user’s voice and warrior. Don’t accept reasons. Make your point. File issues where you see issues. Revolt till someone notices. Help in getting the right thing done. Ride alone if you have to, but ride the right path.

Honestly, you are not alone in getting deceived by quick things. It is the same thing in business. Business gets confused by targets and profits and “customer satisfaction metrics”, because those are the quick and measurable things, although they are not what business is about. Business is about doing the right thing for people, not only the legally right thing.

Software testing is about doing the right thing for users, not only the officially right thing.

Thanks!

Author – Chinmoy Panda