Hope you have been enjoying the series on HTML5 so far, where we covered HTML5 GeoLocation and the Javascript library Modernizr. In this part of the series, we shall cover the new HTML Form elements that have been introduced in HTML5.

A Form is one of the most basic and essential features of any web site. The form elements available in HTML so far include the textbox, checkbox, radio, button, drop-down list, password and file picker. While these have sufficed so far, there is a clear need for newer form elements. The question is not just of newer form elements, but the ability to inject behavior into existing form elements so that usability and validity, which is a cornerstone of any good UI, is given highest consideration.

We shall break up HTML5 Form features into 2 parts in this series. This part will be more focused on the different types of input elements that are introduced in HTML5. In the next part, we shall look at how additional attributes introduced in HTML5 bring in significant improvements to both usability and also to the development code.

New Input Types

HTML5 brings to the table several new input types, a total of 13. The philosophy behind these new input types is to address the common types of data fields that users typically have to fill up in a web form. Apart from plain text, there is data to be filled up like email address, web site URLs, Phone Numbers, Date/Time, Numeric data, Colors, etc.

HTML5 introduces these data types via the <input type=”_NEW_TYPE_HERE_”/> format.

What if my browser does not support these new HTML5 form elements?

No problem. One of the key design decisions in HTML5 is backward compatibility. What this means is that if the new input types are not supported, then by default it falls back to <input type=”text”…./>, so it will be rendered as a plain text box, which the user can then fill data in.

One may ask, what is the advantage of these new input types and how are the browsers supposed to implement them? By supporting the new input types, two things happen:

a) You get automatic validity of the fields as per the format. This means that the form is not going to get submitted if the value entered is not as per the default validation of that type

b) The browser inspects the input type and if it finds that it is of a specific type, then it does something quite clear to aid the input of that data. For e.g. On the Smart Phones, which do not have a physical keyboard but instead a virtual keyboard, the keyboard that will be shown up will only contain keys that will aid the user in filling out the data.

Let us look at the new HTML5 input types that are present.

Email Address

This input type allows for entry of email addresses. The format is shown below:

<input type="email"/>

This input type is useful for entering email ids like test@test.com

Web URLs

<input type="url"/>

This input type is useful for entering web urls like http://www.xoriant.com

Tel

This input type is useful for entering telephone numbers

<input type="tel"/>

The email, url and tel input types are meant to instruct to the browser that the input would be valid only if it contains characters that validate the input type. Additionally, Smart Phone browsers like Apple iPhone do a very neat trick when they encounter input types like URL, Email and Telephone. Since they have a virtual keyboard, they will only show those keys that aid in entering the value quickly. So if you are trying to type the Telephone, it will only show the numbers and some characters, the other keys are hidden from you.

Shown below is a screenshot of the Android Web browser accessing a form which contains an input element of type tel. Notice that in the virtual keyboard, it only shows keys that aid in faster and less error prone data entry.

Date Time

HTML5 provides for 6 types of DateTime inputs, which cater to a variety of date time entries, as your application may require. They are date, time, datetime, local-datetime, month, year. The syntax is shown below:

<input type="datetime"/>
  <input type="date"/>
  <input type="time"/>
  <input type="month"/>
  <input type="week"/>
  <input type="local-datetime"/>

Shown below is the datetime input type rendered in the Opera Browser:

Datetime input type rendered in Opera Browser

Spin Box

A frequent requirement in forms is to fill out numeric values. An input type number has been added. This will render the input as a spinbox if the browser supports it. It will even honor the min, max values that you specify. The step attribute is used to indicate the increment/decrement if the user clicks the up/ down spin button. The value attribute specifies an initial value for the control.

<input type="number"
       min="1"
       max="5"
       step="1"
       value="3">

Slider

Spin boxes are not the only way to enter numeric input. You can also allow a user to use a slider to specify a value. The syntax is shown below:

<input type="range"
       min="1"
       max="5"
       step="1"
       value="3">

If the browser supports the number and range types, it will render as shown below:

Browser supports the number & range types

Search

This input is specified by giving the type=”search” as shown below.

<form>
  <input name="search_terms" type="search">
  <input type="submit" value="Go">
</form>

It will be rendered as shown below:

As you type, a cross icon will appear at the end of the input box and you can clear the search term by clicking on it.

autofocus, placeholder and novalidation

There are 3 attributes that we can apply to HTML5 forms that aid in data entry.

• autofocus: This attribute when applied to any form element, will result in the field receiving focus. For e.g. consider the form shown below:

