By Shalini Rawal

I wanted to share my understanding of USE CASES and get valuable inputs from you. I found use case very interesting and an easy way to design test cases. The name sounds a bit awkward. Doesn’t it? So then what does it mean?

Use Case is a very effective elicitation technique which can be used throughout SDLC. It describes “who” can do “what” with the system in question. The use case technique is used to capture a system’s behavioral requirements by detailing scenario-driven threads through the functional requirements. It is very effective where multiple user classes are involved. As compared to other approach (Requirement Itemisation) of test case designing from SRS, use case has some advantages:

• Easy to write

• Expressed in language of the user

• Can be visually represented

• Can be used for validation (acceptance testing)

• Tools support

• Ideal for OO development

• Where the system is functionally oriented (different types of users, complex behavioral patterns)

We should not use a Use Case when system has few users and is dominated by Non-Functional requirement. Now let us see the various entities involved in a Use Case.

• Actor: An Actor is someone or something that interacts with the system. Example of actors are People (Users), Devices, Other Systems, Organizations. Actors live outside the boundary of the system being defined and they initiate an action. Types of actors are Primary actor and Supporting actor.

A PRIMARY ACTOR is one who calls on the system to deliver a service. i.e. it has a GOAL with respect to the system. A PRIMARY ACTOR is typically who triggers the use case

Examples: A caller initiating a telephone call, a customer withdrawing money from the ATM

(Note: Use cases help identify Primary actors early in the lifecycle)

A SUPPORTING ACTOR is an external actor that provides a service to the system under design.

Examples: A high-speed printer, a web service

(Note: We can use supporting actors to identify external interfaces and the protocols the system will use. An actor can be primary in one use case and supporting in another).

• A GOAL is:

• What an ACTOR wants to get with the help of the system

• An ACTION is

• what the ACTOR must perform to reach the GOAL

• An INTERACTION is

• a sequence of steps that must be  followed to complete the ACTION

Examples of USE CASEs are:

1. “Purchase Goods” Level: User Goal

1. Visitor enters customer information (name, address, etc.).

2. System retrieves customer’s profile information, and presents product search and selection mechanisms.

3. Visitor selects products until satisfied. After each selection, system adds the selected product to the customer’s shopping cart and presents the ongoing running total of products selected.

4. Visitor selects to purchase the selected items.

5. System presents contents of shopping cart and requests customer’s payment information.

6. Visitor enters manner of payment and other payment details.

7. System presents visitor with final sums, charges credit card, and delivers packing list to the shipping department.

2. “Book flight!” referencing “Find a flight-”

“Book flight!” Level: User Goal

1. The customer contacts the travel agency and requests a flight.

2. The customer finds a flight-.

3. The system presents the travel options to the customer.

4. The customer selects a flight.

5. The system builds and reserves flight itinerary for the customer.

7. The customer provides a credit card number.

8. The system charges the flight against it and issues the ticket.

“Find a flight-” Level: Subfunction

1. The customer requests to find a flight.

2. The travel agent captures the customer’s trip origin and destination.

3. The travel agent looks up the airport codes for the origin and destination.

4. The travel agent captures the preferred departure times for the customer.

5. The travel agent captures the customer’s preferred class of service.

6. The travel agent confirms that the customer’s preferences are correct.

7. The system gets from the airline reservation system and presents a list of the available flights that match the customer’s preferences.

To summarise, Use Cases are very helpful in deriving test cases from specification. Some of the good practices for writing Use Cases are:

• Make the use cases clear, short and easy to read: Use active voice, present tense, make sure actor and actor’s intent are visible in each step.

• Every Use case has two possible endings: Success and Failure / alternate courses. Don’t forget to gather both.

• Create a list of primary actors and their goals (actor-goal list).

• Restrict use cases to capture system behavior….use cases are not suitable for other type of requirements.

• Use a common template.

By Ravinder Singroha

Software Development approaches have been changed significantly throughout the last decade. Projects typically took several months or even years to complete. After completion of projects, only those projects consider successful which implemented all the given requirements correctly and completely. Until the recent emerge of e-business, Software development project were mainly targeted at the well known business process (Classical approach). Although this method has been applied somewhat successfully to software development projects in the past, the approach is not suitable for commercial projects in the era of e-business process where things are moving fast. Also due to the fact that many projects development efforts are using leading edge technology that is yet not well understood or even evolves during project lifetime and the underlying business models typically rely on a quick time to market, it is impossibly to pin down the complete requirements list at the onset of the project. Projects goals and system functionality need to be frequently adapted, in order to stay competitive in the market.

Well so far so good, before I joined Company even I had read this all about ‘Agile’ or ‘XP’ development technology. But to read and to actually do it is two different worlds experience all together trust me on it.  Reading is easier…

