Backend Testing Process _ Search a Reply

8/13/2019 Backend Testing Process _ Search a Reply

1/20

1/15/2014 Backend Testing Process | Search A Reply

http://www.searchareply.com/backend-testing-process/ 1/20

SEARCH... Search

Search A Reply

NavigationTechnologySoftwareSocial MediaContact U s

TechnologySoftware Social MediaContact Us

Backend Testing ProcessBy Lucy | on Mar 7, 2013 | 0 CommentSoftware

Search for:

Search

Who s Online

5 visitors online now3 guests, 2 bots, 0 members
http://www.searchareply.com/category/social-media/http://www.searchareply.com/category/software/http://www.searchareply.com/category/technology/http://www.searchareply.com/category/software/http://www.searchareply.com/author/menaka/http://www.searchareply.com/contact-us/http://www.searchareply.com/category/social-media/http://www.searchareply.com/category/software/http://www.searchareply.com/category/technology/http://www.searchareply.com/contact-us/http://www.searchareply.com/category/social-media/http://www.searchareply.com/category/software/http://www.searchareply.com/category/technology/http://www.searchareply.com/http://pinterest.com/searchareply/http://www.twitter.com/searchareplyhttp://www.facebook.com/searchareply


2/20



Why back end testing is so important?

A back end is the engine of any client/server system. If the backend malfunctions, it may cause system deadlock, datacorruption, data loss and bad performance. Many front ends logon to a single SQL server. A bug in a back end may putserious impact on the whole system. Too many bugs in a backend will cost tremendous resources to find and fix bugs anddelay the system developments.

It is very likely that many tests in a front end only hit a smallportion of a back end. Many bugs in a back end cannot beeasily discovered without direct testing.

Back end testing has several advantages: The back end is nolonger a black box to testers. We have full control of testcoverage and depth. Many bugs can be effectively found andfixed in the early development stage. Take Forecast LRS as an

example; the number of bugs in a back end was more than 30%of total number of bugs in the project. When back end bugs arefixed, the system quality is dramatically increased.

What are Differences between back end testing and front endtesting

It is not easier to understand and verify a back end than a frontend because a front end usually has friendly and intuitive userinterfaces.

A back end has its own objects, such as, tables, storedprocedures and triggers. Data integrity and protection is critical.Performance and multi-user support are big issues. Slowness inoperation can be vital to the projects future.

There are no sufficient tools for back end testing. SQL languageis mainly a testing tool. MS Access and MS Excel can be used toverify data but they are not perfect for testing. However, thereare a large number of test tools available for front end testing.

To be able to do back end testing, a tester must have strong
http://www.searchareply.com/tag/sql/http://www.searchareply.com/wp-content/uploads/2013/03/SoftwareTestingWordle02.png


3/20



background in SQL server and SQL language. It is relativelydifficult to find testers who understand both SQL server and SQLtesting. This causes a shortage of back end testers.

What are Back end testing phases?

There are several phases in back end testing. The first step is toacquire design specifications for an SQL server. The second stepis test specification design. The next step is to implement thetests in this design with SQL code. The test specification designshould contain information concerning component testing(individual pieces of the system), regression testing (previouslyknown bugs), integration testing (several pieces of the systemput together), and then the entire system (which will includeboth front and back ends).

Component testing will be done early in the development cycle.Integration and system tests (including interfaces to front ends

and nightly processes) are performed after the component testspass. Regression testing will be performed continuouslythroughout the project until it is finished. The back end usuallydoes not have an independent beta test, as it only exercised bythe front end during the beta test period. The last step is todeliver users a quality product.

What is Back end testing methodology?

Back end test methodology has many things in common withfront end testing and API testing. Many test methods can beused for back end testing. Structural testing and functionaltesting are more effective approaches in back end testing. Theyare overlapped in some test cases. However, the two methodsmay discover different bugs. We strongly recommend testers todo both types of testing. There are many other test methodsthat can be applied to back end testing. We list a few below. Forother test methods, please check other test design references.

A back end can be broken down into a finite number of testablepieces based on a back ends structure. Tests will verify each

and every object in a type of structure.Functional testing:A back end can be broken down into a finite number of testablepieces based on applications functionality. The test focus is onfunctionality of input and output but not on the implementationand structure. Different projects may have different ways tobreak down.

Boundary testing:Many columns have boundary conditions. For example, in acolumn for percentages, the value cannot be less than zero and


