Ramesh Viswanathan, Senior Performance Test Architect at Marlabs highlights the importance of defining and collecting requirements which is usually given secondary importance compared to functional requirements.

Read full article or download the article: Need for Performance Requirements to Ensure Reliable Business Applications

Rajesh Sundararajan, Practice Head-Testing services at Marlabs highlights the key aspects of Test Process Improvement and analyzes their context driven variations in different situations.

High Productivity
Lot of dependency injection introduced in the platform which means a lesser boilerplate code, thanks to Spring who introduced dependency injection concept which is incorporated by Oracle in Java EE7. Provides more defaults in the platform like default datasource, jms connection factory etc this helps in creating quick POC’s without worrying about what values needs to be passed.

WebSocket
Enables duplex bi directional communication over a single TCP channel. Typically when we do a http request it is 2 step process; establish a new TCP connection and then http connection. This will make more heavier since the headers will ride on the these protocols. In websocket there is a connection established and there can be as many data which can be sent and the overhead is only once.

JSon Processing
Java api for processing json is built on top of JAXB. Json processing provides streaming api and object model. Selection criteria between streaming api and object model is based on the trade of between the performance and memory.

Bean Validator
Typically POJO’s which gets persisted via a jpa persist mechanism to the database didn’t have a mechanism to validate the attributes of the bean. This cost a heavier mechanism of database which throws exception and then propagate this to user interface. Bean validator provides a mechanism to validate the beans and this is annotation driven.

Image Courtesy: Oracle

What to look for in Java EE 8

The main focus on EE 8 release is on cloud and defining standards based on cloud programming model. It makes a great sense since the world is excited towards cloud and support in Java EE 8 is vital.

Other highlights of the Java EE8 :

1. Cloud
2. JCache
3. Multitenancy
4. Paas Enablement
5. NoSQL
6. Thin Server Architecture
7. Modularity
8. JSON B

Author : Manigandan Mani Srinivasan – Head, Java Practice, Marlabs Bangalore

Surface Pro can run current Windows 7 Desktop Apps (unlike RT) and it integrates with the existing enterprise management infrastructure. For an IT Administrator it is going to be a huge relief and opportunity – Active directory, Domains, Group Policies etc. are going to work on Surface Pro!

Now, let’s see the bigger picture:
In a recent CIO Survey, 57% of the people surveyed said they have plans to deploy tablets in their enterprise environments, compared to 46% last year. Obviously, there are trends like “Tablets will overtake PCs and laptops” going around. There are lots of talks on the acceptance of Apple iPADs for corporate use.

Here comes BYOD – What is it?
BYOD is Bring Your Own Device to office for work. You own it, the corporate IT will do the policing when you are in. Your apps, data, collaboration tools, etc. will be delivered to you via internal or external Cloud. Or even a corporate desktop image with pre-loaded stuff (VDI) can be rendered to you for your day-to-day work.
However, it is not very easy. CIOs and IT managers were not really enthusiastic when the concept came in, primarily due to the concerns on security and governance. In the US, BYOD is still in its infancy because of these concerns. However, at the same time, China has widely adopted this concept for the last couple of years. It is more or less a norm in Chinese workplace to have a personal device. They seem to be less worried about the security concerns than their US counterparts. In China Android devices are dominating the BYOD spectrum.

CIO’s concerns:
Having said that, CIOs and IT Managers have genuine questions. They are worried about the loss of control, governance, and privacy. Many of them feel that Android and Apple IOS are very sensitive and fragmented to be used for corporate information. Also, the newer versions especially in Android are released every few weeks. New tablet and smart phone models are coming in almost on a daily basis! This makes the life of the internal IT support team extremely difficult and may lead to more downtime.
Now, here comes the Surface Pro. The moment IT team realized that they can extend Windows domain, active directory group policies etc. to this device, they started smiling. It is a big thing that takes the sheen out of Apple IOS and Android devices.

BYOD adoption:
Personally, I feel that there will be an impact on the BYOD adoption when Surface Pro steps in. Also, there are obvious benefits of BYOD for an Enterprise. It gives you a simpler and thin IT infrastructure to manage, with lesser end user device management and troubleshooting headache. Now IT team can focus more on the strategic innovations aligned with business priorities. There are direct savings from Power savings (Some high level calculations reveal that we can reduce power bills by 70%!). Moreover, employees will have increased mobility, higher job satisfaction, better efficiency, and productivity. BYOD can help attract and retain top talents who prefer to work flexibly. Employee on-boarding and training time will get reduced, which may directly add to the bottom-line.

