Monday, June 12, 2017

Mobile Compatibility Testing


In present world, smartphones and tablets are the popular medium to access the internet for any requirement, forcing organisations to develop mobile applications of their service offerings.

The hardware and software are developed independently but function together based on product expectations. For example, a web application is developed in PHP/.NET/Java and is expected to work properly on all available mobile devices and different web browsers.

Here the question arises: how will an application perform functions as expected on client’s devices? While fulfilling such expectations, we need to keep in mind that there are numerous combinations of web browsers and its versions, operating systems and plurality of mobile device models. The process to validate application behaviour is as expected across the mobile devices and browsers based on application requirements is known as mobile device compatibility testing.

On mobile devices, users can have native/web or hybrid applications and each application type will have certain difference in display/functional behaviour/look n feel etc. While testing each type of application, team needs to consider few points. 

Web applications are written in HTML5, navigate to a special URL through web browsers. Testing team need to consider following points while testing web applications:

1. Content: Entire website/product cannot fit on small screen mobile devices
2. Navigation: In-spite of showing full size website/application, different navigation methods are required
3. Size: Font and objects needs to be resized for small screen devices
4. Functions and Feature: On different devices and operating systems, application behaviour is always unpredictable

Native applications are installed on the device and are accessed through icons on the device home screen. They are installed through an application store like Google Play or Apple’s App Store. These applications use device’s notification system and can also work offline, hence testers need to consider following points in testing:

1. Application installation and upgrade process through application store and related issues
2. Fewer applications dependent on the operating system than with responsive Web design applications
3. Many versions are required for each operating system

 Hybrid applications are partially native and partially web applications. They can be installed through application store and access through web browsers as well with special URLs hence testing team need to consider all the above discussed points while testing such applications and be more focused. Application content, UI, functionalities should be same everywhere.

While doing mobile device comfortability testing, we need to cover maximum devices and ensure results are close to 100 percent of users’ device base. We also need to identify the perceived bugs to the corresponding layer – operating system, web browser, device features or skins? Also need to focus on the functionalities which are probable to fail in the case of a technology upgrade or a new device launch. 

Now we will talk about the five step approach to make mobile device compatibility testing more agile and scalable.
1. Develop Device Compatibility Repository: Analyse the major available mobile devices for following information like hardware feature, platform details, technology features supported (audio/video and image format etc.), hardware features included, and network and other technology features supported by the device. This device structure list will be useful for device compatibility testing.
2. Shortlist the device list based in compliance: Short-list devices for specific project based on region or country individuality. This can help to cover up lost popular devices in the region.
3. Prepare device list based on its compatibility: For better visibility, prepare list of compatible v/s partially compatible devices to confirm features which may not work and cause issues in partially compatible devices. In some cases, the potential device is rare or highly expensive, hence team uses emulators for development and testing. iOS and android emulators are mainly designed for native applications, however their default web browsers accurately act how the application will behave on a real device.
4. Execute tests on most compatible devices: To ensure 100% application functionality accuracy, focus on minimum one device from each manufacture if testing is not possible on all the devices given in the list. Execute tests on partially compatible devices as well. Perform testing on the latest and most widely used devices as well and ensure initial focus on the functions that might be influenced by unsupported features.

To summarize, Native, hybrid, or web application are ultimately to render the needs of the mobile users. Hence the majority of time utilized on mobile device compatibility testing is focused on the executing functions as the customer would perform on different devices, operating systems and web browser combinations and confirming that the screens and behaviour is as expected. Although there is no unique best method as each have strengths and weaknesses. The choice of one device/application versus the other depends on each company’s unique requirements.

Multi-channel, Cross-channel, Omni-channel: What’s the difference?




Initially, companies used mails, personal calls or visits as communication channels to promote their products. But with the advent of new technologies/channels and increase in usage of electronic devices, the customers have many alternatives available to explore and complete a purchase activity.
For example, now a company can educate a prospect about their offerings via an email or message, who might explore the company website or physical store, search online about the product details and other buyer reviews before purchasing the product on smart phone. This entire process may swap in different combinations. So keeping this schema in mind, organisations are leveraging these channels to influence customer’s buying decision. 
The question arises: how to ensure that these channels communicate with each other accurately? The answer is hidden in the behaviour of these channels categorised as omni channel, multi channel and cross channel. A software development company needs to understand these channels before any product development and delivery.

