Monday, July 30, 2012

Database Testing

Why test the database?

The database persists data that your application (and organization) depends on. The data thus persisted is most often of mission-critical nature and a key asset for the organization. Also, many of today's data-enabled applications implement a fair amount of their functionality and business logic in the database itself. For an enterprise class application, the data in the database would be accessed and updated (insert/modify/delete) simultaneously by a large number of users (think thousands to millions depending on the scale of your application's usage).

The above statements highlight a few areas where database testing is needed. One, to validate the quality of data being persisted. Two, if we plan to test the application code, it is imperative that we also test the code in the database which implements the business functionality and three, we should plan for non-functional database testing to support the usage of the database in a real-world deployment scenario.

Let us briefly look at the above mentioned database test areas.

1. Data quality testing

Testing the quality of the data may be approached in three ways - data validity testing, data integrity testing and data format testing.

a) Data validity testing - is done to verify the validity of the data that is stored in the database. When data is entered via the front end application, check if the data is correctly updated in the back-end database. Apart from the positive checks, look for other behavior such as data truncation, verify how null/empty field values are handled, verify how special characters or code snippets are handled in the database. Check that the right columns in the right tables are being updated. Data validity testing normally involves use of SQL queries to validate the data.

b) Data integrity testing - involves testing referential integrity and application of constraints (foreign/primary key). When a data field is subject to modification (insert, update or delete), the database should be verified for appropriate changes to related entities such as primary key/foreign key relationships and that referential integrity of the data is maintained

c) Data format testing - involves verifying the size and type of fields that store data in the database with those that accept data in the application. This can help identify mismatches between the type or size of data that is accepted by the front-end vs what the database can store. Example: the application may accept text data but try to store in a numeric or date field in the database or else the application may accept data of greater length than the max length for the corresponding field in the database. This may not throw errors during routine application usage but may store incorrect or erroneous data in the database which could have repercussions elsewhere or at a later stage
   
2. Database code testing - involves testing the code in the database which implements business logic and functionality. Examples of such code include, stored procedures, views (read-only/updateable) and event driven items such as triggers. Each stored procedure is tested distinctly for its functionality. When a stored procedure implements multiple functions, each function is tested separately. Stored procedure testing would look at testing the arguments that are passed to the stored procedure in terms of the number, type and order of arguments plus the return value. Both positive and negative tests can be devised to test stored procedures. Views both read only and updateable are tested either as stored queries that dynamically retrieve values from the database and/or allow updates to the database. In case where updates are allowed, data validity and integrity testing is done. Event driven items are tested by verifying the events that could trigger actions and the actions themselves for functional correctness

3. Non-functional database testing

In most real-world mission critical deployments, to ensure database scalability, security, availability and recover-ability with minimal/no-loss of data, it is important to test the following non-functional areas

a) Database performance testing (load/stress/longevity/scalability)
b) Database security testing
c) Database replication testing
d) Database fail-over testing
e) Database recovery testing

Tuesday, January 31, 2012

SOA Implementation Methodology: What to look for?

SOA Implementation Methodology: What to look for?
Organizations planning to implement SOA should implementation methodologies which covers end-to-end implementation of the SOA roadmap. It should help organization to select the appropriate approach for SAO implementation and set up the IT goal. The methodology should provide visibility of challenges, risks and ROI. 
It should be classified into phases: 
• Formalizing the roadmap, domain model and goal model 
• Providing the component, message, service and information specifications 
• Providing the final implementation based upon standards 

SOA Governance framework: 
Enterprises SOA governance framework should be based upon Open-Source platform. Framework refers to the standards and policies that govern the design, build and implementation of an SOA solution and the policies that must be enforces during runtime. Organizations should also indentify complete testing framework for Unit Testing, Functional Testing, Integrated Testing and Process-level Testing to ensure a high quality of service.

iTKO LISA Vs QTP

Feature iTKO LISA Quick Test Professional
Cross browser testing IE, Firefox, Safari, etc IE and Firefox possible
Supported Technologies LISA supports DTHML/JavaScript, AJAX, Java Applet, Swing, Flash/Flex, Microsoft ActiveX, Oracle Apps Separate license required
SOA Test validation LISA has advantage of connecting middle layer interfaces to test SOA Architecture Scripting required to connect interfaces. Limited to Request and response validations
Validations or Check points Assertions available with support for more than 60 middle layer technologies Check points possible for supported technologies
User friendly Interface Test flow is represented diagrammatically and easy to understand. Test Flow is complex
Control test flow Easy to rearrange test flow as it is Drag & drop Rearranging the Test flow is complex and there is dependency on QTP resource
Implementing Validation Codeless filters and assertions Scripting by use of “if conditions”
Synchronization Easy to create Sync point at step level as well globally. Scripting required
Creating Functions Easy to convert test cases in to sub process. Function creation is possible using scripting
Database Validation Codeless effort for DB connectivity , fetching data and comparing with application Scripting required to validate data base , there are some check points through which we can connect data base without code but still required coding to validate application
QC Integration Available Available
Load & Performance Testing Available Not Possible
Stubs and Drivers LISA Virtualization available to overcome testing constraint Not Possible
Object Identification (GUI) Customization is difficult to implement. Record and Playback option available Customization possible like Descriptive programming
Coding according to Functionality to validate Data on App(GUI & Web Services) Required Java coding knowledge Possible with VB scripting in QTP
Customized report Supports Excel, CSV and pdf without single line of scripting We can customize reports into various formats with the help of scripting
Web Services Testing Easier way without scripting Scripting required or else can use Web service add-in still need some scripting for validations
Automation using Design documents Not Possible Possible