<form>
	<label for=”firstname”>First Name</label>
	<input type=”text” id=”firstname” name=”firstname” autofocus>
              <label for=”lastname”>Last Name</label>
	<input type=”text” id=”lastname” name=”lastname”>
	<input type=”submit” label=”Go”>
</form>

We have added the attribute autofocus to the firstname input field. When the form loads, you will find that the focus is already set on that field, thereby making it easier for the user to start filling the form.

• placeholder: This attribute when applied to any form element, will display helper text to aid the user to fill up the value. When you give focus to the element, the placeholder value will go away and let the user enter the value. If no value is entered and you move away to another field, then the placeholder value will be shown again. Consider the same example as above but with placeholder values for both firstname and lastname fields.

<form>
	<label for=”firstname”>First Name</label>
	<input type=”text” id=”firstname” name=”firstname” placeholder=”Enter First Name here” autofocus>
              <label for=”lastname”>Last Name</label>
	<input type=”text” id=”lastname” name=”lastname” placeholder=”Enter Last Name here” >
	<input type=”submit” label=”Go”>
</form>

When we visit this page, we see the following form:

<form …. novalidation>

Conclusion

The new HTML5 input types and several attributes introduced in the specification are a clear step to address data input via forms, which forms a cornerstone of any public web application. Do note that there are many more features like pattern, etc which we have not discussed in this blog post, but the reader is encouraged to go and refer to documentation on the standard. While testing out any of these features, it is important to first determine if your browser supports them. In our tests, we have found the Opera browser to be one of the first to implement the different input types, however latest versions of Chrome and Firefox Beta are not far behind. We believe that the browsers will catch up soon and implement most of them.

Please participate

We look forward to your feedback on this article and the others in the series. Let us know which feature you would like to see covered. Additionally, do share your experiences with HTML5.

Romin Irani– Principal Architect

In the first part of our series, we saw how to use the Geolocation feature of HTML5. While this part will not focus on any specific feature of HTML5, it will bring to the table an interesting way in which you can determine if your browser supports a particular HTML5 feature or not.

To understand that a little bit, let us go back to the code in the first part in which we determine if the browser has Geolocation support or not. Take a look at the code snippet below that is reproduced from the first part:

function findCurrentLocation(){
	var geoService = navigator.geolocation;
	if (geoService){
		geoService.getCurrentPosition(showCurrentLocation,errorHandler);
	} else {
		alert("Your Browser does not support Geolocation.");
	}
}

The above Javascript function findCurrentLocation() is interested in determining first if there is Geolocation support or not. If you notice, it queries the standard navigator object first. If your browser support Geolocation, then it will have an object geolocation. We then put in an if statement that does something if support is there and if there is no support then it falls back to another path of execution.

While this approach is fair enough, you will soon end up with similar pieces of code to determine if a certain HTML5 feature exists or not. In certain situations you may also do browser sniffing (User Agent detection) to include a certain piece of code if support exists or not. This soon becomes unwieldy and clutters up your code too. You need a cleaner mechanism of detecting support for HTML5 features (since we still in the transition phase where all browsers support most features).

Enter Modernizr. To quote from their web site, Modernizr is a small and simple JavaScript library that helps you take advantage of emerging web technologies (CSS3, HTML 5) while still maintaining a fine level of control over older browsers that may not yet support these new technologies.

And how does it do that? Modernizr creates a global JavaScript object (called Modernizr) which contains properties for each feature. If your browser supports it, it will evaluate to true, else it will be false.

Modernizr is useful for all aspects of HTML5. It not only helps you detect if your browser supports new HTML5 markup elements, CSS3 features but also the Javascript APIs (Geolocation, Storage, Web Workers, etc). Keep in mind that it does not enable any of the features, it is simply there to help you detect it.

You can refer to its complete documentation for all the features that it can help detect for HTML5. I provide a brief summary below for certain HTML5 features and we will see how to modify our function above to incorporate Modernizr.

Modernizr.geolocation

Modernizr.sessionstorage

if (Modernizr.<feature>) {
//Yes! Your browser supports the feature, so take advantage of it
}
else {
//No! Your browser does not support the feature, so fall back on some other mechanism. Degrade gracefully.
}

Using Modernizr in your code
We shall modify our existing Geolocation code shown at the start of the article and which we covered previously in the series and employ Modernizr.

Follow these steps to include Modernizr:

1. Download modernizr-1.5.min.js from the main web site
2. Include the script in your code. This will initialize Modernizr when the page loads. In fact, it creates the global Modernizr JavaScript object with all the feature objects created, so that you can start using it in your code.
3. Finally, use the template pattern in your code as shown above.

I will recreate the geotest.html example that we covered in Part 1: Geolocation article.