MULTI-CHANNEL approach: Companies use multiple channels (e.g. social media, email, PPC, print ad, retail store, website, promotional event, product’s package, or word-of-mouth) to engage their customers across multiple touch-points. Each channel requires its own strategy and can be managed separately. Multi-channel is based on the assumption that customers have their preferred way of interacting with a company.
Suppose for a TV cable station company, development team has developed a site with responsive design where users can search about show schedules, news, and much more through any communication device. To ensure quality, testing team needs to set up a multi-channel test environment for users to perform common functions on desktop, smart phones, and tablets to determine any bugs. Here, rather repeating the testing on all the devices, testing can be performed on one device like one set of users could test on the desktop experience, a second set could take the mobile phone, and a third set could be Tablet. They will test application functionalities on different device. They will review and confirm the performance of various features of the application. 

CROSS CHANNEL approach: Designed to satisfy target customer requirements for a convenient and flexible buy/sell process as they navigate through various channels to complete the same purchase/service. For example, A person can receive newsletter featuring a specific product and decides to search more on website and further purchases from a physical store. In CROSS Channel testing, tester has to test the same functionality through different channels as user can access it from any channel. In this scenario, Tester can test two platforms in no particular order be it desktop first, and then smart phone or vice a versa. This requires application functionalities are designed to be performed seamlessly across all touch points.

OMNI-CHANNEL approach: The concurrent usage of two channels, like using a smart phone while in-store, or a tablet while watching on television. This denotes the uniformity between different channels to facilitate and streamline customer interactions. It also allows customers to access real-time information, irrespective of channel limitations. It also empowers business to cease the gap between on-line and off-line application configurations. This means that if customer has saved his/her configurations and preferences on one channel then it must be memorised and accounted for across channels. During testing, tester creates an account as a customer using one channel to check whether credentials and other preferences are saved across channels.

Testing approach for above channels:
1. When a tester tests a single application across multiple devices, Omni-channel testing is done. Whereas if tester tests the same feature on a range of devices, Multi-channel testing is opted. Next when tester focuses on how the customers view websites on their devices across screen resolutions and sizes, Cross channel testing is done.
2. In Omni-channel testing, tester needs to test entire application with all the users across all devices, login across devices and share about seamless experience. Whereas in Multi-channel testing, tester can perform testing with single user on a single device and all the features.
3. In case the focus is on customer experience, tester needs to select Omni-channel testing whereas if company plans to analyse the performance of every channel/device, tester should go for Multi-channel testing. When tester focuses on few device- or browser-specific then cross channel testing is done.
4. Omni-channel approach can be used where companies believes that the customer might initiate an activity on one channel and eventually move on another channel for various possible reasons whereas Multi-channel approach can be used where companies wants to include multiple platforms to engage the customers.
So, we can conclude that adopting any channel testing approach will depend on the software product domain. For instance, a retail domain based product may require Omni-channel testing approach, while a banking product needs a multi-channel approach to test its application.

Same article is published on: https://www.linkedin.com/pulse/multi-channel-cross-channel-omni-channel-whats-priya-sharma-trivedi?trk=v-feed&lipi=urn%3Ali%3Apage%3Ad_flagship3_feed%3BktsLVDnQqObtBlNWTAqeFg%3D%3D

Thursday, February 18, 2016

Significance of Database Testing



Database is a valuable asset for each and every company in today’s technology world. It is crucial and acts as the backbone of any software application. Without an appropriate database, we cannot imagine the application systems to function as per user requirements.

Initially the banks were using manual processes to record the different transactions, but the technology help in streamlining their processes.  The software applications are regularly updated to provide better functional benefits and convenience to bank.  What happens if while migrating from one application to another the underlined database is not transferred properly? The transactions will all get messed up and the basic use of technology gets defeated. So we need to test our database for all related attributes. 

The organizations generally utilize different applications having the same database concurrently. These applications need to be upgraded regularly as per latest market requirements. We have to migrate the database carefully between the different applications. It is important to have a good database management system due to high relevance of database and data consistency.
In general, an application development includes programming code, configuration files, CSS Files, JQuery files, third party tools, SQL files, and other external systems.  On the other hand, testing an application means testing each and every part separately and also testing how all these parts communicate within themselves and with external factors. 

Traditionally, the data related testing is done at the GUI/Client Layer or Business Logic Layer. Apart from testing the various codes and attributes, testers would also need to test the vital part in the system-the database.

