TestWise IDE

Next Generation Functional Testing Tool

Intro to 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:

Understand the requirement (know what to test)
Think and design the steps (think how to test)
Get application ready (preparation)
Drive the application (do what need to get there)
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 RWebSpec (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 RWebSpec (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' (interacte 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 RWebSpec:

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 RWebSpec test framework (TestWise uses), it is written as

assert_text_present("Payment Successful")

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?