Thursday, July 26, 2012

Getting Eclipse to run Webdriver (with Java)

1. Install Eclipse (from eclipse.org)
   (To work with eclipse in Java you will need the Java Developer Kit (JDK) - http://www.oracle.com/technetwork/java/javase/downloads/jdk7-downloads-1637583.html - uninstall previous version if there is one)
2. In Eclipse:
      -> New Java Project
      -> On this screen give your java project a name ('webdriver')
      -> Finish
3. Download webdriver (http://code.google.com/p/selenium/downloads/detail?name=selenium-java-2.25.0.zip&can=2&q= )
4. Unzip the file
5. Right click in the project in Package Explorer and choose Build Path --> Configure Build Path
6. Click on Libraries tab
7. Click 'Add Jar files' (or if you cant find your jar files 'add External Jar Files'
8. Add all your selenium webdriver jars
  javadoc location is http://selenium.googlecode.com/svn/trunk/docs/api/java/
9. From there you can start using your Webdriver files

Monday, February 20, 2012

Everything you need to setup Django on Ubuntu with Postgresql

This is a very simple run down of everything I did from a basic Ubuntu 10.04 setup to get Django running on my server.

  1. sudo apt-get install apache2 
    This will install apache on your server
    - The httpd service should automatically be started. You can test it by going to the IP of your server (localhost if it is on your computer)

  2. sudo apt-get install postgresql 
    This installs PostgresSQL 8.4.
    I chose to use PostgreSQL. You may use different types of databases for your setup.
    If you are not familiar with Postgres, please visit www.postgresql.org for more information.
    We want to make sure that we can connect to postgres from localhost. While logged in to the machine with Postgres on it, do the following:
    pico /etc/postgresql/8.4/main/postgresql.conf 
    This will open the file where you will need to add access to localhost. Locate #listen_addresses = 'localhost' and remove the # symbol. This will tell postgres to allow connections to the databases as long as the connection is from that server.

    We still have more ways to go. PostgreSQL has a server role of 'postgres' that we will use later to connect to the database. However, there is no password (or the password is unknown). We need to connect to it as an admin and change the password (we will also connect to a default database on postgres - 'template1'). The next step will be to change the password.
    >#sudo -u postgres psql template1
    >template1=#ALTER USER postgres with encrypted password 'your_password';
    The confirmation to above will be 'ALTER ROLE' printed on it's own line. (Type \q to quit)
    Now we want to use MD5 authentication for postgres
    pico /etc/postgresql/8.4/main/pg_hba.conf 
    we scroll down to 'local    all    postgres     ident' and change 'ident' to 'md5'
    Now to reset the connection:
    sudo /etc/init.d/postgresql-8.4 restart
    To test the connection simply type
    psql -U postgres
    You will be prompted to enter the password, after which you will be in 'postgres'
    Most of this information is from https://help.ubuntu.com/8.04/serverguide/C/postgresql.html
     
  3. Install Django (2 options)
    sudo apt-get install python-django
    This will install Django 1.1.1 (depending on what version linux you are on). If you just want to play around it's fine. If you want to install a specific version of Django (as I needed to do), you have to do the following:
          - Go to Django website ( https://www.djangoproject.com/download/ )
          - Find the exact download path of the version you need to download
          - Use "wget exact.address.to/file.zip"
          - Use 'tar' command to extract the file.
               * tar xzvf Django-1.2.7.tar.gz
               * cd Django-1.2.7/
               * sudo pyton setup.py install
          - Go into the folder you extracted, and run "python setup.py install"
  4. For some features in Django you might need more plugins such as psycopg2 (I believe* this step is optional for most)
Now you are ready to start actually setting up your project [I will be making another update for that]

Tuesday, December 20, 2011

Conception of how to do a Testing Suite with Selenium

Thoughts on organizing and starting an Automated Suite from ground up.
  1. Develop test scripts using webdriver (although it is still in its early stages, this is where selenium is headed).
  2. Develop in Python. Reason for this is that the language/platform used for the website is Python/Django. Once developers are in-house, they can be asked some questions if needed.
  3. Split out everything possible to the smallest possible elements (such as 'selecting a dropdown' would be part of my company's selenium library, same as 'login', 'logout' scripts)
  4. Create a Page class that stores all the paths to elements used in current script. When the path is changed, it will be very easy to change it once it's there.
  5. Develop error catching to make it as explicit as possible so that there is no need to dig in as to what actually happened and where it happened (plan is to use screen shot capture capability for most non-obvious errors)
  6. Additionally there will be a need for time measurements to get the approximate feel for how long will it take for pages to load. This will be stored with each sequential running of the test to see if it's going down/up/etc.
The way I see the tests being is
--> General Script that calls a lot of minor scripts
             Example: "Login", "Run Send Email Script", "Run Check sent email script", "Logout"
  --> Specific Scripts will contain general actions (they will see the 'Page' class)
        These scripts will contain parameters such as user name, password, any other relevant parameters (so that they can be re-used if needed).
                   Example: "Login" script will have 'driver.find_element_by_css_selector(email_input).click()'
    --> Page class will contain the actual paths to the elements (css when possible, with comments if it's not)
                 Example: "email_input" will be email_input="input.id_email"


Friday, November 11, 2011

Where to start with inception of a feature ||cue suspensful Inception music||


Let me ask you a question. For quality assurance what do you need before you have the specs to test? How about what do you need to visualize the potential pitfalls later. Mockups!

Now from my view there are several degrees of pulling this off
1. An actual list of requirements (necessary, but not sufficient)
2. A very basic wireframe with a lot of text surrounding the wires telling you what the wires are for. This is a good start but not good at fleshing out scenarios.
3. A mockup as close as possible to the way the form / screen would actually look.
4. A working prototype simulating the behavior of the feature.

We start with requirements, the 'duh' of a feature request. I don't want to go down the road of no list of requirements, it will lead to a dark and lonely place of talking to yourself at night.
Then there's the basic wireframe. For straightforward functionality this might actually be sufficient. You give the programmer and the QA some sort of visualization of a product. At this point, if there is more complicated functionality which usually would not come out until actual implementation it's better to go farther then just wireframes.
In comes Balsamiq Mockups. I really love this software. It gives you an opportunity to put what you are thinking about and make it look real. PERFECT tool for non-technical people. There is no need to know anything technical, it is drag and drop. It allows you to create as many details as you want, as well as if something is a note/question, you can "stick" a post-it note! I believe this is an important step in creating a design document that both QA and Programmer can look to. It clears confusion as to where the buttons should be, what is assumed and what is not (at least as far as the screen goes). With that said nothing is perfect, there will be revision and some more revision.
The last level is a full fledged prototype. This part, done correctly, is beautiful. You get the mock feature that is functioning. Problem is that you will need a different set then for the above 3 options usually. This person would have to know HTML, and usually javascript to throw in some more complicated functionality.

All these 3 levels depend on how complicated what you want is. If it is 'add a cancellation button' - just the requirement is enough. If it is 'create a login screen', a wireframe might be more fitting to show the approximate field/button position as well as logo and whatnot. If you are working with a form that has multiple fields, then you would want something that is more exact graphically. If it is complicated functionality/switching between screens/will need significant changes and testing, then look to creating a prototype.

Hope this helps someone.
Cheers!