September 06, 2008

LinkedIn is not LINKED



Today only I noticed the tiny drop down menu "Add an application" which appears in the home page of the LinkedIn site. With a tester's responsibility, I clicked the drop down. So far so good. The drop down was expanded with three values " people search", " Job search" and "Answers". I clicked on Job search which opened a search form. Hang on. I am in a good company and in a good job. Why do I need a job search application? Let me search and find some people. I decided to cancel the current application. But, How can I do that? I started to think. " Yo man, click on CANCEL link ". I got the command from my tiny brain. I obeyed my brain's command and moved the mouse towards the link. I clicked once. No action. I clicked twice. No action. I prayed god and gave a final try. Oops.. The link is not working..

I am a good tester. Ain't I?

September 04, 2008

Why are we forgetting to grow?

My colleague was joking yesterday that he wished to consider " whats your favorite testing book?" as one of his future interview questions. If he is gonna ask this during telephone interview, I am pretty much confident that many people will fail the interview. when I was reading a blog, I came to know that the same question raised by Copeland during an interviewing process, and uniformly the reply was " I never read a book on software testing". These are the people claimed to be professional software testers. It was not surprising me because there are testers I know personally who never opened a software testing book in their life. There are testers with professional stamps who do not know even the simple day to day test jargons.

Few days back, I was chatting with one of my friend, who calls himself as a test guru. I innocently asked him to tell me some of the key pillars of formal testing? The next minute, he got diarrhea and vanished from the yahoo messenger.

Lee Copeland pointed this beautifully in a conference. Let me put his own words.

" A physics student knows who Newton is. a person in biology business knows who Darwin is. But, tell me how many of us know who Dave Gelperin is? Who Thomas McCabe is? Who Michael Fagan is? These are the grandfathers of software testing". But most of us, do not know them. This not only concerned Lee, but also concerns me.

Let me ask the same question "How can we call ourselves as professional testers if we are ignorant of our own history? " Why do we resist to grow our knowledge? This makes us to be seen as some of the lowest forms of life in the software world. we ourselves do have to believe that testing is a valid specialty in software development and try to grow.

July 02, 2008

Do companies need manual testers in future?

Automation seems to be a hot word right now in the QA industry. I even read in one article that manual testing may be phased out in the future. I almost fell out of my chair. Granted the article was written in a very PRO-Automation periodical.

I could imagine a time where there would be little need for testers who could perform only manual testing, though. I think it would be impossible for manual testing to be phased out; there will always be a requirement for good manual testers. We can't automate for constantly changing software and in some cases we need testers with experience, people who can think as they test.

Shall I put this way? Unless there is an unpredictable artificial intelligence advances to a stage where there is a learning robot which can also make intelligent decisions, manual testers have a future in the test era.

I am not biased to manual testing. In fact, I like to be an agile tester and wish to maintain a level of automation in companies I work for. We can definitely speed up the test process by a certain level of automation. But, we have to understand that automated tests will always run on a constricted set of parameters. There is usually no guarantee that the situation at a customer's shop will fall neatly into this constricted set. It takes a tester's imagination and creativity to cover these situations.

Automation only tests what it is programmed to test (in advance), manual testing might yield results never expected. For instance, while I test for one issue, I suddenly notice a suspicious activity in the some other areas, or an unexpected exception coming from the server, showing a completely unexpected issue to investigate.

You may be surprised and ask me “Why do all the jobsites and current companies call for testers with Automation experience”. Trust me; it’s all pretty much either some general trend or marketing gotcha going on. But while pure automation is not going to happen in many companies, the days of pure manualness is going to be gone soon. Even in my environment, we test web application and we do automation for defect management and performance management. We cant do everything in either way ( manual/automate) because it either may require checking some test results which is difficult to automate or too time consuming to do manual testing in each and every release.

Let me come to the point. If anyone asks me “will manual testers be wiped out in future?”, my answer will be “No”. Manual testing and its continued existence is assured until coding is no longer done by humans.

Manual and automated testing should not be viewed as or/or. They should marry to live happily ever after and to give an offspring of new tests.

June 19, 2008

Testing without specification

If you ask me, testing without any spec is a real pain on ass activity. Nowadays it’s a major challenge to many Test gurus. Say we have a requirement to test and that is the only requirement we have. The immediate reaction of testers will be “How can I be expected to test without specification” or “What’s the delivery date”.