<!DOCTYPE html>
<html>
<head>
<meta charset=”utf-8">
<title>HTML Geolocation Test</title>
<script src="js/modernizr-1.5.min.js"></script>
<script type="text/javascript">

if (Modernizr.geolocation) {
  navigator.geolocation.getCurrentPosition(showCurrentLocation,errorHandler);
}
else {
  alert("Your Browser does not support GeoLocation.");
}
… REST OF THE CODE
</script>
</head>

<body>
<div id="main">
	<div id="mylocation"></div>
	<input type="button" value="Get Location" onclick="findCurrentLocation()"/>
</div>

If you look at the above code, we have simply included the script file i.e. js/modernizr-1.5.min.js and then checked if the Geolocation feature is supported. The rest of the code remains straightforward.

While this is a simple example, the utility of Modernizr becomes visible when you deal with many other features of HTML5. Let it do all the hard work of determining a particular feature of HTML5 in your browser.

Please participate

We look forward to your feedback on this article and the others in the series. Let us know which feature you would like to see covered. Additionally, do share your experiences with HTML5.

Romin Irani– Principal Architect

Welcome to the series on HTML5 development brought to you by the team at Xoriant.

HTML5 has been in the news of late and it promises to help deliver the next set of web applications with features that closely resemble some top of the line desktop applications.

This series will focus on demonstrating a feature of HTML5 with emphasis on a short working example. The idea is to introduce to you what your applications could gain by using HTML5 today. We will focus less on controversial stuff like Flash v/s HTML5 and instead focus on the features. As a developer, you are the best judge of using the technology in your applications today by looking at all factors. We will focus particular on bringing these experiences to mobile web applications, where the Webkit based browsers on most Smart phones today are more than capable of supporting several HTML5 features.

All you need is a text editor (or your favorite IDE), a Web Server (maybe) and a HTML5 compliant browser (more on that later).

Ready, Set … Lets Go!

Which Browser?

First, a word about the browser support for HTML5. To summarize in brief, HTML5 support has been announced in most browsers and all of them support core features, though several features present in the specification are still not implemented. With the announcement of IE9 Beta, HTML5 support has got a fillip in the IE world too, though Google Chrome presents your best bet at this point in time to try out some of the features.

Enter “The HTML5 Test”

A quick tip to figure out how well your browser supports HTML5 specification is to navigate to http://www.html5test.com. This will display a score about how well your browser supports HTML5. You should not worry too much about the score, rather there are 2 things that are particular important here and can actually act as a guide to your learning HTML5 and they are:

• Check out all the features that are there in HTML5. Just a look at the number of features should get you excited about HTML5. Pick each of them up, refer to the web and learn about them. We will also be covering most of them in our series.
• Once you have learnt about a particular feature and wish to see it work, check if your browser is supporting that feature of HTML5. If Yes – you are good to go. If not – you will need to wait.

A quick look at http://www.html5test.com in my browser (I am running Google Chrome 6.0.472.63 beta) shows that it does quite well.

html5test.com in Google Chrome browser

Some assumptions

We will assume that our readers are familiar with developing basic web applications with HTML, JavaScript and a little bit of CSS. That will help you best to appreciate the new capabilities that HTML5 is bringing forth to the table.

What about Mobile Browsers?

The thing that excites us the most today is the fact that most Smart phones shipping today are equipped with the fantastic WebKit browser, which has great support for several HTML5 features. So if you have a Smart Phone, be it Android or the iPhone, you are all set. The other Smart Phone manufacturers including RIM and Nokia have also announced support for WebKit, so moving forward your application will be well placed to be functional on newer devices coming from them.

Where do we go from here?

Well, the question to ask should be “Where am I?” before we can go anywhere. And with that, we can look at the Geolocation APIs that are provided in HTML5. Geolocation is all about telling us where we are. In short, we will know the Latitude and Longitude, though it gives much more information than that like Altitude, Accuracy, etc.

To make sure that your browser supports Geolocation, point it to http://html5test.com and navigate below the Geolocation section, where you should see a score of 10 as shown below.

In case there is no Geolocation support, which means the screen below:

Then I strongly suggest that you get either the latest version of Google Chrome or Firefox to see the example work. If not, you can still follow the article.

The code (geotest.html)

We will write a minimal piece of HTML code that is functional in nature and will access the Geolocation support in the browser and show the current Latitude and Longitude. First, take a look at the geotest.html file below:

<!DOCTYPE html>
<html>
<head>
<meta charset=”utf-8">
<title>HTML Geolocation Test</title>
<script type="text/javascript">

function findCurrentLocation(){
	var geoService = navigator.geolocation;
	if (geoService){
		geoService.getCurrentPosition(showCurrentLocation,errorHandler);
	} else {
		alert("Your Browser does not support Geolocation.");
	}
}

