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.