Though different companies follow different concepts and procedures in testing projects, there is very little which is unique in testing job.

Whenever a project manager requests you to start testing a project which can be either a new project or a maintenance build, resist the temptation to start testing immediately. Our first step has to be identifying the project size and determining what can be expected from this testing experience.

It is important to create a functional specification before starting the test. If we do not have a clear statement of the objectives of the project, we may not know when to complete the testing.
If you are “No time to plan, I’m late, I’m late” sort of person, at least attempt to list everything that need to be done to complete your project.

Then we have to size our work effort. It’s good to maintain a good working relationship with the people who delivered the system to be tested. I always make frequent discussions with developers and identify as much documentation as possible. An effective way to identify the functionality of a component will be to ask the developers to list all the expected outcome of that component. Next I find out the input of the component followed by the necessary steps to produce the output. This is a handy way to capture requirement.

Once we sized and prioritised our work effort, it’s possible to provide an estimate of our testing effort to the management. This is a crucial test management practice. I highly advice all test professionals to find an estimate of how long each activity in the test activity list will take. This will help the project manager to plan his schedule.

Finally, I often review my activity list because customer requirement is likely to change frequently. So we have to add new ones if needed and avoid keeping anything in memory. Even I am working in a short time period, I try to document everything. This makes my life ease when producing weekly report to the project manager. Yes, make yourself the habit of reporting your findings to the relevant parties. This will help to keep the communication flow in between the team alive.

Hey folk!! Am I talking a lot of management stuff? Cool. Through my next blog I am gonna share my experience on TestNG- The next generation java testing framework. See you all soon.

April 30, 2008

Voice of a Tester: Sharing my experience

I always have the habit of dreaming about my career. There are many people I know who take testing as a job and enjoy their life with their income. What they simply need is a job; A job to carry their life. They seldom think about their future. They do not have a clear ambition.

At the same time, there are people who wish to take testing as their career. I am a subset of this category. There is a clear difference between a job and a career. I will explain the difference in a simple example. Consider a computer science student who tries to find a part time job as a pizza maker to cover his university fees. Consider another guy who is doing a diploma in cookery course joining the same pizza shop to get some experience. For the first guy, what he currently does is a job. For the second guy, it’s his career. He would eventually like to be a chef. The experience what he perceives at the pizza shop will definitely be a plus to his ambition; A chef.

Alright, I hope you all now have a better understanding about a career and a job. Let me come to the point. What kind of future can I have in software testing career? Have you ever thought about that? If you ask me, the answer is yes. However it is not a simple answer. It is quite complex. It is very easy to dead end in testing.
We testers have to manage our career, else we might go nowhere. A harsh truth in the IT industry is that a tester is recognised next to a developer. You may think that I am crazy. Folk, I am telling the truth. The pay is often lower in testing than in other development positions. But it does not have to be always true. If we know how to improve our skills and pick our employers we can be in safer side.

A Tester can select a technical career track such as an automation tester, automation architect, performance tester, user interface tester, systems analyst, test planner or a black box tester. The much technical knowledge you have, the much pay you can expect. From my study on software test job market, I learnt that an average pay of an Automation expert is 30 percent higher than a manual black box tester. We can move towards test management such as test lead, test manager, director of testing, and director of quality, internal consultant or an external consultant. Test management always has a pleasant scope which is however quite challenging.

If you are a fresh graduate who is trying your first job as a tester, or if you are an employee of a company looking for a testing job or else you are unemployed who is looking for a testing job, then I would like to give you all some suggestions. They are what I learnt from my mistakes.

We have to find out what a job advertisement requires and alter our resume to respond to their requirements. Its better to make the employers understand what expected skills we currently have and what skills we like to learn and improve. We may be called by a recruitment consultant for an unexpected interview. We might not be impressed with this offer because the company is not stable or its in a remote place or the salary is low. It is always better to go and face the interview with the same enthusiasm as we would for a job what we really like to get. This is because interview is a chance to practice our interview skills in a realistic setting. I missed many interview in my life due to negligence. I regret a lot now for those chances.

I did not know about the payment rates when I joined my first formal job. I consider that as one of my life time mistakes. Now I have made as a routine to doing periodic research on current salary data in our field. Knowing this information will be really helpful in interviews.