4/20



cannot be greater than 100%. We should find out these types of boundary conditions and test them.

Stress testing:It involves subjecting a database to heavy loads. Forincidence, many users heavily access the same table that has alarge number of records. To simulate this situation, we need tostart as many machines as possible and run the tests over andover.

STRUCTURAL BACK END TESTS:

Although not all databases are the same, there are a set of testareas that will be covered in all test specifications.

Based on structure, a SQL database can be divided into threecategories: database schema, stored procedures, and triggers.Schema includes database design, tables, table columns,column types, keys, indices, defaults, and rules. Stored

procedures are constructed on the top of a SQL database. Thefront end talks to APIs in DLL. The A PIs communicate a SQLdatabase through those stored procedures. Triggers are a kindof stored procedures. They are the last line of defense toprotect data when data is about to be inserted, updated ordeleted.

Database schema testing:

Test Coverage Criterion: EACH AND EVERY ITEM IN SCHEMAMUST BE TESTED AT LEAST ONCE

Databases and devices:

Verify the following things and find out the differences betweenspecification and actual databases

Database namesData device, log device and dump deviceEnough space allocated for each databaseDatabase option setting (i.e. trunc. option)

Tables, columns, column types, defaults, and rules

Verify the following things and find out the differences betweenspecification and actual tables

All table namesColumn names for each tableColumn types for each table (int, tinyint, varchar, char,text, datetime. specially the number of characters for charand varchar)Whether a column allows NULL or not

Tweet

0

0

0

Like
http://www.printfriendly.com/print?url=http%3A%2F%2Fwww.searchareply.com%2Fbackend-testing-process%2Fmailto:?to=&subject=Backend+Testing+Process&body=%26nbsp%3B%0D%0A%0D%0AWhy+back+end+testing+is+so+important%3F%0D%0A%0D%0AA+back+end+is+the+engine+of+any+client%2Fserver+system.+If+the+back+end+malfunctions%2C+it+may+cause+system+deadlock%2C+data+corruption%2C+data+loss+and+bad+performance.+Many+front+ends+log+on+to+a+singl%20-%20http://www.searchareply.com/backend-testing-process/http://twitter.com/search?q=http%3A%2F%2Fwww.searchareply.com%2Fbackend-testing-process%2Fhttps://twitter.com/intent/tweet?original_referer=http%3A%2F%2Fwww.searchareply.com%2Fbackend-testing-process%2F&text=Backend%20Testing%20Process%20-%20&tw_p=tweetbutton&url=http%3A%2F%2Fwww.searchareply.com%2Fbackend-testing-process%2Fhttp://www.searchareply.com/tag/database/


5/20



Default definitionsWhether a default is bound to correct table columnsRule definitionsWhether a rule is bound to correct table columnsWhether access privileges are granted to correct groups

Keys and indexes, Verify the following things and compare themwith design specification

Primary key for each table (every table should have aprimary key)Foreign keysColumn data types between a foreign key column and acolumn in other tableIndices, clustered or nonclustered; unique or not unique

Stored procedure testsTest Coverage Criterion: EACH AND EVERY ST

Verify the following things and compare them with designspecification

Whether a stored procedure is installed in a databaseStored procedure nameParameter names, parameter types and the number of parameters

Outputs:When output is zero (zero row affected)When some records are extractedOutput contains many recordsWhat a stored procedure is supposed to doWhat a stored procedure is not supposed to doWrite simple queries to see if a stored procedurepopulates right data

Parameters:

Check parameters if they are required.Call stored procedures with valid dataCall procedures with boundary dataMake each parameter invalid a time and run a procedure

Return values:

Whether a stored procedure returns valuesWhen a failure occurs, nonzero must be returned.

Error messages:


6/20



Make stored procedure fail and cause every errormessage to occur at least onceFind out any exception that doesnt have a predefinederror message

Others:

Whether a stored procedure grants correct accessprivilege to a group/userSee if a stored procedure hits any trigger error, indexerror, and rule errorLook into a procedure code and make sure majorbranches are test covered.

Integration tests of procedures

Group related stored procedures together. Call them inparticular order

If there are many sequences to call a group ofprocedures, find out equivalent classes and run tests tocover every class.Make invalid calling sequence and run a group of storedprocedures.Design several test sequences in which end users arelikely to do business and do stress tests

Trigger tests:

Test Coverage Criterion: EACH AND EVERY TRIGGER AND TRIGGER ERROR MUST BE TESTED AT LEAST ONCE

Updating triggers:


Make sure trigger name spelling is correctSee if a trigger is generated for a specific table columnTriggers update validationUpdate a record with a valid dataUpdate a record, a trigger prevents, with invalid data andcover every trigger errorUpdate a record when it is still referenced by a row inother tableMake sure rolling back transactions when a failure occursFind out any case in which a trigger is not supposed to rollback transactions

Inserting triggers


7/20




Make sure trigger name spellingSee if a trigger is generated for a specific table columnTriggers insertion validationInsert a record with a valid dataInsert a record, a trigger prevents, with invalid data andcover every trigger errorTry to insert a record that already exists in a tableMake sure rolling back transactions when an insertionfailure occursFind out any case in which a trigger should roll backtransactionsFind out any failure in which a trigger should not roll backtransactionsConflicts between a trigger and a stored procedure/rules(i.e. a column allows NULL while a trigger doesnt)

Deleting triggers:


Make sure trigger name spellingSee if a trigger is generated for a specific table columnTriggers deletion validationDelete a record Delete a record when it is still referenced by a row inother tableEvery trigger errorTry to delete a record that does not exists in a tableMake sure rolling back transactions when a deletion failsFind out any case in which a trigger should roll backtransactionsFind out any failure in which a trigger should not roll backtransactionsConflicts between a trigger and a stored procedure/rules(i.e. a column allows NULL while a trigger doesnt)

Integration tests of SQL server

Integration tests should be performed after the abovecomponent testing is done. It should call stored proceduresintensively to select, update, insert and delete records indifferent tables and different sequences.

The main purpose is to see any conflicts and incompatibility.

Conflicts between schema and triggersConflicts between stored procedures and schema


8/20



Conflicts between stored procedures and triggers

Server setup scripts

Two cases must be tests: One is to set up databases fromscratch and the other to set up databases when they alreadyexist.

Below is the minimum list of areas:

Is a setup batch job available to run without muchoperators assistance (It is not acceptable if it requires anoperator to run many batch jobs manually)Work environment the setup needs to run (DOS, NT)Environment variables (i.e. is %svr% defined?)Time it takes to set upSet up databases from scratch.Set up from existing databases

Set up log and failure messagesAfter setup, check for Databases

Stored procedures Look up data User access privileges

FUNCTIONAL BACK END TESTS:

Functional tests more focus on functionality and features of aback end. Test cases can be different from project to project.But many projects have things in common. The followingsection discusses the common areas. We encourage testers to

add project-specific test cases in the functional test design.It is not a good idea to test a server database as a single entityat initial stage. We have to divide it into functional modules. If we cannot do the partition, either we do not know that projectdeep enough or the design is not modulized well. How to dividea server database is largely dependent on features of aparticular project.

METHOD 1: We may ask ourselves what the features of aproject are. For each major feature, pick up portion of schema,triggers and stored procedures that implement the function andmake them into a functional group. Each group can be testedtogether. For example, the Forecast LRS project had fourservices: forecast, product lite, reporting, and system. This wasthe key for functional partitioning:

METHOD 2: If the border of functional groups in a back end isnot obvious, we may watch data flow and see where we cancheck the data: Start from the front end. When a service has arequest or saves data, some stored procedures will get called.The procedures will update some tables. Those storedprocedures will be the place to start testing and those tables


9/20


10/20



Login and user security:

The following things need to be checked:

Email validationSQL user login (user id, password, host name)NT server loginDatabase access privilege (the sysusers table)Database security hierarchyTable access privilege (if select is allowed.)Table data access controlTraining account (maybe no password is required)

There are more test cases here:

Simulate front end login procedure and check if a userwith correct login information can loginSimulate front end login procedure and check if a userwith incorrect login information fail to loginCheck concurrent logins (make many users login at the

same time.)Try to login when a time-consuming query is running tosee how long login will take to succeedCheck for any security-restrict functions and see they areworking properlySee any data view restriction in place, such as, a user cansee his data and the data of people who report to him.

Stress Testing:

We should do stress tests on major functionality. Get a list of major back end functions/features for a project. Find outcorresponding stored procedures and do the following things:

Test Coverage Criterion: EACH AND EVERY MAJORFUNCTION OR FEATURE MUST BE INCLUDED IN STRESS TESTING

