Tuesday, 16 October 2012

Skills Vs Experience In Industry


                                            
This is to share my opinion on skills and experience and not to pinpoint someone. How the people develop a skill? and how the people gain the experience?  Will the skills and experience developed parallel? Definitely not always. The skills have nothing to do with the experience. A skill is what and how we perform like time taken to learn and the approach we do, etc. But the experience is just a certificate shown to others about the work he/she has done for the “x” years. The “x” year of experience of an individual doesn't mean that he/she had developed skills.
 Some have developed their skills like “v” model. Category 1: V-model represents parallel growth in both sides. Category 2:  Some may not develop their skills, but have gained the experience. Here experience speaks more than the skills. Category 3: To someone the skills they developed seem to be differing from the experience. They might have learnt a lot in very short time. Here the skills speak more than the experience. Here they show the experience has nothing to do with the skills.
So among the three mentioned above which could be the better options? So when an employee looking for the change in work, here the experience plays a major role. I have seen some companies which give more preference to the year of experience rather than the skills. Here the skilled professional with less years of experience not able to grab all the opportunities likes the professional who have more years of experience and lack in skills. Skills of an individual have to be judge from the year of experience the individual gained. Similarly the experience of an individual should be judged from the skills developed in that time. Judge the people based on their skills not just by the experience letter.
It’s good to test an individual skill by the means of work done every time and also the priority should be given high to such professional. This makes other category professional to change themselves and follow any of the other two categories.  When the preference is given more for skills in work environment then I would say the rate of fake experience will be reduced. The fake experience plays a major role nowadays. This is one of the reasons for the occurrence of such happenings. So I want to say judge the people from the skills not just by the experience letter.
The one which we hate becomes a challenge and the one which we love becomes a passion.

Email id: ktg.pradeep@gmail.com  
Phone: 08951737784



Monday, 8 October 2012

Human Brain: The Best Tool to Test


Human Brain: The Best Tool to Test
        There is “N” number of automation tools available in the market and also many are yet to be released in the market.  We have come across with number of tools. So which is the best among the available tools? I would say that, the tool which is residing among all of us and can't be sold out to the market. Yes, it’s a “Human Brain" the more powerful than any other automation tools. I agree that the tools can work faster than the human hand work, but if everything is automated, then there is no work for the tester’s new ideas. Imagine if there is a big testing war that is yet to come and we need to face that. How to get ready to face that challenge? Can we prepare a tool for the upcoming war? How can we make that without knowing what sort of war is that? So preferences should be given more to the brain work than the automation work. This helps the testers to walk on their path rather than someone else path and help them to face any sort of challenges.
How the automation tools should be used:
         As my coach says "There is different mechanism that should be applied while eating food. It's quite hard to eat chapati in spoon or fork. The spoon can be used while eating idly or any item related to that.  So don't depend on spoon/fork for all items that you want to eat.  Now, relate this to the software application. When we test, we should not totally depend on automation tool. It has to be used where it is supposed to be used. We can’t eat ice cream in hand. Here we need a spoon. Similarly we can’t test a million data manually. Here we need to test with the help of tools.  It has to be used where it is supposed to be used. It’s better to test manually in case of testing some medical equipment and also the product that might harm when it goes wrong. If we want to check X million data, in such case the tool can be used. But still some cross check can be done manually that gives a good confidence. Pick some data randomly and test manually.
When we trust that the tool we use doesn't cause any problem and the result produced from such tool is a perfect one and if we believe that the end result is the exact one. Then imagine if any non-reproducible bug exists in that tool. In such case, some time there is a chance of showing the error data as a right one and the correct data as a wrong one. So here I come to say that don't trust on tools always trust your own test ideas. That's helps you lot in case of testing any medical equipment’s, etc.  So I feel it is good to test manually and then you can go for automation.
               So don't depend on tool always. In short to say a tool is like a guide for the text book .It can't be an actual text book.  Still if people believe that tool can be a text book, and then I say as "A fool with a tool is still a fool".   The cost of risk can be minimized when it is done by manual than the automation.

    

Tuesday, 25 September 2012

The Advantage of Open Source Testing


The Advantage of Open Source Testing

 Here I want to share my suggestion for the fresh testers. As I have already mentioned in my blog " A Few Tips for Testing Fresher” about my approach in testing and bug reporting,  here  I wish to share my ideas on advantage of doing an open source testing. If you are already aware of that and practicing it then it’s good.  Here I wish to tell the fresher’s who might not aware of such thing and might not have heard about the open source testing. Okay, I suggest it is good to practice an open source testing. This helps you to improve yourselves in learning how to test.