Article by Marlabs Maven Sreejith Gireesan

Integration Testing (typically tested with full load testing)

Integration testing tests the interfaces of the DWH process – the source system, the scheduling tool, the alerting mechanism and the publishing agent.

Most issues found during integration testing are either related to the data that is ingested into the DWH or related to a wrong assumption on the design of another application. As most applications today expose their interfaces as services, it is fairly easy to get comprehensive information on the design of these services. It is critical to test integration with production-like data. Real production data is ideal, but depending on the contents of the data, there could be privacy or security concerns that require certain fields to be masked before using it in a test environment. Good communication between the testing and design teams of all systems involved is of paramount importance here. To help bridge this communication gap, framing test scenarios should be a cross-team activity. Integration testing should always be run end-to-end and with extreme inputs from the interfaces mimicking production systems as closely as possible.

Audit, Logging and Error Handling Testing

This testing is more for validation of the technical processes of a data warehouse. Every ETL system should log what processes have run, when and for how long. Consider the following strategies:

• Ensure that you consciously abort processes and validate that they re-start from the point of failure.

• Sometime re-starting from the point of failure may not be possible; in that case we need to validate that the system can roll back to the original state and the ETL can be reprocessed.

• Check the depth of error logging – does it log the error alone or does it also capture additional details including when and in which data row does it occur.

• The scheduling mechanisms in the DWH may need to have manual over-rides for special cases (Feb 29th) or “back-data” loading – identifying the various automated and manual scheduling scenarios and testing for it may help identify production issues.

Deployment Testing

Eventually ETL processes are run out of data centers by production support operators. The deployment process and documentation for the same should be complete and comprehensive enough for them to run the process end to end. A couple of areas that need to be kept in mind here:

• Ensure that deployment testing is performed by a person who is new to the project and does not understand the nuances of the system you have designed.

• When things go fine, the data center personnel do not have much to do except monitoring; it is when things go wrong that they swing into action. Testing should cover instances where things go wrong (an ETL process hangs, a data file does not get loaded) and how the system effective capture and presents these negative scenarios.

User-Acceptance Testing

The eventual goal of a data warehouse application is to make data available to end business users. Users know the data best, and their participation in the testing effort is a key component to the success of a data warehouse implementation. User-acceptance testing (UAT) typically focuses on data loaded to the data warehouse and any views that have been created on top of the tables. Consider the following strategies:

• Use data that is either from production or as near to production data as possible. Users typically find issues once they see the “real” data, sometimes leading to design changes.

• Plan for the system test team to support users during UAT. The users will likely have questions about how the data is populated and need to understand details of how the ETL works.

• Consider how the users would require the data loaded during UAT and negotiate how often the data will be refreshed.

Regression Testing

Regression testing is revalidation of existing functionality with each new release of code. When building test cases, remember that they will likely be executed multiple times as new releases are created due to defect fixes, enhancements or upstream systems changes. Building automation during system testing will make the process of regression testing much smoother. Test cases should be prioritized by risk in order to help determine which need to be rerun for each new release. A simple but effective and efficient strategy to retest basic functionality is to store source data sets and results from successful runs of the code and compare new test results with previous runs. When doing a regression test, it is much quicker to compare results to a previous execution than to do an entire data validation again.