I always like to serve in one company for a longer period. It is usually a good idea to keep a current job. I don’t like to consider my pay as a stumbling block in getting a job. When I was offered a first job to work as an IT professional in a reputed company, I was ready to be a volunteer because I loved to work in IT. However it is important to know how much our talent, effort and hard work is recognised inside our company. I don’t blame on those who think “we deserve for the company. What do we get in return?” If your employer is not ready to identify your capability and treat you according to that, I personally don’t think it’s an ideal company to work with. Good companies do not normally do such.

One more valuable point is that it’s much easier to find a job when we are employed. When I was unemployed I was so desperate and I needed a job quickly. As a result, when a company offered a job for less money and made some other few promises I had to shake my head. I am telling you all only one word, loud and clear. WAIT. Don’t be in a hurry. But don’t slow down your job search. If you have the right skills, you will be definitely hired with a decent pay.

January 30, 2008

User Interface Testing: More guide lines

Hey friends, you know woah..

User Interface Testing presents software teams with significant challenges. Simple UIs reveal a surprisingly large number of possible interactions, and therefore potential bugs. Lets see how we can start the UIT. When we test the Colors what do we have to consider?

Well, I try to answer these questions Yes- Are hyperlink colors standard?,are the field backgrounds the correct color?, are the field prompts the correct color?Are all the buttons in standard format and size?Is the page background (color) distraction free?Are the screen and field colors adjusted correctly for non-editable mode?Does the site use (approximately) standard link colors?

Hey, what about the content? Do you all check All fonts to be the same,are all the screen prompts specified in the correct screen font? Does content remain if you need to go back to a previous page, or if you move forward to another new page?Are all texts properly aligned?Is the text in all fields specified in the correct screen font?Are all heading left aligned?

Any idea to test the navigation? oki doki. I try to fill these gaps.Are all disabled fields avoided in the TAB sequence?Are all read-only fields avoided in the TAB sequence?Can all screens accessible via buttons on this screen be accessed correctly? Does a scrollbar appear if required?Does the Tab Order specified on the screen go in sequence from Top Left to bottom right? (This is the default unless otherwise specified)Is there a link to home on every single page? On open of tab focus will be on first editable field When an error message occurs does the focus return to the field in error when the user cancels it?

Finally, what about the Usability. These are the stuff i learnt from test gurus' and i strictly practice. Are all the field prompts spelled correctly? Are fonts too large or too small to read? Are names in command button & option box names not abbreviations.Assure that option boxes, option buttons, and command buttons are logically grouped together in clearly demarcated areas "Group Box" ,Can the typical user run the system without frustration?Do pages print legibly without cutting off text? Does the site convey a clear sense of its intended audience? Does the site have a consistent, clearly recognizable "look-&-feel"? Does User cab Login Member Area with both UserName/Email ID ?Does the site look good on 640 x 480, 600x800 etc.? Does the system provide or facilitate customer service? i.e. responsive, helpful, accurate?Is all terminology understandable for all of the site’s intended users?

Hope, its enough for the day..

January 17, 2008

Coders and Testers : Friends or Foes?

As a tester , dealing with coders is inevitable. The sad reality is that the relationship or the link in both communication and understanding between coders and testers have not been so smooth in the recent past. Many research evidences support this reality. However, in my personal life I always some how manage to build a good relationship with coders. Our experience affect how we understand programmers and how, when we work as testers, we work with programmers. In my current work place I enjoy my work as a tester. Let me tell you how I move with coders.

From my experience, the best way to learn how to interact with coders is to become and to work with other coders as our peers for a while. I have a development background. I came to testing after I have written some production code, had it criticized, condemned and praised by testers, users and managers. We, testers and coders work under different conditions. coders focus on their own theory. They have models for how the system components are related, which components are reliable and how errors proper gate. they must work from their mental model. when they tell that a bug we reported cant happen, they are not saying they are infallible. they are saying this type of error doesn't fit with their model and what they believe to be true. we testers better have to focus on observation and evidences. This tests their model.I always Keep clear notes and logs, focus on reports on what I have actually seen and let them find the flaws in their reasoning.

We will be effective if the coders share information with us such as their plans , early drafts, design docs, prototypes, etc.I find out what kind of feed back they want and give it to them. I always offer to assist coders directly. This builds trusts and proves that I am some one they should cooperate with.