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!