function showCurrentLocation(position){
	document.getElementById("mylocation").innerHTML = "Current Latitude : " + position.coords.latitude + " , Longitude : " + position.coords.longitude;
}

function errorHandler(error){
	  alert("Error while retrieving current position. Error code: " + error.code + ",Message: " + error.message);
}
</script>
</head>

<body>
<div id="main">
	<div id="mylocation"></div>
	<input type="button" value="Get Location" onclick="findCurrentLocation()"/>
</div>
</body>
</html>

Let us analyze the code which is rather straightforward:

1) Our body has a div element named mylocation, that we shall populate once we have the Latitude and Longitude.

2) We have a button, which when clicked calls the findCurrentLocation() method

3) The findCurrentLocation() method is where all the magic happens. The standard navigator object now has an object named geolocation. So, if your browser supports the geolocation object the navigator object will contain it. That is the first test we do. If there is no object then we display a standard alert informing the user that his/her browser does not support Geolocation.

4) If you do have support for the geolocation object, then all you need to do is invoke the getCurrentPosition method on it. The getCurrentPosition method takes 3 parameters:

1. A success callback function
2. An error callback function
3. An optional parameters where you can provide some additional options to get the Current Position

5)  The success callback function in our case is the showCurrentPosition method. This method will get passed one parameter, an object of type Position. This object has two parameters, a property called timestamp and a property called coords that is an instance of type Coordinates. The coords object has several properties related to the current location like latitude, longtitude, altitude and several more. For our example, we are interested only in latitude and longitude.

6) The error callback function in our case is the errorHandler method. This method will get passed one parameter, an object of type PositionError. This object has two properties: code and message. The code is either 1 (PERMISSION_DENIED), 2(POSITION_UNAVAILABLE) or 3(TIMEOUT). The message is dependent on the device / machine browser.

7) We can leave out the 3^rd optional parameter for now, since it is not fully supported on all browsers.

8)  So once the success callback function i.e. showCurrentPosition is invoked, we simply retrieve the latitude and longitude and populate the div with the results.

Our Geolocation Example in Action

We serve the geotest.html file via a local web server as shown below. Please note that I am using a latest version of Google Chrome browser.

Geolocation Example

When we click the Get Location button, we see that the browser prompts a warning message as shown below. This is important since it is recommended that all applications that deal with the location of the user should always allow the user to opt-in for sharing the location. It is good practice and strongly recommended, since it is a privacy issue and more users in the future will demand it.

Geolocation Example

If we click on Allow, you will find that it takes a little while (at times) to get the location and the current latitude and longitude are printed below.

Geolocation Example

Do note that since you allowed the browser to share the location, it has remembered that you have opted-in. On subsequent calls or even across browser restarts, this is remembered by the browser and you are no longer prompted by the browser for permission to determine your location. You can clear this preference, by clicking on the Icon shown below and then clicking on Clear these settings for future visits.

What happens, if we refuse permission to the browser to determine our location? Let us see what happens by running our example again. We navigate to the home page i.e. geotest.html and once again the browser prompts us, asking for our permission, as shown below:

This time we refuse it by clicking on Deny. This will results in the error callback function getting invoked i.e. errorHandler and we extract out the PositionError.code i.e. value of 1 (PERMISSION_DENIED) and PositionError.message that is device specific. In the case of Google Chrome, it rightly populates it to “User denied Geolocation” as shown below.

Do not assume that this message will be populated correctly. The same error message on Firefox browser gave the following alert message, as shown below:

So remember to provide a user friendly message that is populated by your application rather than depending on the device to do that.

What if the Browser does not support Geolocation?

If the browser does not support Geolocation, we have handled the scenario such that it displays an alert to the user in our test code. For e.g. I accessed our sample page via Internet Explorer 9 Beta and found that it displayed the appropriate message as shown below:

Remember HTML5Test that we covered earlier in the article. If we access http://www.html5test.com in Internet Explorer 9 Beta, we get the correct results for Geolocation feature as shown below.

So remember to save yourself enough heartburn and use html5test.com as a quick way to ascertain if a particular feature is supported or not.

What can we do with our location?

Location is the starting point of an entirely new class of applications/services that called themselves “Location Based Services”. Once you know the Location of the user, several value added features can be built on top of it. Location of a user is such a hot topic nowadays that everyone from Google, Yahoo, Twitter and Facebook added location of the user activity to their applications. Examples of how you can use a location are:

· Weather Reports for a particular location as the user is passing through it

· Traffic incidents as they happen

· Retail offers from merchants in the vicinity of the location that the user is currently in