I joined Company as part of a team, which was planning to develop software. The platform we used was dot net + excel as backend. As I was new to the Dot net and language we are using vb.net, first of all I need to learn vb.net as soon as possible I was give one full day for that. I then demanded the requirement document of the project, my Lead told me that there are no such documents, I was little surprised and my TL was even more surprised than me! Work kicked off aggressively. We had a month to complete the first phase; the team started coding the s/w as per the so-called “current requirements”. We had a very dynamic manager, which just added to the agility of the project. Every third day he use to get some new ideas and we had to incorporate the same mind you without changing the time lines. Well I still would like to ponder did we ever had any real time lines!

The first major change which stuck was changing the backed from excel to a much lighter ‘xml’
It was although the very first but not the last bolt of lightening which stuck the team. After successful completion of the phase one and demo, the manager asked us to change the UI altogether so that it is more tested focused! Well till then I had taken my Miranda so ‘zor ka jhatka dheere se laga’. By continuing this agile mode of development we had also become agile i.e. alert for any and easily accepting the changes.

Then came into picture the testing team, well no requirement doc for the team to refer, But I tell you what a marvelous bunch of guys they were, not only they picked up the technology well they left no stone unturned to make our lives hell. In this situation where one side the manager was bombarding us with new features, the other side the testers with their bugs only I know how I survived it all. Every day we had a stand up meeting where the status reports were discussed the progress was monitored closely and issues were discussed and solved too in just those holy 15 minutes.

Well I can keep on writing my experience but my lead has given me just 4 mins to write this, how agile has she become oh god help me, just to summarize my experiences:

1.    Be ready for any type of change
2.    Be positive
3.    Get feedbacks frequently
4.    Try to think as your manager thinks
5.    Write Down All the Changes.
6.    Update Your Timeline As per changes, keep track on the timelines, and estimate the impact of changes on application.
7.    There should be very effective communication between team and respective manager.
8.     Frequent standup meeting for max. 15 mins.
9.    Every body should be present in the meeting.

And the most important thing, it is very vital to have a highly motivated and good leadership skills manager. Hasn’t it been our manager undying enthusiasm and support this product in agile mode wouldn’t have been possible. He gave us credit too though by giving us the “Performance Award” for the quarter.

Anyways readers, I sign off as an agile developer, changes are calling me.

By Vivek Goyal

I am a tester and recently, I was asked to prepare SRS of a new feature which was getting introduced in the product. While working on the preparation of the SRS document, I realised that it’s very difficult for me. But slowly I understood that I should communicate frequently with the client and ensure that everything regarding the project was clearly understood by me.

An SRS is a very important document for the implementation the testing of that project. A good SRS can usually be prepared by an experienced person. While creating an SRS document the communication with the Business team and the developers is extremely important as they are the only people who can tell you exactly about the project and what the requirements are.

In case of testing, if tester has a good SRS with him then he can do testing effectively. A Tester should know what, is the exact functionality of the application and what are the major points he has to keep in mind while testing so that project doesn’t get any issue after launch in market. All flows are also clearly mentioned in the SRS. If tester has SRS with him while testing, he don’t get any problem or issue and there is less need to communicate with the development or business team while testing.

We may also face some problem while creation of SRS. It may be possible that first time all the requirements are not clear to you. It may be possible that in every meeting some requirements may change and you have to make changes in SRS corresponding to that change, change may be minor or major. The documents which are provided by either development team or by the business team also help in creating a more comprehensive SRS.

After the first phase completion of SRS you should send it to the business team which is working on that project. Business team reviews the SRS and if they want any change in it, they list it out and the changes should be incorporated by the author. If they find complete requirements and other information regarding project in SRS they approve the SRS. After approval it’s not easy to make change in SRS and not advisable also. If in future you want to make some changes in the requirements of flow of the project, firstly you have to take approval from senior manager of that project and after the approval from him the changes can made to the SRS, if he reject those changes then SRS cannot be updated.

While working on SRS, we have to keep some points in mind for making it effective.

These points are as follows:
•    You should know purpose and scope of project.
•    You should have all the requirements for project.
•    You should know the flow of application.
•    You should know all the people/teams involved in the project.
•    Talk, talk and talk it all out. Don’t assume things on your own.
•    Proof read the SRS before mailing it for approval.
•    Delicately maintain the various iterations which a SRS goes through, so that you don’t miss out any changes.
•    Remember, it’s not the creativity which people look for in a SRS, it’s how logically you have summarized all the technical flows in the application.

By Sudha Sharma

What is FitNesse?

