Tutorials

• Intro to Automated Functional Testing
• Get to know your tool: TestWise
• Five-Minute programming guide

Automated Functional Testing

Functional Testing here means the testing can be performed by testers, business analysts and customers (please note, NOT programmers) to verify that the web application does as required by customers. Automated functional testing is performing these tests using test scripts. There are many benefits of automated testing, especially for regression testing. As Steve McConnell says it in a nutshell (in his classic book: Code Complete) “The only practical way to manage regression testing is to automate it”.

Here are common steps testers follow to develop a test case:

1. Understand the requirement (know what to test)
2. Think and design the steps (think how to test)
3. Get application ready (preparation)
4. Drive the application (do what need to get there)
5. Verify the result against expectation (check what you got)

The first two steps sometimes are called ‘test design phase’; Step 3 onwards are called ‘test execution phase’. Automated functional testing differs (manual testing) from test execution phase. It is important to emphasize that test design phase is vital.

The same steps apply to automated testing as well, with some differences from manual testings. We will visit them in more detail in the context of testing web applications using rWebUnit (the test framework supported by TestWise IDE).

Step 3. Preparation: Set Initial State (‘Simpsons Pattern’)

Besides conventional preparation tasks such as test data collection, here we want to emphasize the ‘setting initial state’, ie. before test execution, the web application is in a known state.

Why? For automated test scripts, there are only two results “Correct” or “Wrong”. For a typical manual test, a tester may not write down ‘make sure no users logged in’ as a test step but doing it naturally as part of test execution anyway. Like robots, test scripts strictly follow the direction given. If previous test leaves the user logged in, then next test case is starting from different state, which will fail.

For people who watched ‘The Simpsons’ cartoons, will know what we mean.

How? In rWebUnit (it is RSpec syntax to be exactly), you can adding appropriate test steps in the following blocks to achieve.

• before(:all)
• before(:each)
• after(:each)
• after(:all)

Here is an example.

before(:all) do
  open_browser("http://TestWise.com")
end

before(:each) do
  login
end

after(:each) do 
  fail_safe { logout }
end

after(:all) do
  close_browser unless debugging?
end

Step 4. Drive the application

The test scripts ‘drive’ (interaction with web page controls such as textbox, checkbox …etc) the web browser to perform required operations. The execution process shall be same as done by a human except without human, testers can view the test execution in a real browser (IE or Firefox in our case).

Here are some sample driving statements in rWebUnit:

click_link(‘transfer’)

select_option(‘fromAccount’, ‘Savings’)

enter_text(‘amount’, “499.00”)

click_button(‘Submit’)

Step 5. Verification

In some frameworks or tools, this step is also called ‘assertion’ or ‘checkpoint’.

A typical web application verification is to check certain text present on the web page. It is important note that as web page is written in HTML, so the checking is really against the HTML source returned (to view a web page’s HTML source, right mouse click and select ‘View Page Source’). In rWebUnit test framework (TestWise uses), it is written as

  assert_text_present(“Payment Successful”)

or

  page_text.should include(“Payment Successful”)

Here are some more complex verifications

  assert_link_present_with_text(“TestWise with Id”)

  assert_checkbox_not_selected(“checkbox1”)

  assert !div(:id, “info”).visible?

Get to know your tool: TestWise

TestWise Main Window

TestWise ToolBar

Five-Minute Programming Guide

The test framework (rWebUnit) is using Ruby programming language, which provides powerful scripting and expressive syntax. If you know Ruby, Congratulations, you can skip this. If you don’t know Ruby, Congratulations!!, as you are going to learn a fast growing popular programming language, and it is not hard to learn, instead it is fun to learn and use.

We here list concepts and syntax (with examples) you need to get started on writing your own test cases, and you will learn more as you go. Good Ruby programming skills certainly will help you to write more creative test scripts. But we assure you that you don’t need much of that to get started, don’t be scared. TestWise also helps you on the way too.

Warning: This is intended to be 100% correct or a formal Ruby tutorial (and here is one by Chris Pine). Its purpose is for non-programmers to get some programming concepts

“Learn to Program” by Chris Pine.

• Comments

Comments are used to document the scripts and are ignored during test execution. In ruby script, Comments start with “#”.

In the following example, The first line is a comment, while the second is not.

#James, the following line return error, but I can't see why. Please help.
page_text.should include("Functional testing is fun")

Here is an example of appending a comment at the end of test step, and this step will be executed.

click_link_with_id(‘loginBtn1’) # there are two buttons with sample caption ‘Login’, so use ID instead.

• String

When we enter some text in text box on a web page, these text are treated as Strings, represent in script as quoted, such as “TestWise IDE”, “199.00”.

"James" + " Bond" # => "James Bond" 
1 + 2 # => 3
"1" + "2" # => "12" as it is string adding

• Scope

Any programming language has certain structures (so that it can deliver intended instruction to computers). A scope can be see a container of scripts, the variable defined in the scope is only available to the scope. A scope starts with ‘do’ and ends with ‘end’.

Our test case definition uses scopes, so that one test case does not mix with another one. Here is an example.

test “my test case” do

  #steps in the scope

  if true do 

    #in the inner scope

  end

end

• Variable and Assignment

In programming, the process of storing a value in computer’s memory for late use is called Assignment. The name we give to that value is called a variable. The syntax is as below.

variable_name = some_value

Here are some examples.

app_id = div(:id, ‘appId’).text # get application id from tag div

click_link_with_id(‘application’ + app_id) # try to click specific application

The following scripts assign a TransferPage to variable ‘transfer_page’, and call page functions (see below) on it.

transfer_page = expect_page TransferPage

transfer_page.select_from_account ‘Savings’

trasnfer_page.enter_amount “123”

• Compare Equal

As you see, ‘=’ is used for assigning value to variables. How can I check the values are the same? Using ‘==’ for equal, ‘!=’ for not being equal.

div(:id, 'receipt').text.should == '123'
div(:is, 'receiptDate').text.should == today #today is special function provided by rWebUnit

• Logical operations

Now we quickly move to more advanced topics. You are not very likely to use it in your first batch of test cases. But it is good concept to know. We will show some (quite readable) examples here.

fail('page has error') if page_text.include?('Oops')

if receipt_number > 100 then
  click_link('Bonus')
end

if page_text.include?('Success') then 
  click_button('Ok')
 else
  click_button('Cancel')
 end   

• Function

A function (or called ‘Method’) is a collection of piece of scripts may be reused.

Here is definition of function ‘login_as’ that takes two parameters (with one optional).

def login_as(login, password='password')
  enter_text('username', login)
  enter_text('pwd', password) 
end

Here are two usages of the function.

login_as('bob', 'thebuilder') # will try to login using username 'bob', password 'thebuilder'
login_as('john') # same as login_as('john', 'password')