· A Friend Locator application that informs the user of his/her friends if they are within close proximity of each other.

Most of these LBS application also make use of Google Maps to provide an intuitive user interface.

Conclusion

We saw how easy it was to get access to Location using the Geolocation APIs in HTML5. Geolocation data when combined with Maps and Other services can help create powerful applications.

Please participate

How important is Location to your application? How did you incorporate it into your application? What do you think of HTML5 Geolocation APIs? Would it make things simpler/better? Please discuss in the comments below. We look forward to your active participation.

Romin Irani– Principal Architect

Introduction

In today’s competitive and ever changing world, where most software applications are complex in nature having distributed, multi-tiered, Web-based architectures, one of the key success factors is the application’s actual performance.

Imagine a scenario where your application is great in design with a fantastic look and feel and the most user friendly GUI, but is really poor when it comes to performance, with users needing to wait for several minutes to complete a single transaction. Add to that a very high system down time due to failures, frequent restarts and incorrect operations under heavy traffic conditions. All these factors would understandably lead to losses in revenue, market share and the company’s reputation.

Software performance testing thus plays an essential and significant role in the entire software testing cycle; the quicker the problems related to performance are found in the development cycle, more easily and cost effectively they can be fixed by providing the necessary hardware and/or software solutions.

This blog focuses on the performance engineering practices that we follow here in Xoriant to deliver high quality software on-time that meets the required performance objectives within the allocated budget.

Performance testing types

Following are some of the phases of software testing that an application usually goes though during the testing cycle:

• Load Testing: Determine if the application can meet a desired service level under real world volumes.
• Spike Testing: Simulate a sudden increase in the number of concurrent users performing a specific transaction to determine the application’s behavior under abnormal traffic conditions.

• Endurance Testing/Soak Testing: Determine if the application can sustain a continuous and expected load for an extended period of time. Usually during endurance tests, memory utilization is also monitored to detect potential memory leaks, since small amounts of memory leaks on a system can turn out to be a severe problem during peak traffic conditions leading to performance degradation and resulting in the system running out of memory very often.

• Stress Testing: Determine the application’s breaking point under maximum load conditions that the application is designed to handle (typically specified in terms of number of concurrent users/transactions, memory and disk space becoming full etc).

• Scalability Testing: Determine whether the application under test is able to gracefully handle increases in work load by upgrading the hardware (for example, by adding extra memory and disks to the system).

The performance testing process

The following diagram shows the processes involved in the entire performance testing cycle along with the flow between them.

Processes involved in the performance testing cycle

Requirements analysis

During the requirements stage, the system performance criteria are captured and documented to get them approved by the customer. This process helps to identify testing objectives, understand system components and its configuration, and comprehend system usage in the production environment.

Performance test planning

Based on the requirements plan, the key activities of performance testing are planned, which include:

• Test tools’ identification and finalization.

• Preparing various checklists to be used during actual execution.

• Indentifying test resources includes hardware, software and human resources.

• Indentifying the baseline for the test setup.

• Identifying the risk involved in performance testing.

• Estimating and planning the performance test cycle.

Testing tools’ identification and finalization

Based on the requirements, identify the tools which can support the number of simultaneous virtual users as fixed in the test plan, the cost of testing, the number of features to be supported in the particular build and the platform it will support. Because most of the times these requirements are fulfilled by good open source performance testing tools, investing in proprietary and licensed tools must be properly thought over.

Some of the popular performance testing tools in use these days are Load Runner by HP, SilkPerformer by Borland, Webload (open source), JMeter (open source) and Microsoft Web Application Stress by Microsoft

Preparing the various checklists

Having a checklist for performance testing is extremely important. This helps in creating a better definition of the required performance and tracking the requirements. In the absence of properly defined performance testing requirements, teams may have to spend a great deal of time either in getting the information during actual testing which could delay the actual testing, or in rework required in the project because of insufficient information.

Checklist to ensure availability of the correct performance testing environment

The following is the list of points to be verified to ensure that the performance testing environment is correctly set up:

• Does the test environment exist?

• Is the environment self-contained?

• Are all required licenses in place?

• Are systems for the load testing identified?

• Is the environment modeled close to the production environment?

• Is a copy of production data available for testing?

• Are replacement servers available?

• Are the tools and utilities identified compatible with the environment?

• Is load balancing available?

• Are system deployment diagrams in place?

• Are testers well versed with the environment?

Checklist to ensure proper performance test planning

• Are people with the required skill sets available?
• Have version control processes been used to ensure the correct versions of applications and data in the test environment?
• When will the application be ready for performance testing?
• How much time is available for performance testing?
• How many iterations of testing will take place?
• Have external and internal support staffs been identified?
• Have back-up procedures been written?
• Have any contingency situations been considered and provisioned for?