Write test scripts to try those functions in random orderbut every function must be addressed at least once in afull cycle.

Run test scripts over and over for a reasonable periodMake sure log execution results and errors.Analyze log files and look for any deadlock, failure out of memory, data corruption, or nothing changed.

Test a back end via a front end:

Sometimes back end bugs can be found by front end testing,specially data problem.


11/20



The following are minimum test cases:

Make queries from a front end and issue the searches (Ithits SELECT statements or query procedures in a backend)Pick up an existing record, change values in some fieldsand save the record. (It involves UPDATE statement orupdate stored procedures, update triggers.)Push FILE NEW menu item or the NEW button in a frontend window. Fill in information and save the record. (Itinvolves INSERT statements or insertion storedprocedures, deletion triggers.)Pick up an existing record, click on the DELETE or REMOVEbutton, and confirm the deletion. (It involves DELETEstatement or deletion stored procedures, deletiontriggers.)Repeat the first three test cases with invalid data and seehow the back end handles them.

Benchmark testing:

Test Coverage Criterion: EACH AND EVERY FUNCTION OR FEATURE MUST BE INCLUDED IN BENCHMARK TESTING

When a system does not have data problems or user interfacebugs, system performance will get much attention. The badsystem performance can be found in benchmark testing.

Four issues must be included:

System level performanceMajor functionality (Pick up most-likely-usedfunctions/features)Timing and statistics (Minimal time, maximal time andaverage time)Access volume (A large number of machines and sessionsmust be involved.)

DAILY DOWNLOADING ANDDISTRIBUTION:

This part is usually developed by an operation team. It did notget enough attention a long time ago. However, after wedeliver a product, end users must live with nightly processevery daily. Bugs in nightly job put serious impact on usersdaily work. Loss or corruption of customer data can be severe.We strongly recommend testers to intensively test nightlydownloading and distribution, particularly error detection andreporting.


12/20



Batch jobs:

By batch job, We mean batch jobs for Windows NT, DOS orOS/2. (The SQL scripts that are called by a batch job will bediscussed in next three sections. )

Test Coverage Criterion: EACH AND EVERY BATCH JOB MUST BE TESTED AT LEAST ONCE

Here are the minimum list of test cases:

File transfer batch job:

Destination path and source pathAll variables in a batch job must be resolved (i.e. if %log%is used, the log must be defined somewhere either inthe same file or in other system setup utility.)Make sure source files and their names are correct asspecified.Make sure destination files and their names are correct

as specified.Verify if any error level is checked after each file copy.Error messages must be logged. Fatal errors must be sentto operators or testers.Verify the database has the bulk copy option set to truebefore a batch job is executedGet estimate of total batch execution time. Make sure itfits the time window (specially the worst case)

BCP batch job:

Make sure dbnmpipe.exe is automatically loaded andbcp.exe/isql.exe are on the system pathCheck for pass-in parameters %1, %2, to a batch jobMake sure a table truncation script must be run beforebcp in to those tablesMake sure database name, bcp in file name/bcp out filename, and options /S, /U, /P, /c and /bVerify if any error level is checked after each bcpcommand.Failure should be logged. Fatal failure should be sent tooperators or testers immediately

Batch file jobs that launch SQL scripts:Make sure dbnmpipe.exe is automatically loaded andisql.exe are on the system pathCheck for pass-in parameters %1, %2, to a batch jobMake sure all required SQL files and their names, options/S, /U, /PVerify if any error level is checked after each launchingFailure should be logged. Fatal failure should be sent tooperators or testers immediately


13/20



Data downloading:

In most cases, downloading is not just bcp in to a database.Data format change and calculations may happen.

Test Coverage Criterion: EACH AND EVERY SCRIPT MUST BE TESTED AT LEAST ONCE

We have to check the following areas:

Network connection status. Failure handling.Input data must be validated before a batch jobinserts/updates a database (Invalid data must be filteredout, i.e. NULLs in critical fields, negative values, too bignumbers)Input data populated to right tablesCalculations must follow business rulesCheck if data is really changed after data downloadingSee if two columns of data are mistakenly exchanged (i.e.product_id data and productgroup_id data are reversed

when inserted)Check if any data is unexpectedly changed or deletedSee what happens if database objects do not exist whendownloading starts

Data conversion:

