What is Monkey Testing and its types

Few days back I come across an interesting term “Monkey Testing”, some people prefer to call it as “stochastic testing” a more technical word used to refer this type of testing.
The name 'monkey' comes from an old traditional saying that is accepted by many as true or partially true that ‘a thousand monkeys at a thousand typewriters will eventually type out the entire works of Shakespeare’.

Monkey Testing
In software testing world we (Testers) when talk about monkey testing referring to a fully automated testing tool. In fact this type of testing fall in the category of automated testing and black-box testing, the word monkey is used to refer a fully automated testing tool.

There are different types of monkey testing
i. Dumb Monkey Testing
ii. Semi Smart Monkey Testing
iii. Brilliant or Smart Monkey Testing

Dumb Monkey Testing
In Dumb Monkey Testing, dumb monkey do not know anything about the application, here the inputs are generated from a uniform probability distribution or Infinite Monkey Theorem. You can run these tests the whole day or even for more time. A dumb monkey, with its continuous repetition, can expose bugs such as memory leaks that might not occur until many hours or days of normal use.
For Example, using Quick Test Professional (QTP)you want to check for memory leak, what you need to do is just run a loop with thousands of values and leave it for hours (well its very fast, it adds the records in seconds), it will enter same records according to the loop (if duplication check is not applied).

Semi Smart Monkey Testing
We can make our dumb monkeys as semi smart by adding some functionality to them.
For Example, if I am talking about QTP we can write some script for a specific project according to its needs, lets say if you want to add many employees using automated tools you can make a table, enter all the different values to the table and import that table in the script of QTP it will work and add different values one by one and generate a report about all the values in the table and tells that with this value test passed and with this value test fails specifically.

Brilliant Monkey Testing
It works and uses software like a user can even more quickly. You can program it as you want like where to start and then where to click then where to go, enter data and submit the form so on and where to stop, so its very SMART :), Great. You just need to program it. Most of the commercially available load and stress testing tools depend on this smart monkey technology.

Good Paper on Monkey Testing
Beautiful Article on Monkey Testing

How to Apply Synchronization Point in web and desktop Applications in QTP

What is Synchronization Point: Synchronization Point instructs QTP to pause until an object property achieves a specific value.

Why we use Synchronization Point: We use “Synchronization Point” to maintain the time coordination between testing process and our application process.

Different ways to Apply Synchronization Point:
Basically there are 4 ways

1) sync (only for web applications)
Syntax: Browser("Browser").Page("Page").Sync
Description: “sync” is more dynamic than wait. In wait we have to wait for specified time even if the process has been completed in less time but with “sync” the page will move on after completion of a process. It is very good to apply but unfortunately we can’t apply it in desktop application.
For example, if we apply wait(60), to process and open some utube video, when we will run the test, it will wait for complete 60 seconds and do not move to the next page even the video opened but with sync
How to Apply: We can apply “sync” by editing the code in expert view
Example: Browser("Google").Page("UrduPoint Network, Urdu").Sync

2) Wait
Syntax: wait(n)…… same for Web and Desktop applications
Description: This statement instruct QTP to stay (waits) on the same page for specified 'n' seconds even though process has occurred in less than n seconds
How to Apply: we can apply “wait()” by editing the code manually in expert view after a test is recorded.
Example:
For Web Application: wait(10) ….. it will stay on the same page for 10 seconds
For Desktop Application: same as above

3) Wait Property
Syntax: Browser("Browser").Page("Page").WebElement("WebElement").WaitProperty "property name", property value, timeout(time in miliseconds)
For Desktop: Window("Window").WinObject("Window Object").WaitProperty property name", property value, timeout(time in miliseconds)
Description: Here wait property contains 3 things as you can see above, the Property Name list contains the test object properties associated with the object. Select the property which you want to use for the Synchronization Point.
Next comes the Property value for which QTP should wait before continuing to the next step in the test.
Then enter the Synchronization Point timeout (in milliseconds) after which QTP should continue to the next step, even if the specified property value was not achieved or if the specified value was achieved in less time even then it will wait for the specified milliseconds.
How to Apply: Synchronization point can be added while recording without writing any code from “Insert  Synchronization point” it will open your web page, here click the object  “object selection – Synchronization Point” pop up opens  here select the object  after clicking on any object “Add Synchronization Point” pop up opens  here select property name, enter property value and timeout. We can also add wait property by editing in expert view after a test is recorded.
Example:
For web Application: Browser("Google").Page("UrduPoint Network, Urdu").WebElement("WebElement").WaitProperty "abs_x", page, 50000
For Desktop Application: Window("Flight Reservation").WinObject("Insert Done").WaitProperty "text", text,30000

NOTE: There is a mistake done by beginners is to apply and try to find synchronization point after stopping the recording.

4) Exist
You can enter Exist and/or Wait statements to instruct QuickTest to wait for a window to open or an object to appear. Exist statements return a boolean value indicating whether or not an object currently exists. Wait statements instruct QuickTest to wait a specified amount of time before proceeding to the next step. You can combine these statements within a loop to instruct QuickTest to wait until the object exists before continuing with the test.
For example, the following statements instruct QuickTest to wait up to 20 seconds for the Flights Table dialog box to open.
blnDone=Window("Flight Reservation").Dialog("Flights Table").Exist
counter=1
While Not blnDone
Wait (2)
blnDone=Window("Flight Reservation").Dialog("Flights Table").Exist
counter=counter+1
If counter=10 then
blnDone=True
End if
Wend