Identifying the test resources

Identify suitable hardware and software which should replicate the production environment because using the same hardware and software as in the actual production environment is neither cost effective nor feasible. Also, identifying the human resources in the beginning will help you plan the required trainings for the application’s understanding and its usage as well as using the testing tools and learning any third party software that is required in the testing phase. This in turn helps the testers feel confident while executing the performance tests.

Identifying baselines for the test setup

Identify the baselines for the test setup for all types of tests that you are going to perform. The setup should be a replica of the real environment. This has two advantages: First, the results from various categories of tests do not reflect the type of hardware you are using. Second, you can depend on the test results because the test setup is close to the production environment.

Identifying the risks

Performance testing is a risk-driven and time consuming activity. If the level of risk is small, the effort involved in performance testing activities can be correspondingly small and if the risk is high, then a significant amount of effort is needed. Hence, identify these risks in the beginning and document them in the plan to build a common undersigning for all stakeholders, and define the clear expectations for each throughout the performance testing cycle.

Estimate and plan the performance test cycle

Because performance testing is a risk-driven and time consuming activity, precise estimation is very much important which will help define the early performance testing cycle so that any bottlenecks found can be fixed and retested during the test cycle itself.

Test design

This phase includes designing and developing the test cases for each performance test type. Prioritize these test cases and test scenarios according to the critical functionalities, the risk involved in the use cases and the high traffic/volume conditions that need to be tested first. The deliverables for this phase are the test case design document which is the input criterion for the test scrip and test suite creation activities.

Test script and test suite creation

This phase includes developing the test scripts and designing a test suite. This includes actual performance test execution scripts as well as system monitoring scripts.

Test execution

The test execution phase includes running the actual tests and collecting statistics for analysis. The following items needs to be considered while actually executing the performance tests:

• Always execute the performance tests in a controlled environment. Testing without dedicated servers and good configuration management will yield test results that are not reproducible. If you cannot reproduce the results then you cannot measure the improvements accurately when the next version of the system is ready for testing.

• Clear the application and database logs after each performance test run since excessively large log files occupy the disk increasing the chances of the system running out of space during the test. It can also artificially skew the performance results.

• If the application uses a database, then both the application and the database should be installed on two different systems.

• Validate the test setup by sending a few requests before you actually start the complete test.

• Prioritize the test cases and test scenarios that need to be executed first so that important bottleneck issues are identified early.

• Always generate the load by using different client computers.

• Make sure that the client and server systems are located on the same network; otherwise it may introduce latency in the request/response times.

• Always refer a single client to capture client-side data such as response time or requests per second. You should consolidate data at a single client and generate results based on the average values while a load is generated on the system.

• Include a buffer time between the incremental increases of users during a load test.

• Use a zero think time if you need to fire concurrent requests. This can help you identify bottleneck issues.

• Monitor all computers involved in the test, including the client that generates the load. This is important because you should not overly stress the client.

• Do not allow the test system resources to cross resource threshold limits by a significant margin during load testing, because this may affect the test data and test results.

• Do not run tests in live production environments that have other network traffic. Use an isolated test environment that is representative of the actual production environment.

• Do not place too much stress on the client test computers. The processor and memory usage on your client computers should be well below the threshold limit (CPU: 75 percent). Otherwise, chances to die/hang for the client are very high and destroying the test result and necessitating re-execution of the tests.

• Do not try to break the system during a load test. The intent of the load test is not to break the system, but to observe performance under expected usage conditions. You can stress test the system to determine the most likely modes of failure so they can be addressed out.

During the test, the system should be closely monitored to capture the following metrics and statistics at regular intervals of time:

• CPU utilization
• Memory usage identifying memory and thread leakages
• Disk space
• All queues and IO waits
• Network usage on individual clients, application and database servers (bytes, packets, segments, frames received and sent per sec, bytes total/sec, current bandwidth, connection failures, connections active, failures at network interface level and protocol level)
• Web server (requests and responses per second, services succeeded and failed, server problems if any)
• Request and response times
• Throughput
• Time (session time, reboot time, transaction time, task execution time)
• Hits per second, requests per second, transactions per second
• Database problems (settings and configuration, usage, read/sec, write/sec, any locking, queries, compilation errors)

Test analysis

This is the most important phase. At the end of the test execution, the test results and its data are analyzed for system performance and bottlenecks are identified.

A preliminary snapshot of these analyses is sent to the development group to fix the issues or performance tuning recommendations. Once fixes or tuning is applied on the test system, the tests are re-executed and hence, test execution and test analysis processes are iterative processes and need to be executed until the desirable performance is achieved.

