Software testing

The other day a friend asked me what a tester does. In other words what is software testing? What’s a bug? What are the key terms associated with testing? This is a humble attempt to address these questions and initiate the uninitiated to the world of testing.

Software Testing is a process of software analysis and defect detecting. It’s the art (pun intended) of identifying as many defects as possible in order that they can be fixed. A Defect (bug) is the nonconformance to requirements or functional specification. It is something that does not correspond to valid Customer’s expectations that are assumed but may be not described in product requirements.

The Test Manager in conjunction with the Project Manager develops a Test Plan which describes what, when, how and who will be involved in the testing process. This basic document also describes a list of tested components, quality criteria and risks of testing, resources and graphs of testing, testing strategy and testing types test budget etc.

The test lead/ senior test Engineer develops Test cases which is basically a set of test inputs, execution conditions, and expected results developed for a particular objective, such as to exercise a particular program path or to verify compliance with a specific requirement.

Classification of Testing Types:

Static Testing is a process, which is used for verifying any work product in terms of code, requirements, functional specification, architecture and design documents, etc. Static testing is one of the most effective ways of defects detecting in the early stages of a product process.

Dynamic Testing Dynamic testing consists of launching the program, running all functional modules and comparing the product’s behavior with expected one using user interface.

Black box testing. Testing software based on functional and business requirements at launching and operating it without knowledge of the internal structure or program source code. A tester tests a product so as an end-user would work with it at the time of its launch and operation. This method checks the proper working of all functions and whether they conform to functional requirements.

White box testing (glass box testing). The Tester uses his or her understanding of source code and accesses the code to develop and execute test cases. This method tests the architecture of the system. It tests the design and programming that goes into building system. White box testing is usually applied when application is not entirely assembled, but it’s necessary to check each of the components, modules, procedures and sub-functions.

Unit Testing. This level of testing is usually carried out by the software developer to perform the testing of a separate module of the system. It may be a testing even of any particular part of the code (class).

Integration Testing. Is the testing of various components of an application (in their integrated form) to determine if they function well together. Also, interactions between applications of big system can be checked with this type of testing. In this case this testing is known as Cross-product testing. Usually it is performed after unit and functional testing has been carried out.

System Testing refers to that type of testing which checks the operation of the system as a whole. It is usually associated with the testing of the functional as well as non-functional requirements of the system. 

Functional testing is the process of attempting to find discrepancies between the program and its functional requirements or specifications. Its goals are

Posted by Prakash at 10:16 AM | Permalink | Comments (0) | TrackBacks (0)

Introduction

Bluetooth a short range wireless communication technology developed for use at home, office and Personal Area Networks. Over the years Bluetooth integration has been achieved in mobile phones, Personal Digital Assistants (PDAs) and other consumer devices. When blue tooth was conceived, an essential element of the technology was its requirement for a low expectation of end user technical ability and minimum levels of user setup and configuration for ease of use. This was adopted to ensure that widespread adoption and utilization of Bluetooth technology by the general public could be achieved

A direct consequence of this requirement some users are not aware of the functionality Bluetooth offers and its potential for exploitation and in many cases leave the default settings on their devices unchanged. Bluetooth enabled devices are vulnerable to exploitation using a range of methods including Bluesnarf, Backdoor and Bluebug.

Bluetooth vulnerabilities

The use of Bluetooth technology to access restricted areas of a users’ device without their knowledge or approval for the purpose of capturing data e.g. contacts, images, lists of called missed, received or dialed, calendars, business cards and the device’s International Mobile Equipment Identity (IMEI) is known as Bluesnarf. Bluesnarfing works by using the push profile of the Object Exchange protocol (OBEX) which is a built-in Bluetooth functionality for exchanging electronic business cards.

Instead of pushing a business card the Bluesnarf attack pulls using a “get” request looking for files with known names e.g. phonebook file (telecom/pb.vcf) or calendar file (telecom/cal.vcs). This vulnerability exists due to the manner in which the OBEX push profile was implemented in some of the early Bluetooth enabled phones, which did not require authentication from other Bluetooth devices attempting to communicate with it. Accessing information by Bluesnarfing was thought to only be possible if the users device is in "discoverable" or "visible" mode, but Bluesnarf attacks have being carried out on devices set to “non-discoverable” mode.