FitNesse is a software testing tool. Agile web teams use FitNesse to create comprehensive test suites that make system-level assertions. FitNesse creates a feedback loop between customers and programmers and allows customers and testers to use tools like Microsoft Office to give examples of how a program should behave–without being programmers themselves. FitNesse automatically checks those examples against the actual program, thus building a simple and powerful bridge between the business and software engineering worlds.

With FitNesse, customers can provide more guidance in development process by lending their subject matter expertise and imagination to the effort.

FitNesse enables customers, testers, and programmers to learn what their software should do, and to automatically compare that to what it actually does do. It compares customer’s expectations to actual results.

FitNesse is basically :
•    A WIKI (HTML Page) designed for acceptance testing.
•    Includes a built-in web server.
•    Open source.
•    Written in Java 1.4
•    Sits on top of Ward Cunningham’s Fit Framework.
•    Creates a feedback loop between customers, testers and programmers
•    Provides a one-click test environment

The FitNesse Architecture
•    FitNesse runs on one server where users write tests
•    Tests are written in the form of HTML tables.
•    Each test table references one fixture code that connects the table to the real application
•    Fixture Code can be written in –
o    Java
o    .Net
o    Ruby
o    Python
o    C#

What is the Goal?

•    The goal is to allow business users and non-programmer testers who can use a web browser but not a compiler to write tests.
•    Programmers are still required to write the application code and the fixture that connects the application code to the WIKI.

FIT is the older of the two, and uses HTML. The HTML parsing is done on the SUT just prior to the fixtures being called. Fit works by reading tables in HTML files. Each table is interpreted by a “fixture” that programmers write. The fixture checks the examples in the table by running the actual program.

FitNesse acts as a front end.

SLIM is newer. All the table processing is done inside FitNesse, within the Slim runners. The Slim Executor and the fixtures are the only code that lives on the SUT. The Slim Executor is very small and easy to port. The Test pages are broken down into simple instructions by the Slim Runners. Those instructions are passed to the Slim Executor which directs the fixtures to call the SUT.

The steps of acceptance testing using Fit/FitNesse include:

Write acceptance tests: the customers write acceptance tests using a browser with the help of developers and the testers. The tests are written in a form of executable tables with Wiki syntax.

Write fixture code: After the customers define the acceptance tests, the developers work on implementing the application code.

Run acceptance tests: Acceptance tests are executed through the FitNesse test runner. The test runner parses the test tables to find the key words and link them together to construct the class name of the fixture code.

View test results: After running the acceptance tests on the FitNesse server, the results are shown in the form of the original test table with the appropriate value cells colors that represent the acceptance testing results.

By Shalini Rawal

Correlation is a method used by performance testing tools such as LoadRunner to handle dynamic content. Dynamic content refers to page components that are dynamically created during every execution of the business process and always differ from the value generated in the previous run. For example, consider the following interaction with a web based application.

When a yahoo user successfully logs in the website, the web server returns a session id to the web browser that is being used by the user along with the page indicating that the login has succeeded. The user then clicks the Inbox link on the returned page that request the web server to open the Inbox page. The Web browser includes the session ID when sending the request. Based on the session ID, the Web server knows that the request comes from someone who is already logged on, and so open the respective Inbox page. In this case data in the second request depends on the data contained in the response to a previous request. So here the request data is substituted from the response data on which it depends. The term for this internal tagging of response and request data is data correlation (or, sometimes, dynamic data). When a test is run with multiple users and varied data, data correlation is required to ensure that the test runs correctly. Besides this correlation is also used to simplify or optimize the code and to accommodate unique data records.

To use correlation the following steps are to be followed:

1.    Determine the value to correlate: This can be done in two ways. Firstly we can scan for correlation and choose from the list, the values to correlate. Secondly we can record the same script twice and compare them. We can look up the difference file to see for the values which need to be correlated.

2.    Save the results: Save the value of a query to the variable using the appropriate correlating function. The functions are protocol specific. E.g. web_reg_save _param.

3.    Reference the saved values: Replace the constants in the query or the statement with the saved variables.

Correlation can be done manually using functions and automatically. Scripts can be automatically correlated during and after recording. The script should be recorded in HTML mode as this reduces the need for correlation. Vugen’s correlation engine automatically correlates dynamic data using Built-in Correlation or User Defined Rule during recording. The Built-in correlation detects and correlates dynamic data for supported application servers. Most servers have clear syntax rules or contexts that they use when creating links and referrals. User defined Rule correlation is used in an application which has unique rules which can be determined clearly. The new rules can be defined using the Recording Options dialog box. Vugen’s built-in web correlation mechanism correlates scripts after recording. This mechanism compares snapshots captured during record and replay to find values which need to be correlated. The web correlation mechanism has built in comparison utility that displays the text or binary differences between the snapshots. The differences can then be correlated one by one or all at once.