What is an open source testing?
These are software products whose source code is publicly available and under an open source licence to study, change, and to improve its design.

Choose any website and apply your test ideas and do some test.  If you find some issue in that application report that to the developers. If the issue is a considerable one and critical then, there are some organizations which they will pay for the one you have reported. Apart from that you yourselves keep learning by doing such test, where your testing skills are also being improved. Remember there is no bug free software that is available in market. So now there is a hope that you can find issue from any of the sites.

How long you can practice this? You can practice throughout your career. You can also add this in your CV that gives more weight-age to your CV. This will create a confidence among you and helps you to test better and faster. So I suggest you to do an open source testing as one of your hobby. So keep practicing. As my coach says, consider there is a big war that is yet to come. So how you keep yourself prepared for that?  One of the ways to prepare myself is to do an open source testing. Though doing an open source testing as one of my hobby, that question made me to do more and more test. This helped me to test faster with some more new ideas. The fresher’s who are guided by a right coach, means that they are in the right path. Why I want to mention this is unless my coach tells about this, I was not aware of such testing. Now I realized the importance and seriousness of doing such testing. So I wish all the fresh testers to practice this open source testing. Apart from fresh tester it is good even if an experienced professional practice an open source tests and also helps a fresh tester to practice this testing and be ready to face the war that are yet to come. Smile J
 
Mobile: 08951737784

Monday, 10 September 2012

The Risk of non-reproducible bug

The Risk of non-reproducible bugs:

                 I have come across with few non reproducible bugs. When I found for the first time,  I was not aware of the criticality of that bug. Because I felt it happens in rare cases. Once I was going through the blog of a famous tester, in which he has mentioned about the risk of such bugs and also I was guided by my coach to investigate this issue. So I realized this may not occur today, but might occur in future. Because the issue is not resolved yet. As a tester, I am responsible for the quality. So again I started my investigation. When I was looking into this issue I found another issue which was more critical than the one which I was looking for. So I was thinking if such issue still exist, then what are the possible things would happen.

1. The user might lose the trust.
2. There is a chance for the user to move to the competitor’s product.
3. This could cause a big loss for an organization.

 Okay. What was the bug?
        When I was testing a site using my credentials, unfortunately someone else account has opened. I found that issue in a e-commerce site. As I was aware of the risk, I made some investigation on that issue. My first approach was :
          Changed the content in the URL and looked if  any change has occurred. I found that the page was loading very slowly. So I tried the same investigation on a different day at the same time, it happened again. I noted the speed and I found that the page was quite down between that time. So I realized that the server was down. Since there is a huge traffic to the site, the server was not able to respond to which the request was send at that time. So whenever the server was down I found some more issues. So I felt it’s just because of the server performance the issue has occurred. I could say that the non-reproducible bug is more dangerous than the reproducible. Because the reproducible bugs can be reported and fixed. But in the case of non-reproducible bug it’s quite hard. So more investigation is needed in the case of non-reproducible bug.

How do I approach:

 If any bug was found and not able to reproduce then I consider the following,

1. Nature of the bug.
2. Risk, if it appeared for the next time
3. Note down the time
4. Environment
5. Under what circumstances it appeared
6. Will it affect other functionalities.
7. What was my previous action.
8. Systems behavior (before and after the bug occurred).

Other possibilities:

In order to reproduce the bug, I look into some other possibilities like

1. Changing the content of the URL.
2. Opening some more tab and performing the different task for the same application.
3. Opening the different browser and  performing the different task for the same application.
4. The same operation under different machines.
5. Perform the same step and check whether the issue occurs again.

If it happens again, we might not be able to provide a proof for its occurrence. So it is always better to record a video while testing. Because that gives a strong proof for its occurrence.

Saturday, 8 September 2012

A Few Tips for the Testing Fresher


                         
A Few Tips for the Testing Fresher 

      Here I wish to share some ideas for the fresher’s who want to start their career in testing.  Before getting into the real time work we just know testing is about writing the test cases, execute and if any bugs found we report it. But there are few more things to be considered beyond that. Most of us what we do is that we just learn the definition of testing, their types and so on. We feel that if we know the definition we know testing.  Knowing the definition that might help to some extend during some interviews, but not always.  Even in learning the definition, be aware that you choose the right material. Because there are “N” number of definition given for the question such as What is testing? The answer vary from people to people. Here I could say no body is best to give a perfect definition which could not satisfied by all. Because different people have different thoughts, unless you test you could not give a right definition.