To achieve this the Bluesnarfing software needs to address the device by its unique 48-bit Bluetooth device name. For example, uncovering the device name is possible using software applications such as RedFang. This application uses a brute-force approach to discover device addresses by systematically generating every possible combination of characters and recording those combinations which get a response. Fortunately this approach is time consuming, potentially taking hours of computation.

Current scenario

The subsequent release of the Bluetooth specification 1.2 has addressed this problem by adding an anonymity mode that masks a device’s Bluetooth physical address. In addition a major privacy concern related to this type of attack is the possibility of obtaining the IMEI of a device which can then be utilized to uniquely identify a phone on a mobile network and could also be used in illegal phone cloning. This could give someone the ability to use a cloned subscriber identity module (SIM) card to track a mobile device and by inference the user carrier without their knowledge. Recent firmware upgrades have corrected this problem but many phone owners have not installed them

Nokia the World leading Mobile phone manufacturer recently made this announcement “Nokia is aware of claims that there are security issues relating to malicious attempts by hackers to access another user’s mobile device featuring Bluetooth technology, an act currently referred to as “Bluesnarfing”. Affected models include the Nokia 6310, 6310i, 8910, 8910i mobile phones. “

Nokia recommends the following in order to prevent “Bluesnarfing”. In public places, where phones with Bluetooth technology might theoretically be targets of malicious attacks, reliable ways to foil potential hackers are:

• To set the device to "hidden" mode using the Bluetooth menu. Personal devices like headsets can still connect to the phone, but intrusion is much more difficult since the hacker will have to know or guess the Bluetooth address before establishing a connection.

• If a user wants absolute security, they can simply “switch off” the Bluetooth functionality of their mobile phone. This will not affect other functionalities of the phone.

Vivek GD is Software developer with the Bluetooth software development team at Binary spectrum.

Posted by Prakash at 07:39 AM | Permalink | Comments (0) | TrackBacks (0)

Here are some similarities, differences, advantages and disadvantages of architecting/developing applications in .NET over J2EE.To summarize these 2 technologies for a layman to understand would be:

 .NET – Relates to Productivity, Simplicity and “Out-of-the-box”.

J2EE – Relates to Flexibility, Complexity and “Do-it-yourself”.

1. To bring about a comparison with respect to the Architectural Philosophy, below are some of the points that have been identified:

            J2EE

 J2EE was created to give something better and more scalable than CGI or CORBA and to help standardize pervasive enterprise technologies such as message oriented middleware (MOM). As such, J2EE had some - great hits in Servlets instead of CGI,
- lackluster - EJBs instead of CORBA Hence the J2EE is a result of a powerful but also very complex framework.

Some of the big architectural advantages that one can enjoy when working on J2EE are the flexibility and the extensibility rendered by the J2EE API’s, which leaves ample room for open source innovations. Another noted feature is that J2EE can run on any platform.

Amidst all this a major concern would be the need for expensive application server to run its applications where they often add very little value relative to its license cost.

J2EE has limitless options for implementation of domain models backed by object-relational and cross-enterprise integration tools.

            .NET

            The major architectural additions to the .NET Framework were:

<!--[if !supportLists]-->·         <!--[endif]-->The "adoption" of the Java language as C#.NET

<!--[if !supportLists]-->·         <!--[endif]-->S.O.A.P. (Simple Object Access Protocol) and its native support for OO-to-XML

<!--[if !supportLists]-->·         <!--[endif]-->Re-design of VB into a VB.NET to make it, as Java/C# was, fully object oriented.

The architectural advantages identified here is that the focus is on the developer and hence is easy to work with, it follows a simplified transition path from the client-server to the enterprise development model. But unlike J2EE where it is platform independent, .NET is restrained to just one platform.