Manual correlation is done using the function web_reg_save_param which dynamically saves data to a parameter. When the script is executed, this function scans the subsequent HTML page for the text specified between the defined left and right boundaries. When the text is found it is assigned to a parameter. Please, note that web_reg_save_param function does not perform correlation. web_reg_save_param function just registers a request for correlation from the next server response. That’s why web_reg_save_param function should be placed before action functions, such as: web_url, web_submit_form, and others.

The function’s syntax is as follows:
Int web_reg_save_param(const char *mpszParamName, <List of Attributes>, LAST);

The available attributes are listed below. The attribute value strings are not case sensitive.

NotFound The handling method when a boundary is not found and an empty string is generated. “ERROR,” the default, indicates that VuGen should issue an error when a boundary is not found. When set to “EMPTY,” no error message is issued and script execution continues. Note that if Continue on Error is enabled for the script, then even when NOTFOUND is set to “ERROR,” the script continues when the boundary is not found, but it writes an error message to the Extended log file.

LB The left boundary of the parameter or the dynamic data. This parameter must be a non-empty, null-terminated character string. Boundary parameters are case sensitive; to ignore the case, add “/IC” after the boundary. Specify “/BIN” after the boundary to specify binary data.

RB The right boundary of the parameter or the dynamic data. This parameter must be a non-empty, null-terminated character string. Boundary parameters are case sensitive; to ignore the case, add “/IC” after the boundary. Specify “/BIN” after the boundary to specify binary data.

RelFrameID The hierarchy level of the HTML page relative to the requested URL.

Search The scope of the search—where to search for the delimited data. The possible values are Headers (search only the headers), Body (search only Body data, not headers), or ALL (search Body and headers). The default value is ALL.

ORD This optional parameter indicates the ordinal or occurrence number of the match. The default ordinal is 1. If you specify “All,” it saves the parameter values in an array.

SaveOffset The offset of a sub-string of the found value, to save to the parameter. The default is 0. The offset value must be non-negative.

Savelen The length of a sub-string of the found value, from the specified offset, to save to the parameter. The default is -1, indicating until the end of the string.

Convert The conversion method to apply to the data:

HTML_TO_URL: convert HTML-encoded data to a URL-encoded data format

HTML_TO_TEXT: convert HTML-encoded data to plain text format

Examples:
The examples below are taken from the LoadRunner tutorial to give clarity on topic. We will see more examples in the coming posts.

Sample Correlation for Web Vusers
Suppose the script contains a dynamic session ID:
web_url(”FirstTimeVisitors”,”URL=/exec/obidos/subst/help/first-time-visitors.html/002-8481703-4784428>Buy books for a penny “, “TargetFrame=”,”RecContentType=text/html”,”SupportFrames=0″,LAST);
The dynamic id here is 002-8481703-4784428
You insert a web_reg_save_param statement before the above statement:
web_req_save_param (”user_access_number”, “NOTFOUND=ERROR”,”LB=first-time-visitors.html/”,”RB=>Buy books for a penny”, “ORD=6″,LAST);
ORD=6 saves the sixth occurrence of the value in user_access_number. I think everything else is self explanatory

After implementing correlated statements, the modified script looks like this, where user_access_number is the name of the parameter representing the dynamic data.
web_url(”FirstTImeVisitors”,”URL=/exec/obidos/subst/help/first-time-”“visitors.html/{user_access_number}Buy books for a penny “,
“TargetFrame=”,”RecContentType=text/html”,”SupportFrames=0″,LAST);
Note: Each correlation function retrieves dynamic data once, for the subsequent HTTP request. If another HTTP request at a later point in the script generates new dynamic data, you must insert another correlation function.

Tips to identify the dynamic string boundaries:

•    Always analyze the location of the dynamic data within the HTML code itself, and not in the recorded script.

•    Identify the string that is immediately to the left of the dynamic data. This string defines the left boundary of the dynamic data.

•    Identify the string that is immediately to the right of the dynamic data. This string defines the right boundary of the dynamic data.

•    web_reg_save_param looks for the characters between (but not including) the specified boundaries and saves the information beginning one byte after the left boundary and ending one byte before the right boundary. web_reg_save_param does not support embedded boundary characters.
For example, if the input buffer is {a{b{c} and “{” is specified as a left boundary, and “}” as a right boundary, the first instance is c and there are no further instances—it found the right and left boundaries but it does not allow embedded boundaries, so “c” is the only valid match. By default, the maximum length of any boundary string is 256 characters.

Include a web_set_max_html_param_len function in your script to increase the maximum permitted length. For example, the following function increases the maximum length to 1024 characters: web_set_max_html_param_len(“1024”);

If you have problems handling dynamic data or you want to optimize your code , avoid nesting queries or handling unique data you know what to do. Of course correlation is the answer….