Identifying bottlenecks and tuning the system

If any bottlenecks are found in the system, then the performance of the system can be enhanced by improving the architecture, design, code and configuration. And tuning of the code can be done using developer support tools such as profilers and code coverage analysis tools.

The following considerations should be taken into account while applying any performance optimization:

• Always practice change control. Make backups of all configuration files you alter, so you can revert to an older version if required.

• Take a baseline of the performance before and after changing any settings.

• Document the changes. This helps others understand why the changes were made.

• Don’t apply any changes to the test system unless you have a reason to. If everything is working well enough and performance data are acceptable by the customer, then why to make any changes? In such a case, you should contact the customer with the suggestions and apply the changes only after they have been approved by the customer.

Test results and reporting

At the end of the performance tests, test results are correlated and summarized in an executive summary report which includes the following contents:

• Objectives of the test

• Reference documents

• Test setup (hardware configurations, software configurations, tool settings, list of transactions, scenarios tested, client machine details and its configurations, transaction generation pattern etc.)

• Test results (list of significant runs, scalability statistics, request and response time statistics, server side statistics etc.)

• Findings, recommendations and test log

Knowledge repository

Maintaining a proper knowledge repository is the most important part of the performance testing cycle since it is a link between the current and future activities as it contains the record of all the activities performed during performance testing. The objective of this is to capture the knowledge gained during the project which can be used in future releases.

So summarizing, we saw in this blog that there are several steps and processes that need to be followed to ensure that a software development project progresses in the intended manner and within the available time and resource limits. Thankfully, many of these processes have now been made easy by good quality and easily available software tools.

Ketan Tank– Sr. Member of Xoriant QA Center of Excellence

A commonly used class in any application, whether it is a desktop application or a mobile application is an application level class. An application level class also called a controller is a single instance available across the application and visible to all modules within an application. This application controller can be used to maintain global state across an application, contain common methods, etc.

Android provides support in every application to create an application wide class. The base class for this is the android.app.Application class. The official documentation of the Application class is given below:

Base class for those who need to maintain global application state. You can provide your own implementation by specifying its name in your AndroidManifest.xml's <application> tag, which will cause that class to be instantiated for you when the process for your application/package is created.

Let us look at how to incorporate an Application class in our Android applications.

Step 1: Provide an implementation of the Application class

You need to extend the android.app.Application class and override the OnCreate method. This method is invoked by the Android runtime once when your application is started. So this is a good point to do application initialization and set some global settings like shared preferences, etc.

Shown below is a template for your own Application class:

public class ApplicationController extends Application {

	//Application wide instance variables
      //Preferable to expose them via getter/setter methods
@Override
	public void onCreate() {
		super.onCreate();
		//Do Application initialization over here
        }
        //Appplication wide methods
}

Step 2: Code your Application class

You can then introduce public methods in your Application class above. These public methods can then be called from anywhere in the Android application. We shall how to invoke them in Step 4.

Step 3: Specify our Application class in the Android manifest.xml file

Specify your application class in the Android manifest.xml file. Each Android manifest has the <application> tag and you need to provide the application class as an attribute of this element as shown below:

<application android:icon="@drawable/icon" android:label="@string/app_name" android:name=".android.controller.ApplicationController">

Step 4: Utilize the Application class from other places in your application

To access the Application class instance in any activity, you can use the code as shown below:

ApplicationController AC = (ApplicationController)getApplicationContext();

The main method is getApplicationContext(). This gives an instance to the Application class if defined in the application. You need to simply type cast it to your provided Application implementation class. Once you have this instance, you can invoke any public methods that you would have defined in the class. Additionally, if you provide getter/setter methods for application wide state variables, you can invoke them too.

Having an Application wide controller in your application is a commonly used design with significant benefits. Instead of rolling out your own custom implementation, Android provides a simple mechanism to introduce it in your applications, letting you focus on your Application wide logic while it takes care of its lifecycle methods. Start using the Application class to bring in structure to your applications today.

Romin Irani– Principal Architect

Overview

Back in 2001 when a group of 17 CTO’s came together to discuss an alternative to documentation driven, heavyweight software development processes, Agile was born. Agile is a software development technique based on iterative and incremental development, in which requirements and their solutions continuously evolve via collaboration amongst self-organizing, cross-functional teams. The Agile Manifesto, introduced in 2001, places more emphasis on individuals and interactions rather than processes and tools.