.NET has a harder time supporting database independent implementation of the domain model because of its less mature or mapping tools.

1. To bring about a comparison with respect to the Framework Components, below are some of the points that have been identified:

            .NET

 The major architectural components of the .NET framework that most of the developers use are ASP.NET pages, plain objects written in some .NET language, ADO objects and Web Services.

            J2EE

 J2EE design is heavily based on design and architectural patterns such as "MVC - Model View Controller", Facade, Factory, Layers which makes it somehow more complex to understand to the uninitiated.

In general, the most commonly used core components in J2EE are Servlets, JSP and JDBC for database access. These roughly correspond to "code behind", ASP.NET and ADO.NET components in .NET.

J2EE defines one or more sets of components for enterprise tasks that are not even defined in .NET. So in J2EE we have:

<!--[if !supportLists]-->·         <!--[endif]-->EJB for object remoting, message (as in MOM) processing and relational persistence

<!--[if !supportLists]-->·         <!--[endif]-->JMS for Message Oriented Middleware (MOM) abstraction

<!--[if !supportLists]-->·         <!--[endif]-->JDO for relational persistence

<!--[if !supportLists]-->·         <!--[endif]-->JCA for non-relational enterprise access

<!--[if !supportLists]-->·         <!--[endif]-->JAAS for security services and SSO abstraction and so on.

Not very many people write their web apps using Servlets and JSP only. Most of the J2EE developers use either aging but widely popular Struts framework, official J2EE JSF web framework, more recent and innovative Spring MVC or WebWork, etc.

1. To bring about a comparison with respect to the Web Components, below are some of the points that have been identified:

            .NET

 In general, ASP.NET is easy to work with; the tool support through Visual Studio product line is very good. There is also a very good set of components available for the common web development tasks.

Its code behind concept is easy to understand and it is flexible enough to extend through smart use of design patterns. I like how ASP.NET manages to keep configuration files and application settings under control. Unlike J2EE, there are no verbose xml files for every little component you want to use. You specifically configure only special cases and exceptions.

Another attractive feature is how Microsoft incorporated Atlas (their AJAX frameworks) into ASP.NET. Deployment of ASP.NET applications is very easy.

            Some of the concerns that have been identified with ASP.NET are:

<!--[if !supportLists]-->·         <!--[endif]-->The increased risk of code replication which in other terms increases code duplication and could create a significant maintenance burden.

<!--[if !supportLists]-->·         <!--[endif]-->Addition of data binding objects, including query definitions into the ASP.NET pages itself.

            J2EE

Servlets came as a better, faster, more expressive replacement for then popular CGI-BIN. They are very POST/GET and HTTP parameters oriented. API is easy to work with but it is very bare. It could be categorized in the following procedural format:

            Request, Response, Session and Context.

            The advantages that are seen in its use are:

<!--[if !supportLists]-->·         <!--[endif]-->Portability

<!--[if !supportLists]-->·         <!--[endif]-->Extensibility

<!--[if !supportLists]-->·         <!--[endif]-->Richness and Sophistication of available Value Add Open Source Frameworks

            Some of the issues that have been identified with J2EE are:

<!--[if !supportLists]-->·         <!--[endif]-->Complexity of the deployment model

<!--[if !supportLists]-->·         <!--[endif]-->Bareness of the core API

<!--[if !supportLists]-->·         <!--[endif]-->Over-saturation with choices

<!--[if !supportLists]-->·         <!--[endif]-->Need for application server.

 The Author Hermon Peter is a Software Engineer at Binary Spectrum.

Posted by Ashok Kumar at 12:52 PM | Permalink | Comments (1) | TrackBacks (0)

Mobile..

Mobile..

Mobile..

In today’s scenario - a very common name, a technology which in recent years has seen growth in leaps and bounds. As the economics of demand set in, competition between the various Mobile Manufacturing companies hots up. Complementing all this is the new generations of competent mobile application developers, who are making their dream come true.

The most commonly used mobile application development platforms are

