Recently in Software Category

There are many easy to use testing automation tools on the market.  There are many powerful testing automation tools on the market.  There are, however, rather few that are both.  Selenium is one that stands out, though and it is the tool that I most often use.  In this tutorial, I'll demonstrate a quick way to create simple tests using the tool.

OK, those are the parts, let's get busy with an actual test.  We'll keep it simple and start with a single testcase.

*For the following instructions, things in RED should be steps that you take in FireFox. Items in BLUE are steps that you'll take in the Selenium IDE window.

1. Open Firefox to www.google.com
2. Open Selenium IDE by going to "tools" and clicking on "Selenium IDE"
3. Verify that your Base URL is set to "http://www.google.com"
4. In the search bar, type "Eddy Jones" and hit [ENTER]
5. Click the first link that will take you to estevenjones.com
6. Highlight the title "The Blog" on the estevenjones.com home page
7. Right click on the highlighted text and select "VerifyTextPresent The Blog" (this is one of the new Context Menu items that was added when you installed the Selenium IDE
8. Click "Hubble Space Telescope" link in the story about the Hubble Space Telescope (or any other link on any other story)
9. Right click on one of the images and hover over "Show All Available Commands >"   and from there, select "AssertElementPresent <some identifier here>"

In order to play back your tests, simply press the green arrow "play buttons" on the toolbar.

WHAT???  Why did my tests fail??

Well, your tests probably failed here, but that's ok.  This really demonstrates the speed of Selenium.  Your test most likely failed because Selenium tried to move on to the next step before the web page finished rendering.  So it tried to click on your next link before the link was actually on the page.  There are two ways to handle this.  The quick but bad way would be to adjust the speed of your test by adjusting the slider on the toolbar.  This would allow the web pages a chance to render prior to Selenium trying to act on it.  The better way to handle this would be to change the "click" commands to "ClickAndWait" commands, though.  This way, Selenium will wait for the page to completely render before moving on to the next command.  One thing to note about this method, however, if you are testing a page that has frames, you might run into problems with FireFox.  FireFox says the page is completed once the Frameset is complete rather than waiting for the contents of the frame have completely rendered.

Also before I sign off for this first tutorial, I'll mention the difference between Assert and Verify

When you ASSERT that an element is present, you are telling Selenium to stop the test and proceed no further if the assertion is not valid.  So, if I assert that an image is present and that image is NOT present, Selenium will not move on and all testing will stop.  The test will be marked a failure.

When you verify something is present, you are looking for something that is not terribly important enough to stop the entire test if it's not.

An example of when I might use assert versus using a verify:

If I loaded a web page displayed a render time, I might want to verify that the render time was under 5 seconds, but I wouldn't necessarily think that it's a total failure if it took 6 seconds to render.  I would want to use an assert to verify that it didn't take longer than 10 seconds because 10 seconds is way past my threshold for acceptable render times and there is no point in continuing my tests if it takes longer than that.

Stay tuned for the next session: "Creating Tests Suites"

No matter what you are using to keep track of defects that you find in your software, there are certain things that you should keep in mind when you are documenting a defect.

1. A CLEAR AND CONCISE SUBJECT LINE / TITLE
   This might be the most important part of creating a good defect report.  With this, the people responsible for fixing the bug/defect and quickly group several similar or identical problems into one investigation.  A good description will have at least 2 elements:  An action taken and a result
   
   EXAMPLES:
   Bad:  The website isn't working.
   Good: Clicking on 'Home' link takes me to a "missing page" error page
   
   
2. CLEAR AND CONCISE STEPS TO REPRODUCE THE ISSUE
   More often than not, a majority of the time it takes to fix a defect or bug occurs in the "trying to reproduce it" phase.  Even if we track you down to have you give us a demo of the problem and that demo only takes 2 minutes, the time it takes to actually catch up with you and get that 2 minute demo stacks up quickly.  So, in the body of your defect, you should give developers more information than you think they could ever use.
   
   EXAMPLES: (We'll continue with the bug started in step 1)
   Bad:  I clicked home and was taken to a blank page.
   Good:
   1. I opened up a browser and navigated to our live site ( http://www.ourdomain.com )
   2. I logged into the site using the "Login" link
   3. I clicked on the "Message Boards" Link
   4. From Message Boards, I opened up the article "Summertime fun spots"
   5. I clicked on the "Add Comment" button
   6. I typed in a comment, but didn't hit [submit]
   7. I clicked on the "Home" button in the menu bar of the site
   8. I saw a blank page that stated the page was not found
   9. In the address bar, there was this URL:  http://joedeveolper.dev.ourdomain.com/home.html
   10. I'm using Firefox for my browser on Windows 7.
3. A RECORD OF REPRODUCTIONS
   There is an old and sometimes joked about adage that states "It's not a problem if was can't reproduce it." While this may seem rather flippant and careless, there's also a huge grain of truth in it.  Sure there may have be an actual problem, but in the terms of prioritization, I'm sure it's easy to see that a defect that is either un-reproducible or difficult to reproduce is less important to fix than something that happens all the time.  Of course, this is an over-simplification as a bug that wipes out all of your data, even if it is almost impossible to reproduce is pretty damn important.
   
   EXAMPLES:
   Bad: I think I heard someone else had this problem
   Good: I was able to reproduce this on Internet Explorer, too.
   Best: I was able to reproduce this on Internet Explorer too.  I also got Sally and Jim to reproduce it on their computers, as well
   
4. SCREENSHOTS OF THE PROBLEM
   If the problem is visual in nature, it's always a good thing to include a screen capture of the problem.
   
   EXAMPLE:
   "The background color for the Name and Description columns do not match on the albums listing page."
   
   
5. ADVANCED TECHNIQUES: Recording a macro to reproduce the problem automatically
   There are many tools out there that will allow you to record all the clicks and typing you do on your computer.  Recording these actions could prove to be very helpful to the people trying to fix your defect.  Even if you list all of your steps as accurately as you believe is possible, there might be something that you do, thinking it's insignificant, that the developer will catch on and realize exactly what the problem is.  Perhaps you clicked on the graphic of a button rather than its, text.  Perhaps you submitted a form by hitting the [Enter] key on your computer rather than clicking the [submit] button on the web page.  Another major benefit of recording your actions is that your recorded actions are now documented, and it might be possible to create an automated test from them.  With an automated test, your defect might be caught next time before it ever gets to a production environment.  Keep in mind, these tools record your actions ( move mouse here, click here, type this ).  It does not record a video of what you see.
   
   SUGGESTED SOFTWARE:
   
   Bad Boy a very nicely done tool that is, unfortunately, a windows and Internet Explorer only tool.
   
   Selenium IDE:  This tool is also a very good program.  It sits on your system as a Firefox Plugin.  So initial recording of a defect will be done in Firefox only, but it can be played back using several different browsers.
   

These techniques and suggestions are not the be all and end all of 'best practices' for reporting a bug or defect, but they will certainly get you further down the road in being a productive partner when it comes to making sure your company produces the highest quality software.