As it happens with any new concept, Agile was misinterpreted as not requiring any tools at all, or as focused only on inclusive modeling using simple tools such as whiteboards and paper. Yes, both whiteboard and paper would constitute one of the most basic tools in Agile and if used correctly, can be very effective for a small Agile team in a location. However, in today’s connected world, “Remote-Team” is, but a mere term. Agile or not, today teams/projects are connected to their counterparts in various parts of the world and it becomes mana-de-rigueur to use sophisticated tools to increase collaboration and transparency.

I had the experience of working in a Distributed Scrum team spread across the US and India, and our team extensively used efficient Agile tools to run the day to day activities of the project. However, this was not always the case. One major advantage we had on our side was that the stakeholders were Scrum evangelists and were focused on breaking the traditional waterfall mould. In this blog, I plan to discuss these phases and a couple of tools which kept our project ticking.

Prior to using tools for Scrum

When a new tool comes aboard a project, it does make life easier for all stakeholders, especially in a distributed Scrum. In the early days, it used to be quite cumbersome for both the US and Indian team members. The project was driven primarily from the US where a majority of the stakeholders, including the ScrumMaster, were present. The Indian team would then go for a “Sprint Planning Meeting” and break down the user stories which the ScrumMaster would then put up on the Scrum Board. The Indian team then picked up the stories and the ScrumMaster would move the cards around the board.

After the Daily Scrum Meeting, team members would inform the ScrumMaster of the remaining hours and he would update the burn down charts. Naturally, this couldn’t go on for long without people getting burned out in the process and eventually diving back head-on into the waterfall. So the ScrumMaster decided to introduce Scrum tools to help the sprints gallop at a good pace.

Enter ScrumWorks , CruiseControl and Perforce . Notably, it was also decided to follow Scrum during integration of these tools. A separate infrastructure team was set up with their own sprints to integrate these tools into the mainstream project.

ScrumWorks

ScrumWorks Pro is used for all day to day activities in a project. The tool is hosted on a server and hence, is accessible over the Internet. The PO defines the product backlog as per the priority and during the sprint planning meeting, the team picks up the stories and moves them to the sprint backlog.

A screenshot of the backlog window in ScrumWorks Pro is shown below.

If you observe the above figure, the Product Backlog window fills the main screen once a Product has been opened or created. It allows you to edit, prioritize, and schedule your work.

Higher priority work appears higher on the list than lower priority work. You can reprioritize and schedule your work by dragging and dropping backlog items, tasks, and releases.

The left pane represents Sprints (typically 4-week iterations) in chronological order. The right pane represents “uncommitted” (unscheduled) work, optionally organized into “releases”. You can also use the “release” feature to group related backlog items.

The tabs on the left pane display the teams that are working on the open product. Once the sprint is planned, the team updates the remaining hours on the stories after the daily scrum meeting. This lets the stakeholders see the progress on the burn down chart during every sprint.

A sample screenshot of a sprint chart is shown below.

Sprint chart

To highlight any impediments during the sprint, we used the Impediments window (shown below) to report all issues. The ScrumMaster tracks the impediments from this window.

ScrumWorks - Impediments

Complete Setup

We had various dedicated environments for our project – development, integration, QA, staging and finally production. Our Enterprise version product was related to the Supply Chain Management domain with a wide user base. With teams distributed across the US and India, we required a Software Configuration Management System which could support this work model. Perforce supported our iterative model and fit into our system. To start with, it had an easy GUI, was very flexible and allowed us to create private branches from the main trunk when required. We could also run automated tests against a specific branch. The merging was handled by Perforce with color coded indication of the changes. It also seamlessly integrated with our Visual Studio IDE which made check-in/check-out very easy.

With Perforce in place as the Change Management System, we hooked up CruiseControl as our big melting pot Integration Server. CruiseControl for .Net, or CCNet as it is popularly known, is an automated integration server. The server automates the integration process by monitoring the Perforce source control repository directly. Once developers check-in any code in Perforce, CruiseControl picks up the newly modified files and its associated components and creates a new build on the Integration server. When the build is complete, the server notifies the developer whether the changes that they committed integrated successfully or not. Using automated integration guarantees that the integration build will be completed.

The quality team would then deploy the successful builds on their environments and run a full set of functional and regression tests before certifying it for Staging and Production.

These tools helped both the US and Indian team members to effectively manage themselves. Once the team started using ScrumWorks, they did not have to depend on their US counterparts to access the sprint backlog as well as update the progress during the sprints. The stakeholders could also review the project progress any time.

The combination of following Scrum and using compatible tools has made this project a great success!

[1] ScrumWorks is a registered trademark of Danube Technologies, Inc. [1] PERFORCE is a registered trademark of Perforce Software, Inc.

Sushil Sapre– Tech Lead of Xoriant’s Microsoft COE