Know the definition for the few questions that would be asked in interviews.
1.       What is testing & What is Software testing?
2.       Why testing ?
3.       Testing types
4.       Models
5.       Available tools
6.       Difference between Manual  & Automation Testing ?
7.       QA & QC ?
8.       Test case
9.       Test ides
10.   Test coverage
11.   Priority & Severity
12.   What is a bug ?
13.   Test scenarios
14.   STLC,SDLC Bug life cycle
15.   Verification & Validation

The above mentioned are the few questions that are frequently asked during interviews. The answer for the above mentioned question will be posted in my next blog. :-)

Now at work:

Most of the organization follows the scripted testing and some organization support exploratory testing. Scripted testing is what the organization totally depends on test case. They believe that if all the test case is executed and if all the condition is satisfied, then there is no bug in the application or product. This could help to few extend but not always. Because there are many product that failed in the production even after executing all the test cases. 




Exploratory testing:

     Here the approach is quite different. Here the testing is done without the test case.
 Remember not only the testers, but everybody do exploratory testing in real time. But we don’t realize. Exploratory comes not by training from some experts.  It’s an individual creativity.  For example think what we do when we buy a mobile phone.
 To be short the test we do while buying a mobile phone is a part of exploratory testing.

 Things I do while I follow the exploratory testing for a web application. This is how I start

1 .Know the purpose of that application
2. Know who are the end users
3. Explore it
4. Decide which I will be testing
5. Fix a time (Session based).
6. Be focused, because I consider I am responsible for the quality.
7. Give suggestion


My approach while testing

Most of the web application will have a login page . If I am going to test the login page, I consider the below mentioned points.

      The login page should have
1.       User name field   
2.       Password field   
3.       Forget password
4.       Login button
5.       Sign up option



Other things I Consider:
6.       User name field – rectangle shape ,(A-Z,a-z,0-9) ,boundary (min & max),special characters , check for empty space,
7.       Password field   - rectangle shape ,(A-Z,a-z,0-9) ,boundary (min & max),special characters , check for empty space
8.       Forget password-Hyperlinked
9.       Login button-enable/disable
10.   Sign up option- Hyperlinked
11.   Spell check
12.   Cursor at the right side of the Username  and password field
13.   Spaces between the fields
14.   Length of the password/Username
15.   Proper error message. User understandable form
16.   Highlighting where the error occurred
17.   Copy & paste the data in the field
18.   Data disappeared once submitting the wrong data
19.   Password in dot or * symbol
20.   Text entered should not exceed the rectangular field
21.   Check box-enable /disable
22.   Remember username/password are the mandatory field.So,  if no (*) symbol is provided it’s not an issue.
23.    Size of the font
24.   Color of the font and the background page color
25.   Font style.

The above mentioned things are the ideas that I consider and I do a mind-mapping so that I don’t miss any of those points .

            Okay now we tested an application and we found a bug .Now it’s our responsibility to report to a developer. How do we need to report? Here plays another major role which we call as “Bug Report”. Writing a good bug report is a skill.  The report explains the stuff of an individual. Here I share my ideas on writing the bug report.





Bug Reporting-Checklist

When you find a bug and when you want to report it to the developers or to the concerned people, make sure that the report you are sending should be clear and in understandable format. The bug report should help the developers to understand the issues by means of report you send. Here is the checklist created for reporting the bugs.
Ø  Mention the environment (operating system).
Ø  Mention the browser you used along with the version
Ø  Summary: Summarize the bug. The summary should be short and meaning full. The summary should be able to explain the nature of the bug. Don’t exceed the summary for more than 30 characters.
Ø  Description: Here you can describe the issues. But make sure it should not be like a paragraph.
Otherwise it would be like a story. Where the developer might get board to read or may not have time to go through entire description. Explain the risk in the description part
Ø  Mention the severity.
Ø  Steps to reproduce: This is the best way to explain where the issue has occurred. This will help the developers to get into the specific place and help them to solve it.
Ø  Snapshot: Attachment is also a good way of representing the bug. This is also a proof saying that the issue has occurred. Because some bugs are non-reproducible. So in such case this would stand as a proof for those   issues. Good to send in .png format.
Ø  Give a meaning full name for the attachment  
Ø  Check for the grammar mistakes and spelling mistakes.
Ø  Write the report in normal English word. Don’t use any complex words. So that developers may not Google it in search of getting meaning for those words.
Ø  Go through your report before you send it to the concerned people.


  Writing a good bug report is a skill and it happens by practice “.
-Pradeep Lingan.