1. Sun’s Java 2 Platform Micro Edition – J2ME, and
2. .NET Compact Framework (CF)

 Both have their own advantages and disadvantages,

J2ME, which has been around for quite a while, is the platform of choice for the application developers, as it is beholds the same JAVA motto, “Compile Once, Run Anywhere” and this holds true for mobile application development. J2ME developers can write their code without worrying about cross-platform portability.

In recent years Microsoft has extended its .NET environment to the Windows operating system based mobile devices with the .NET Compact Framework (CF). .Net CF runs only on one operating system – Windows.

For the Mobile Application Developers, how do these two platforms measure up? What are the strengths and weaknesses, of each platform? And Last but not the least, which of these is the best suited platform for developing and deploying your mobile application?

To answer these questions lets examine Bluetooth – a very important emerging standard for wireless integration of small devices. It is said that the “sky is the limit” in terms of applications that will be available in the not so distant future. The JSR-82 specification standardizes a set of Java APIs to allow Java-enabled devices to integrate into a Bluetooth environment.

The Java Bluetooth API basically relies on the Java Generic Connection Framework (JGCF), which has been around for a long time. One of the main advantages is that the Bluetooth API can be made accessible for a broader range of systems as the technological advances occur.

The Java APIs for Bluetooth defines two packages:

1. javax.bluetooth - for the core Bluetooth API, and
2. javax.obex -for the Object Exchange (OBEX) protocol.

All Bluetooth applications need these components for:

1. Stack initialization,
2. Device management,
3. Device discovery,
4. Service discovery, and
5. Communication.

As per the JSR 82 specifications, a Bluetooth system should have a Bluetooth Control Center (BCC). The BCC, is defined as the heart of a Bluetooth System, it allows a user or the OEM (Original Equipment Manufacturer) to define specific values for certain configuration parameters in a stack. In particular, it would be used in a stack initialization.

The API is intended to provide the following capabilities:

            1. Discover devices and services

            2. Register services

            3. Establish connections( it may be OBEX, L2CAP or RFCOMM) , and finally

            4. Conduct these activities in a secure fashion

The Mobile Information Device Profile (MIDP) is a specification which standardizes Java on embedded devices and is a part of Java Micro Edition Framework (J2ME framework). MIDP devices are expected to be the most prevalent class of devices to incorporate the above said specifications, and the specification allows for the coexistence of Bluetooth APIs and MIDP. This specification was developed under the Java Community Process, and is known as the JSR 82.

We conclude that the J2ME framework is, with its enriched Features, is one of the most widely used. Sun’s J2ME wireless toolkit 2.2 has a Bluetooth simulator and also supports OBEX and is the basic available development Kit for J2ME applications.

The Author Somnath Das is a Software Engineer at Binary Spectrum .

Posted by Ashok Kumar at 08:50 AM | Permalink | Comments (1) | TrackBacks (0)

1. Use the Web Project Conversion Wizard
   
2. To ensure browser compatibility XHTML compliance has been enforced in .Net 2.0, one good idea would be to run your aspx pages through an XTHTML parser and fix any broken pages.
   
3. If current .Net 1.x applications use AJAX framework, either convert them to ATLAS (preferred) or build applications with the corresponding AJAX 2.0 libraries.
   
4. In usage of Object model calling a protected constructor directly is not allowed for security reasons, but calling through base constructor is permitted.
   
5. You should consider Re-designing the entire layout to a Master page layout.
   
6. Use more ATLAS components to reduce post back delays
   
7. Re-visit pages that were cached to support Sql Notifications hence reducing rounds trips between database and application layers.
   
8. Re-organize complex screens to use the new Wizard control.
   
9. For more organized and easily maintainability of code convert the entire aspx codebase to partial classes.
   
10. Use Site Navigation features of ASP.Net 2.0 to manage breadcrumbs with ease.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspp/html/webprojectsvs05.asp

http://msdn2.microsoft.com/en-us/library/ms379587.aspx

Posted by Ashok Kumar at 08:05 AM | Permalink | Comments (0) | TrackBacks (0)