There are no industry standard automation tools to perform data transformation and data quality checks, but try using a tool like Concordion (http://www.concordion.org/), especially for unit testing.

Taking these considerations into account during the design and testing portions of building a data warehouse will ensure that a quality product is delivered and prevent costly mistakes from being discovered in production.

This article by Rajesh Ramaswamy, Head of the BI/DW/Analytics practice at Marlabs, was first published at  siliconindia.com.

While day-to-day threats are a reality originating from hackers as well as from internal employees, protecting against them can be a daunting task. Security and privacy breaches can cause substantial damage including revenue loss, legal liabilities, diminished productivity, and brand erosion, to name just a few.  The answer to this challenge lies in implementing a comprehensive information security management framework that aligns people, processes, and technology. In the following video, Robert Parham, the Director of the Information Security Practice at Marlabs, presents an overview of Marlabs’ approach to Information Security and Cyber Threat Management.

Data Completeness (can be tested with both designer data and full load)

One of the most basic tests of data completeness is to verify that all expected data loads into the data warehouse. This includes validating that all records in all fields and the full contents of each field are loaded. Strategies to consider include:

• Comparing record counts between source data, data loaded into the ODS and data loaded into the warehouse. You might also want to consider the rejected/suspense records.

•  Comparing the count of distinct values of key fields between source data and data loaded to the warehouse. You could also do a comparison of the distinct values themselves.

• Utilizing a data profiling tool (Talend, http://www.talend.com, provides a free tool) that shows the type, range and distributions of data in a data set. This can be used during testing and in production to compare source and target data sets. The profilers can also identify defects from source systems that may be missed even when the data movement is correct.

•  Ensure that each field is tested to its maximum length – for example if you have a varchar(10) field, make sure you test it with 10 characters, 11 characters, blank and null.

• Testing the boundaries of each field to find any database limitations. For example, for a decimal field with a precision of 3 include values of -99 and 999, and for date fields include the entire range of dates expected (including dates in multiple formats).

Data Transformation (typically tested with designer data)

Often the real value of data in a warehouse lies in the transformation rules that are applied. Validating that data is transformed correctly based on business rules/logic can often be the most complex part of testing an ETL application. One typical method is to pick some sample records and eyeball to validate data transformations manually. This can be useful but requires manual testing steps and testers who understand the ETL logic. A combination of automated data profiling and automated data movement validations is a better long-term strategy. Here are some simple automated data movement validation techniques:

• Create a set of scenarios of input data and expected outcomes and validate these with the customer. This is a good exercise to be performed during requirements and can also be used during testing.

• Create a test bed with test data that includes all scenarios. Automate the process of populating data sets with from the scenarios sheet prepared in the previous step. More scenarios can be added and the testing automation will remain valid.

• Use the results of the data profiling tool to compare range and distribution of values in each field between source and target data.

• Validate correct processing of technical fields generated during ETL design such as flags and surrogate keys.

•  Validate that data types in the warehouse are as specified in the design and/or the data model.

• Set up data scenarios that test referential integrity between tables. This is especially true when you are testing behavior of child records that do not have a parent and when checking many to many relationships.

Data Quality (typically tested with designer data)

For comprehensive data quality testing, make sure to include as many scenarios as possible. Typically, data quality rules are defined during design, for example:

• If a state is spelt wrongly, look up from the master list and correct it.

•  Substitute null if a certain decimal field has nonnumeric data.

•  Validate the city and state based on ZIP code.

 
Depending on the data quality rules of the application being tested, scenarios to test might include null key values, duplicate records in source data and invalid data types in fields (e.g. special characters in date field). Data quality rules applied to the data will usually be invisible to the users once the application is in production; users will only see whats loaded to the database. For this reason, it is important to ensure users are aware of how bad data is being handled. The data quality reports often present patterns and trends that hint at underlying structural issues. Quite often, the DQ reports are published before the reporting tables are fully processed. It might make sense to stop processing and publishing of reports in the number of data quality issues passes a certain threshold.

Performance and Scalability (typically tested with mock-up data)

As the volume of data in a data warehouse grows, ETL load times can be expected to increase and performance of queries can be expected to degrade. The aim of the performance testing is to point out any potential weaknesses in the ETL architecture and design, such as reading a file multiple times or creating unnecessary intermediate files. The following strategies will help discover performance issues:

•  Load the database with peak expected production volumes (this is often much higher than current production data and some method of statistical extrapolation might need to be considered) to ensure that this volume of data can be loaded by the ETL process within the agreed-upon window.

• Compare these ETL loading times to loads performed with a smaller amount of data to anticipate scalability issues.

• The ETL processing time should also be tested module by module to understand potential bottlenecks.

• If parallelism is present in the ETL design, test it fully to ensure that there are no memory bottlenecks.

• Monitor the timing of the reject/suspended process and consider how large volumes of rejected data will be handled – often this leads to source tables being scanned fully twice and that deteriorates performance.

• Perform simple and complex outer join queries to validate query performance on large database volumes. Identify acceptable performance criteria for each query and benchmark against this. This is especially true for ad-hoc reporting scenarios.

In part 2 of this article we will look at Integration Testing, Audit, Logging and Error Handling Testing, Deployment Testing, User-Acceptance Testing, and Regression Testing

This article by Rajesh Ramaswamy, Head of the BI/DW/Analytics practice at Marlabs, was first published at  siliconindia.com.

Forrester claims that mobile BI is “no longer a nice-to-have” and BI will soon fully catch up with mobility. Gartner predicts that by 2013 33% of BI functionality will be consumed via hand-held devices.

What are the elements that need to be considered when drawing up your mobile BI strategy? How important are they?

Use Case

What are the use cases for your organization to adopt a mobile BI strategy? Most of the current usage of traditional BI is for strategic purposes by people residing in the upper echelons of the pyramid. Mobile BI to perform strategic analysis does not really make sense, unless there is a reason why your C-level executive cannot open his/her laptop. The real use cases for mobile BI lie in operational decision making. Gartner believes that “The biggest value is in operational BI information in the context of applications not in pushing lots of data to somebody’s phone”. For example, a sales person on the road may want to know the Next Best Product to be sold to a customer. A valid use case could also be in integrating device specific features in BI. For example, a door-to-door service agent may be advised on the order in which to make the house visits based on multiple parameters including proximity (GPS!), criticality, aging etc. Irrespective of the use case, it is important to be clear on it and set expectations appropriately.

The other important factor that helps finalize the use cases is by tracking the RoI. Mobile BI investments span the cost of devices as well as software, security, development and maintenance costs. So it is important to ensure that your use cases provide tangible returns. The RoI can be quantified as Revenue Enhancement, Margin Enhancement, Cost Reduction, Cost Avoidance or Capital Cost Avoidance. For example, if an iPad containing drug performance comparison across patient profile can help increase quality face time for a medical representative with a physician by x%, your sales head would surely be comfortable promising an x/5% increase in sales. That, by itself, could fund your entire project.

Target Audience

Typically, the 70% of users who don’t access traditional BI are the representative audience for mobile BI. Hence it is important to tailor your strategy to the new cross-section of people who will be your consumers. They may be less techno-savvy, more impatient to see results and have narrower but very specific needs. The real value of mobile BI is when users can fully interact with BI content delivered to mobile devices there needs to be a distinction from informative email or text messages.

Mobile BI should complement your existing BI solution it need not cover all the bases. A desktop dashboard is meant for deep analysis while a mobile BI is designed for quick and easy consumption. A mobile BI solution is meant for the mobile folks in your organization: executives, sales personnel, line managers on the shop-floor etc. Tailor your mobile BI solutions to suit the needs of these people (not those of your research analyst and financial accountant).

Standards

Don’t ignore existing devices when framing the mobile BI strategy and attempting to arrive at organization standards. BYOD (Bring Your Own Device)/heterogeneous systems have their drawbacks especially in terms of consistency, but the task of converting iOS fanatics to Apple (and vice-versa) is not a battle worth getting into. There might also be a challenge in utilizing device specific capabilities and this is another negative that needs to be considered. HTML5 is helping us bridge the divide between browser specific and device specific strategies.

Prioritize

There is a tendency in BI projects to say “we are just doing some reports on the mobile; let us roll it out in a couple of weeks”. Beware! Mobile BI projects are governed by the same fundamentals that traditional BI projects are – just even more stringent. Garbage in is still garbage out. Visualizations that don’t make sense will kill adoption. Security is even more critical. User Types are a lot more critical. The mobile BI strategy should therefore be planned and executed in a well-thought out manner and not rushed into. Ensure it doesn’t get fast tracked.

Expectations

A critical part of the mobile BI strategy is managing expectations. No one should expect feature parity with a traditional BI solution (drag and drop etc.) but there are some cool new things that can be integrated (GPS, gyroscope, touch screen etc.). Telling people what they can get and what they cannot is an integral part of the strategy via trainings etc.

Security

Security architecture needs to be revisited for mobile BI implementations and should be a critical part (if not the most critical part) of the strategy. Key business information needs to be delivered via mobile devices; else the utility of the BI project is compromised; however this carries security considerations that need to be carefully handled. All mobile BI projects transmit data from an internal firewall through a DMZ and via an external firewall before hitting the end device. It is critical that the mobile BI strategy lays out the approach for handling a whole gamut of security considerations including:

• Transmission Security
• Authentication
• Authorization
• Access
• Device Security

Miscellaneous- Bandwidth, UX and Design Considerations
Some of the other factors that need to be kept in mind when framing your mobile BI strategy include bandwidth (system and resource), mobile UX and design considerations (templates, interactivity, device features), ability to reuse existing investments, strategy to reuse design for both traditional and mobile BI etc.

Mobile BI is something that can only be ignored at your own peril; but don’t just jump into the waters without some thorough preparation.

This article by Rajesh Ramaswamy, Head of the BI/DW/Analytics practice at Marlabs, was first published at  siliconindia.com.

Here’s an article by Shiju Varghese from the Marlabs Cloud and Mobile Center of Excellence (CoE) that explains how to install Napa Office 365 Development Tools onto your Office 365 developer site and build apps for SharePoint and Office using the Napa developer tools.

Click here to read the article on Building Apps with Napa Office 365 Development Tools

In this video, Shubhatara from Marlabs introduces you to  Report Builder 3.0, outlining its new features.