Recent Posts
Categories
Archives
- April 2011 (1)
- February 2011 (1)
- January 2011 (1)
- November 2010 (1)
- October 2010 (1)
- September 2010 (1)
- August 2010 (3)
lesson learned everyday
When tinymce is plugged into a webpage, selenium treats the tinymce as a new IFrame – this can be verified using Right-click on TinyMce and Inspect Element option – if you can fine this option, you might need to install Firebug add-on installed in Firefox browser
In order to enter text into tinymce editor, please follow below steps,
//Currently Selenium is instructed perform action on the application under test, now we need to //instruct selenium to perform action on tinymce Selenium.selectFrame(“Input your Iframe Id or name – can be found using Firebug”);
//let’s ask selenium to focus in the text area where we want to input text, generally it will have id //tinymce if this is different please update it to the way it is name selenium.Focus(“tinymce”);
//lets enter the text we want to Selenium.Type(“tinymce”, “enter your text here”);
//In order to perform other operations on the application under test we need to instruct selenium to change focus back to application under test Selenium.selectWindow(“name of the main window”);
I’ve used this code several number of time and it work – if you have any issue please feel free to comment I’ll try to get back to you latest
I managed to make it to my first Week night Testing session today. You can follow WT here
Facilitator (Sharath) provided a link to download the software Stellarium (here). Then we need to install, learn, test and discuss about approach used
We had 15 minutes to get familiar with application – yes, a quick start guide provided with application helped
Then we had 45 minutes to test the application and find functional bugs. At the end of testing, we’ve been asked below question,
- Did you enjoy the session?
- How did you learn the application? What do you feel helped you learn this application faster?
- Did u meet the mission? If yes how? If not why?
How?
- Bugs Pls?
This part of the session where we discuss the approach was my favorite for the reason you get to know different approaches used by testers participated in the session
Be focused and plan your testing so that you gain most from the limited time available
Some time back I heard about BDD (Behavior Driven Development) from one of my colleagues – done some Google and found below links which gives us a basic understanding of BDD,
“Behaviour-Driven Development (BDD) is an evolution in the thinking behind TestDrivenDevelopment and AcceptanceTestDrivenPlanning.” – from http://behaviour-driven.org/
Having spent some time understanding the framework BDD provides, below are my finding,
Writing a Requirement Specification Document of thousands of pages and maintaining them for every release is prone to high risk. BDD focuses on writing a Specification that expresses Behaviour of a feature, thus specifications can be used as Live Documentation replacing Requirement Specification Documents
Usage of common vocabulary to write Specifications will help in common understanding of products intended behaviour among Business, Developer and Testers
A request from business to update behaviour of a feature can sometimes be tricky and It is important to note that there is a high risk (depending on how urgent the release should happen) that one might not update Requirement Specification before sign off and release. In this case, once a release is done Requirements Specifications becomes out of date – Driving Development (Units tests) & Testing (Functional tests and Low-level Automated tests) efforts from Specifications mandate us to update the specifications (Live Documentation) first – This helps in keeping Requirement Specifications up to date
Personally, I also found creation of Test Automation Scripts from these Specifications can be done in very short span of time using different BDD tools like Cucumber, SpecFlow etc
Above mentioned points are some of the key benefits I can see in using Behaviour Driven Development – I’ll keep this post updated every time I find something interesting.
MS Test executes tests in random order which can’t be predicted – below example explains how this could be a risk.
Consider we’ve 2 tests as below
Test Class 1 Test Class 2
—————- ——————–
Class Initialize 1 Class Initialize 2
Class Cleanup 1 Class Cleanup 2
Test Initialize 1 Test Initialize 2
Test Cleanup 1 Test Cleanup 2
Test Method 11 Test Method 21
Test Method 12 Test Method 22
Assuming that MS Test runs Test Method 11 first, execution order would be Class Initialize 1 –> Test Initialize 1 –> Test Method 11 –> Test Cleanup 1 –> ??? Here MS Test can execute Test Method 12, Test Method 21 or Test Method 22
Want to automate acceptance tests using any Selenium RC and MS Test Framework – consider following risk,
Unpack, Edit selenium-server api, Repack selenium server
Concern – selenium.open command times out after 30 sec waiting for page to load. I wanted to update the command to wait for maximum of 120 sec
After a couple of hours of googling to find how to unpack selenium-server, update selenium and repack selenium-server – I found following steps which does the work for me,
Step 1:
If you haven’t already done get the download selenium server from here
Step 2:
Copy selenium server into temp folder and unpack the server source using following command,
jar xf selenium-server.jar
Step 3:
selenium.open method is by default set to wait for maximum of 30 seconds – however, in this post i would like to update the command to wait for maximum of 120 seconds. To do this,
go to folder core\scripts\ and open selenium-api.js
search and edit Selenium.DEFAULT_TIMEOUT value to 120*1000
Here, you can change the value 120 to 180 or 60 depending on your requirement.
Step – 4:
Repack the source to selenium-server.jar by using following command,
jar cfm selenium-server.jar META-INF/MANIFEST.MF *
This should now create a new selenium-server.jar file new timeout
Note – Timeout value set in this instance applies for selenium.open command only and doesn’t affect selenium.waitforpagetoload command
Happy testing…
James Bach has posted an excellent video edited explaining about Career path for Testers
I came across an excellent article by Gojko with regards to impact of change in UI designs on Test automation,
http://gojko.net/2010/07/29/the-sine-of-death-by-ui-test-automation/