Bug Found In Pakistan's # 1 Job Site

Few days back i have created my account in some famous job site, they declare them as Pakistan's # 1 Job Site.
Here, one have a choice to upload more then one CV. This is a privilege given to users so that they can select different CV for the related job. For example, one person have experience in Graphics and also in java programing and she want to work on any of the two then she have two different CVs to apply, but see what happens here, i have uploaded my CV only one time, "same CV is shown many times".
I have seen this problem many times while testing different applications in my office, and reported as bug and get it fixed as well. 

Computer Weekly IT Blog Awards 2009

Computer Weekly’s blog award ceremony is going to be held on 25th November
in association with IBM , they want to know who you think are the best bloggers and Twitter users in the UK IT industry, so to kick off the Awards they are asking IT professionals to submit their nominations to them. Interestingly, Blogs do not need to originate in the UK, but they must contain some coverage of the UK IT industry and Self-nominations are also permitted.
Check out the details here

How to write an Effective Bug Report - Part 2

Whenever you are reporting a bug always try to attach a screen shot, by using this method you can pinpoint the bug very easily, its a very good way to elaborate your bug that where the bug lies and highlight the particular area in the screen short where the bug lies and write the bug detail (steps which you follow to reproduce a bug) with that.
             You should use different tools like Microsoft Paint or Cropper or any other of your choice to highlight and elaborate the particular bug area. Find some good tools here

1.    In the description area just write something like
“Module Name --> Page Name --> Problem in Short --> Attachment notification”,
For Example “Poll --> Create Poll --> Confirmation message is not shown --> Please view the attachment for clarification (or details)”.
In this case, its easy to describe the bug for a tester and also there is some better understanding for the developer. He/she (the developer) can easily switch to the page where the bug lies in complex applications without wasting much time in finding out the particular bug area. See the example below,

2.    Do not highlight more then one issue in one screen shot. In this case developers fix 1 highlighted issue (bug) and leave the other. Let me give you an example for clarity, see the figure below  

   Here there should be two separate bugs and screen shots, one for the “Cancel” button and the other for the “Reset” button.
3.    In the comparison cases, screen shot method is very handy. For Example same drop down show different options on different pages, look and feel of different pages in the same application etc. By using this method you can elaborate your point in a very effective way without writing long details. Have a look at the figure below,

How to write an Effective Bug Report - Part 1

Use some reporting tool of your choice like Bugzilla. There are many free reporting tools available, some of the useful links are as follows,

Bugzilla

Bug Genie

Three free bug-tracking tools
126 Hand-picked Defect Tracking Tools
9 Free And Open Source Bug Tracking Softwares

1. After installing bug tracking software, do read its Bug Reporting Guidelines section, it will really help.

2. Select component, platform, OS etc

3. Set priority (most of the times it is assumed the duty of a tester but its logically incorrect).

4. Set severity
Here arise some questions like, What is priority? What is severity? What is the difference between priority and severity? What considerations should one have in his mind while setting priority and severity?

Severity is the one that states how bad or critical, is the bug. It is usually reported by the tester to the developing team. Priority is the level that determines which bug needs to be fixed first, whether it is of high priority or can it be resolved (not fixed in this release) or can it Wait (low level), it is usually determined by the developing team or the Project Manager. For details on severity and priority you can click here.

5. Summary should be precise and compact. A good summary should quickly and uniquely identify a bug, means after reading summary reader gets an idea about the whole bug just like the name of a novel gives you an idea about what you are going to read in next 500 pages.

6. Description should contain comprehensive details. Here your first audience, the developer who fixes the bug, needs clear and unambiguous steps to follow in order to reproduce the symptoms. The more information you provide the better it should be. The developer needs precise detail about “what you did” and “what you saw”. Your second audience, the person or group who decides the fate of the bug, needs to understand the consequences of choosing not to fix the bug. This audience needs information that can grab their attention and also help them see implications of not fixing the bug at the time you reported it. So the key point here is, that your description should be clear and easy to understand, do not use big difficult words so that the developer needs to consult a dictionary to understand the bug :)

Here I want to divide description in two portions, Without Screen-shot and With Screen-shot.

	1.	In first case (Without Screen-shot) Write complete description in the description area and do not attach any screen-shot with it. In this case somehow it will become difficult for the tester (reporter at the moment) to report and cover the bug completely and at the same time developer also faces some difficulty while understanding the bug, I am not saying that developer didn’t understand your point in the bug but he have to spend more time to understand and may be bored while reading the bug. As a reporter it is your duty to convince the developer to read the whole text or focus on your reported bug.
	2.	About the second case (With Screen-shot) I will tell you a very effective way to attract the developer in my next blog (because this one is becoming very lengthy) and that is very important, so don’t miss that.

7. Do not report two bugs in a single bug report, in this case developers fix one bug and leave the other, I had been a victim to this.