The goals of many ITG projects are moving end users fromexisting VAX systems into PC platform systems. One of important steps is to convert old data into new systems. Dataconversion is required.

Test Coverage Criterion: EACH AND EVERY SCRIPT MUST BE TESTED AT LEAST ONCE

We list several checking items here:

For each script, check for syntax error (Running a script isan easiest way to find out)For each script, check for table mapping, columnmapping, and data type mappingVerify lookup data mappingRun each script when records do not exist in destinationtablesRun each script when records already exist in destinationtablesMake sure the execution sequence of scripts is correct(i.e. Look up data must be converted first beforeconversions)Look for any scripts that encounter index error or triggererrors (i.e. error attempt to insert unique index row.)Make sure a major transaction statement is followed byerror checking if @@error != 0


14/20



Look for any script that causes error out of memory at runtimeCheck for any scripts that take too long to run forreasonable size of records. If it is the case, suggestdevelopers to optimize scripts.Make sure begin tran and commit tran are in scriptsIf a failure occurs, transactions in a block after begintran should be rolled back

Data distribution:

There are two kinds of data distribution: One kind is to sendreplicated data to other SQL servers across LAN and WAN andkeep them in sync. The other distribution is to pass informationto other kinds of systems. Header information and data needconverting. For example, KBATS article editing system nightlysends articles to Knowledge base server and to external systemlike CompuServe. Here is a minimum checking list:

Test Coverage Criterion: EACH AND EVERY FEATURE MUST BE TESTED AT LEAST ONCE

For data replication:

Make sure every job extracts right updates from a SQLserverLook for any new records that are missing in distributiondata setMake sure data overwriting works correctMake sure sequences of data updates in destinationserversRun distribution utility when new updates need to bedistributedRun distribution utility when many changes are madeVerify data loss handling mechanism for LAN or WANenvironmentVerify distribution mechanism when a network is downVerify error handling when a destination server is downVerify error handling when a source server is downCheck if failures can be automatically recovered or canbe recovered from next run

For data conversion distribution:

Make sure every job extracts right data from a SQL serverLook for any new records that are missing in distributiondata setMake sure table mapping, column mapping, data typemapping, file format changes, and header changesMake sure data is converted to fit other systemsMake sure data overwriting works correctMake sure sequences of data updates in destination


15/20



serversRun distribution utility when new updates need to bedistributedRun distribution utility when many changes are madeVerify data loss handling mechanism in LAN or WANVerify distribution mechanism when a network is downVerify error handling when a destination server is downVerify error handling when a source server is downCheck if failures can be automatically recovered or canbe recovered from next run

INTERFACES TO TRANSACTION APIS:

By Transaction API, we mean those APIs that are speciallydesigned for our projects to handle communications between afront end and a back end. Those APIs are not part of SQLDBLIB or ODBC. Although they do not belong to a back end, we

have to test their interfaces to back end.Connections to a SQL server database:

Make sure transaction APIs can open connections to aSQL serverVerify APIs are able to send queries to a SQL server andretrieve dataUnplug net cable and see if APIs can detect itStop a SQL server and call APIs to make connectionStop a SQL server in the middle of transaction

Send queries to a back end:

Call each API that sends queries to a back endMake sure A PIs call right stored proceduresVerify parameters in stored procedure callsMake sure APIs should call stored procedures to access aSQL server. It is not recommended to send a simplequery like SELECT FROM WHERE

Receive output from a back end:

For every API, try a query with no row returnedFor every API, try more than one row returnedFor major API, try to have many rows returnedDisconnect in the middle of transactions and check errordetectionMake sure an API always checks the return value of astored procedureWhen a failure occurs, an API should receives value


16/20



nonzero

OTHER TEST ISSUES:

Test tips:

No program is bug free. If you have been doing tests forseveral days and do not find any bugs, our test methodsor test data might be wrong. You should at least havesome suggestions for developers.The Break-Program attitude is highly recommended. Ifyou dont break it now, end users will break it later.There are a huge number of test cases. Always askyourselves if any test case is missing and if our testspecifications are complete.When you design test specification, think about validcases, invalid cases and boundary cases