Database testing is a process of testing the data stored in the database. It requires some in depth knowledge of the given application and a pre-planned approach to test the data. It is essential when application has persistent storage of data, have centralized control over data, control on data redundancy, control on consistency and integrity, includes multiple user support, data sharing practice, data documentation, data autonomy, control over data access and moreover client is concerned for security, backup and recovery of data.

There are many database tools available like MS-Access2010, MS SQL Server 2008 r2, Oracle 10g/11g, Oracle Financial, MySQL, PostgreSQL, DB2 etc. The software applications must be developed using any of the database tools.

The question comes in mind that what we have to test in database testing. The main attributes to be considered in testing are:
  1. Accurate mapping of different screens of application and the relationship of its DB: For all CRUD operations, verify that respective tables and records are updated when user clicks ‘Save’, ‘Update’, ‘Search’ or ‘Delete’ from GUI of the application as per the design documents.
  2. Exhaustive testing of ACID properties of DB Transactions: ACID properties refer to the ‘Atomicity’, ‘Consistency’, ‘Isolation’ and ‘Durability’. Proper testing of these four properties must be done during the DB testing activity. 
  3. Data integrity: Maintaining and assuring the accuracy and consistency of data over its entire life-cycle is a critical aspect to the design, implementation and usage of any system which stores, processes, or retrieves data.
  4. Implementation of Business Rules: The business rules describe the operations, definitions and constraints that apply to an organization and are put in place to help the organization achieve its goals and objectives.
In order to test the DB accurately, a tester should possess good knowledge of SQL and specially DML (Data Manipulation Language) statements. The tester should also acquire understanding of internal DB structure of AUT (Application under Test). Once these pre-requisites are satisfied, then the tester can test the DB with more accurate parameters.  

Database is the engine of any client/server system. What if any malfunctions appear it may cause system deadlock, data corruption, data loss and bad performance. Hence, the importance of database testing in software testing should not be ignored.

Database Testing & its Importance

Database is the most valuable asset for every company because it is the most critical and the backbone of any software applications. Without an appropriate database, the application system will not be able to function as per user requirements. 

There are many organizations/scenarios where many different applications use the same database at the same time and these applications upgrade time to time as per market prerequisites therefore while changing the applications, nobody throws away the database however they migrate it very carefully. Because of such significance of database, it is important to have a good database management. As this could cost a company if any factor destroy the data consistency.

An application development includes programming code, configuration files, CSS Files, JQuery files, third party tools, SQL files, and other external systems.  Testing an application means testing each part separately and testing how all the parts communicate.

Traditionally all the data related testing is done at the GUI/Client Layer or Business Logic Layer. Apart from testing the various codes and attributes, testers would need to test one of the most vital part in a system-the database.

Database testing is a process working with data that's stored in the database. It involves some in depth knowledge of the given application and requires more defined plan of approach to test the data. It is essential when application has persistent storage of data, having centralized control of data, need to control of redundancy, need to control of consistency and integrity, having multiple user support, want sharing of data, data documentation needed, data independence, control of access is required and client has concerns for security, backup and recovery

Database testing, basically, includes the following:-
Ø  Data Accuracy & Validity (Field size validation)
Ø  Data Integrity (Check constraints, insert, delete, update)
Ø  Database Objects (Stored Procedures, Views, Tables)
Ø  Data Migration (Import, Export)
Ø  Data Transaction Consistency and Concurrency (States & Locks)
Ø  Performance related to database (Indices, number of triggers and procedures)
Ø  Security related to database - Data Accessing ( unauthorized access)

There are many database tools  available like MS-Access2010, MS SQL Server 2008 r2, Oracle 10g/11g, Oracle Financial, MySQL, PostgreSQL, DB2 etc. and every software application must be built using any of these database tools.
Database designing is done in three phases: Conceptual Designs -> Logical Design-> Physical Design

When the application is under execution, the end user mainly utilizes the ‘CRUD’ operations facilitated by the Database Tool.
Ø  C: Create – When user ‘Save’ any new transaction, ‘Create’ operation is performed.
Ø  R: Retrieve – When user ‘Search’ or ‘View’ any saved transaction, ‘Retrieve’ operation is performed.
Ø  U: Update – when user ‘Edit’ or ‘Modify’ an existing record, the ‘Update’ operation of DB is performed.
Ø  D: Delete – when user ‘Remove’ any record from the system, ‘Delete’ operation of DB is performed.