Effective test methodology is neither unique nor universal.Feel free to discuss the test plan, test specifications andtest data with other testers.When testing, you should pretend to be different levels ofusers. As power users, you can test advanced featuresheavily. As novices, you can do stupid things, i.e. turn offthe machine in the middle of a transaction.If you suspect any result or message, go ahead and trackit down. You may have found a big bug.Before you log a bug into Raid, find out the minimal stepsto reproduce it. If you can not reproduce a bug, make anote and try it next time.If a developer resolves a major bug as By-Design, butyou think it is crucial to fix, try to convince the developerand your test lead.If you can track a bug down to a code level, do it. You willlearn something new from bug trackingIf a test is likely to be repeated later, automate it.A good programmer may not be a good tester. Be proudof your ability to find bugs.You are an important part of product development. Youhelp to ensure the high quality of ITG products.

Test tools:

As mentioned earlier in this document, there are not manygood tools for back end testing. But some utilities can be used.

SQL language:

Write test scripts to call stored procedures, retrieve data,insert/update/delete records. Most back end test work can bedone with the SQL language


17/20



NT SQL utilities:

DOS utilities like isql.exe, bcp.exe

Windows applications such as WinQuery, ISQL/w, SQLAdministration, SQL Object Manager, SQL Client ConfigurationUtility

MSAccess:

We may take advantage of MSAccesss tables, queries, forms,reports, macros and modules.

Excel:

MSQuery and Q+E are useful for data validation

Our own test tools:

Several test tools have been developed. For example, storedprocedures to log passed/failed for each test and to present teststatistics. Contact MinF for those tools.

Useful queries:

To facilitate testing, we post some useful queries here. Theyare just something good to start with.

Check for data devices and log devices:sp_helpdb

Check for space used:sp_spaceused

Get information about an object in a database:sp_help where can be atable name, trigger name, stored procedure name and soon.

Get trigger code, procedure code, or view code, do:sp_helptext

Find out who is on system, whose host name and otherinformation:sp_who @companynameend

Share this story:

Tweet 0

0Like

0

Tags: BackendBackend testingDatabaseDatabase testingFrontend testingFrontendOracleSQL

Recent Posts Related Posts
http://www.searchareply.com/how-to-take-backup-of-my-word-press-database/http://www.searchareply.com/youtube-to-bring-in-offline-video-viewing-feature/http://pinterest.com/pin/create/button/http://www.searchareply.com/tag/sql/http://www.searchareply.com/tag/oracle/http://www.searchareply.com/tag/frontend/http://www.searchareply.com/tag/front-end-testing/http://www.searchareply.com/tag/database-testing/http://www.searchareply.com/tag/database/http://www.searchareply.com/tag/backend-testing/http://www.searchareply.com/tag/backend/http://twitter.com/search?q=http%3A%2F%2Fwww.searchareply.com%2Fbackend-testing-process%2Fhttps://twitter.com/intent/tweet?original_referer=http%3A%2F%2Fwww.searchareply.com%2Fbackend-testing-process%2F&text=Backend%20Testing%20Process&tw_p=tweetbutton&url=http%3A%2F%2Fwww.searchareply.com%2Fbackend-testing-process%2F


19/20



Author Description

No Responses to Backend Testing Process

Leave a Reply

Your email address will not be published. Required fields aremarked *

Name *

Email *

Website

Youtube to bring inoffline videoviewing feature

Oct 3, 2013 - 0Comment

An app toremember yourdreams


Soon Mobiles willPredicts theEarthquakes


How to take Backupof my word pressdatabase

Mar 22, 2013 - 0Comment

Oracle BasicsTutorial


SQL Server Tutorial

http://www.searchareply.com/sql-server-tutorial/http://www.searchareply.com/sql-server-tutorial/http://www.searchareply.com/oracle-basics-tutorial/http://www.searchareply.com/oracle-basics-tutorial/http://www.searchareply.com/how-to-take-backup-of-my-word-press-database/http://www.searchareply.com/soon-mobiles-will-predicts-the-earthquakes/http://www.searchareply.com/soon-mobiles-will-predicts-the-earthquakes/http://www.searchareply.com/an-app-to-remember-your-dreams/http://www.searchareply.com/an-app-to-remember-your-dreams/http://www.searchareply.com/youtube-to-bring-in-offline-video-viewing-feature/


20/20


HomeContact UsHomepage

2013. All Rights Reserved. Search A Reply

Comment

Post Comment

Notify me of follow-up comments by email.

Notify me of new posts by email.
http://www.searchareply.com/homepage/http://www.searchareply.com/contact-us/http://www.searchareply.com/

Documents

Backend Testing Process _ Search a Reply