Now, the question comes in mind that what to test in database testing:
  1. The mapping between different forms or screens of application and the Relations of its DB is should be accurate and is also according to design documents. For all CRUD operations, verify that respective tables and records are updated when user clicks ‘Save’, ‘Update’, ‘Search’ or ‘Delete’ from GUI of the application.
  2. ACID properties of DB Transactions refer to the ‘Atomicity’, ‘Consistency’, ‘Isolation’ and ‘Durability’. Proper testing of these four properties must be done during the DB testing activity. 
  3. Data integrity refers to maintaining and assuring the accuracy and consistency of data over its entire life-cycle, and is a critical aspect to the design, implementation and usage of any system which stores, processes, or retrieves data.
  4. To Ensure Accuracy of implemented Business Rules.
In order to test the DB properly and accurately, first of all a tester should have very good knowledge of SQL and specially DML (Data Manipulation Language) statements. Secondly, the tester should acquire good understanding of internal DB structure of AUT. If these two pre-requisites are fulfilled, then the tester is ready to test DB with complete confidence. 
A back end is the engine of any client/server system. If the back end malfunctions, it may cause system deadlock, data corruption, data loss and bad performance. 

Hence, the importance of database testing in software testing should not be ignored as it is the data which is visible to the user as it will help the tester identify the root cause of the problem apart from detecting the hidden bugs in the database.  

Golden rules for software testing



Testing is termed as a process of evaluating a system or the sub components with the purpose of understanding whether the system fulfils the requirements or not. It helps identify the gaps, errors, or any missing requirements against the defined requirements. 

Based on my testing experience, I feel that testing is a basic human nature of examining things before accepting or agreeing upon. In case of software testing, it starts with analysing requirements much before actual software development. 

Software testing can be grouped into four major phases:
  • Unit Testing (by developer or a separate white-box testing team)
  • Integration Testing (by Development Team)
  • System Testing (by Professional Testing Team)
  • Acceptance Testing (by Business Users)

The few golden rules of software testing to be considered are:
  • Identifying bugs in the early stages: Ideally, software testing process should start once the testing team gets the requirement specification document from a client or development team. In involves analysing the specified requirement documents prudently, and resolving the questions at the earliest. The issues acknowledged during early stages facilitate the development team to develop the software with correct functionalities.
  • Preparation of Test documents: Once the documents are reviewed, the next step involves planning of test strategies, test scenarios, test cases and respective test data if required.
  • Quality remains the key point: A Tester has to stick to the quality and perform quality testing instead of bugs count, complete test cycles on time and perform software/product quality. During testing, the main focus should be based on client business requirements and expectations.
  • Descriptive Bug report: Whenever tester reports a bug, he/she should provide comprehensive document about the bug occurrence with supportive screenshots. Do suggest the severity and priority of the bug. Do to mention the expected and actual results to guide the development team for the bug resolution process.
  • Include Regression Testing: After a test cycle completion, Development team fixes logged issues in bug management tool and release the software for testing again. With bug verification, always ask the development team for impact analysis report and perform regression testing to make sure that there is no impact of the bug fixation process.
  • Test with Real scenarios and Test data: Negative testing should be done to test robustness of the software, however, make sure that prepared test scenarios and test data is quite real as predictable by client end users.
  • Maintain record of change requests: Once the project is completed one or few releases, usually documentation of change requests is not done by the development team. In this situation, as under change request management, testers should maintain test cases based on the changes with the priority status.
  • Don't fight for bug fixes: Testers need to report all possible bugs in respective bug management tools with the severity and priority of the bug fix. However the bug fixation selection should be decided based on business urgency by the client, business analyst and technical managers. Definitely testers should give inputs to them with the accurate reasons for the necessity of fixing bugs.
  • Bug Leakage analysis: After product release to client and UAT completion, if bugs are raised by client, Tester should do an analysis of bugs and provide inputs on the bug leakage. Also needs to prepare preventive actions for the future quality releases.
  • Focus on the software testing process, not on the tools: There are many free and paid tools available in market for testing and test management to make our tasks easier. However, testers should always focus on core testing processes; the other tools can be used as additional support only.
  • Don’t presume more of automated testing: Automated testing can be beneficial and a time saver, however sometimes it can be expensive and doesn’t provide the required results.

The requirements analysis and accurate testing are the major reasons of software projects delays/ failures. These golden rules would definitely push all testers to hook on to it for the help in testing. Utilising these rules in a testing project will help in delivering quality software products on time.