Pages

Friday, August 22, 2014

CRM Application Testing Help


CRM Application Testing Help
Customer Relationship Management (CRM) systems are at the core of most customer-oriented business. A buggy or improperly implemented feature in your CRM application can have direct impact on how you understand your customers and hurt your revenue. Conversely, a well-implemented CRM can help you gain customer insight and improve customer satisfaction and loyalty.
CRMs also contain a lot of sensitive data about your company and your customers. Any CRM testing program should ensure that the data is accurate and secure during storage and retrieval.
1. Data Quality and Conversion:
The first test cycle focuses on issues related to data quality and conversion. At every step of a migration or update you should be verifying that the CRM is working as expecte3d both with and without data.
Look in particular for the following issues and data quality scenarios:
a)      Duplication of data: No redundancy is allowed.
b)      Wrong fields populated: Transaction details for one card type should not appear under the transaction history of another card. Loyalty card transactions appearing as gift card transactions.
c)      Hidden data is indeed hidden: Only the appropriate data should be visible to various user roles.
d)     Data maps correctly: Grid issues where a selected row’s data goes out of alignment with the fields as you scroll down are very common.
e)      New and updated data saves properly: Customer information and card information should save and update properly.
f)       Partial and full search work as desired: Users should be able to search by first name, last name, company, card and whatever else is deemed necessary.
g)      No data is missing: All of the required data should be available to the right user levels.
h)      Graphs represent data correctly: Critical data like store-specific and program-specific filters and sales percentages should be accurate.
i)        Data sorting: All of the fields that need to be sortable should works as desired.
j)        CRM installs correctly: No critical GUI issues should arise during installation even when the user misses data during installation.
k)      Updating data is smooth and doesn’t require you to move to another form: Information such as customer visit count should update automatically without visiting additional forms.
l)        Data saved in one field does not move to another field after saving it: Fields like address, which may need more than one field, should save to the correct fields.
m)    Check that data which is not supposed to be editable is indeed not editable: Data like date and time of transaction should not be editable.
2. Functionality:
The second cycle of testing focuses on testing the functional aspects of the system. Regression testing of data quality and conversion should also be done.
Here are a few typical functional areas and related scenarios of a CRM application that should be checked:
a)      Access level: User permissions are working as desired. In particular, non-admin users should not have access to any admin functions.
b)      Transaction upload: If the CRM integrates with a POS, then all of the customer’s transaction information should accurately update at the Point of Sale (POS) within a few seconds.
c)      Insufficient card balance: If the customer does not have sufficient balance in the card for complete order payment, then he should be able to pre-authorize for the amount equal to balance available on the account and select another payment for the remaining balance of the purchase.
d)     Connection lost: For an Enterprise-grade CRM application, when the connection between stores gets lost then cards should not work and the proper error message appears.
e)      Card information: A customer’s card number or card type should not be changeable after the transaction has been completed.
f)       Card amount: Negative balances never appear through direct or indirect methods.
g)      Partial search: Partial search for program numbers that can both act as loyalty cards and gift cards should return matches from both types of cards.
h)      Transaction type: Users should be able to change the transaction type before settling the transaction and transactions should settle properly after the change.
i)        Data mismatch: Customers with the same first and last name should not trigger data mismatches and other problems.
j)        Pre-authorization: When a transaction fails while a card is pre-authorized, the payment slip should not print incorrectly.
k)      Department-specific transactions: Any restrictions on which departments accept gift and loyalty cards are working as desired.
l)        Store-specific sales: Receipts are printing the correct store name and address.
m)    Tax: All tax-related scenarios should work fine while pre-authorizing and settling transactions including cancelling transactions.
3. Reporting and Integration:
The third testing cycle focuses on reporting and integration, passing data to or from external systems, with a regression testing done for data quality and functionality.
Testing CRM reports should cover the following areas and scenarios:
a)      Accuracy and reliability: The accuracy of reliability of data and reports from the new CRM solution need to be checked to determine whether they match existing reports and how many, if any, reports must be revised.
b)      Exporting reports: Do these reports export in all formats with the correct data.
c)      AND/OR filter: Check that AND/OR filters work properly even with lots of filters chained together.
d)     No input value: Check that fields with no input value are not getting past filters incorrectly.
e)      Labels match: Label names should be the same regardless of where they appear.
f)       Unnecessary dependencies: Generating a report at one store should not be dependent on any actions at other stores.
g)      Store filters: The correct data appears when store-specific filters are applied.
h)      Date/time: Reports should include the correct date and time of creation.
i)        Headings and build versions: Reports should show the correct headings and build versions.
j)        Report performance: Data should populate the report in a timely manner.
k)      Date ranges: Filtering on date ranges should always be tested.
4. Regression and User Acceptance Testing:
All of the end-to-end business processes are validated by the customer through user acceptance testing. User acceptance testing is process-level testing. All of the testing that has been done to this point is module-level testing.
User acceptance testing should cover the following areas:
a)      Documentation: We refer to project documentation to write the test cases based on the requirements of the users of the application.If the original documentation is incorrect or the end-users have undocumented needs, then the documentation needs to be updated as per the actual customer’s requirement.
b)      Usability: In CRM applications, customization to things like the grid, forms, schema and templates affects the usability. Unless test confirms the implementation is acceptably easy to use, the application should not be released.
c)      Functional Correctness and Completeness: All features should be implemented correctly.
d)     Reliability: The CRM should meet or exceed service level uptime requirements and the end-users should not have to wait a long time for transactions to  upload and data should be available all the time.
e)      Confidentiality: Customer’s details (contacts, points, balance visits etc) should be kept confidential.
f)       Scalability: Test the application for a realistic number of stores connected to a head office.
g)      Stress: The following check points should be monitored for response time  with an increasing number of open (not settled) orders:
i)        Sending order to requisition (kitchen)
ii)      Customer search (especially company search), and saving of the customer (on confirmation of customer info).
iii)    Payment processing on order settlement.
    Begin stress testing by having 10 open checks and then settling them at the same time. Then increase the number to 20 open checks, then 50, 100, 300, and 600.
Finally, check that the CRM application is well integrated with the customer’s other applications or systems such as Outlook, Map Point and Squirrel Explorer.
5. Not-so-final regression test
Once all of the critical defects have been fixed run another round of regression tests on all of the above.
Any time requirements change (a common occurrence in CRM implementations), new features are added or defects are fixed, you should run these regression tests again.

Constraints and types of constraints in sql server

What is Constraint in SQL - Server ?
Ans:->  Constraint are using to restricted the insertion of unwanted data in any columns. we can create constraints on single or multiple columns of any table. It maintain the data integrity of  the table.

There are 6 types of constraints in Sql Server:-


    Primary key constraint.
    Foreign Key constraint.
    Unique Key constraint.
    Not Null constraint.
    Check constraint
    Default constraint

Description of  above constraints:-

1. Primary Key :- Primary Key of a relational table uniquely identifies each record in the table. It can be either be a normal attribute that is guaranteed to be unique such as in a school name should be same of any student but roll number never be same of any student in a school.

Creating primary key at the time of table creation.

CREATE TABLE EMP
(
EMPNUMBER INT PRIMARY KEY,
ENAME VARCHAR(30),
DOB DATETIME,
HIREDATE DATETIME,
SAL NUMERIC(13,2),
MGR INT,
DEPTNO INT
)

CREATE TABLE DEPT
(
DEPTNO INT PRIMARY KEY,
DNAME VARCHAR(30),
)

Adding primary key after creating of table.

when we adding primary key in any table before adding primary key we have to create that column is not null if the column is not null then we have to create not null constraint on the column after that we will create primary key constraint on that table.

Syntax:-

ALTER TABLE ALTER COLUMN NOT NULL

ALTER TABLE  ADD CONSTRAINT   PRIMARY KEY (COLUMN_NAME)

Eg:-

ALTER TABLE EMP ALTER COLUMN EMPNUMBER INT NOT NULL
ALTER TABLE EMP ADD CONSTRAINT PK_EMP PRIMARY KEY(EMPNUMBER)

2. Foreign Key:- One of the most important concept in database is creating relationships between  database tables. these relationships provide a mechanism for linking data stored in multiple tables and retriving it in an efficient manner. in order to create a link between two tables we must specify a foreign key in one table that references a column in another table.

foreign key creating at the time of table creation:-
CREATE TABLE EMP
(
EMPNUMBER INT PRIMARY KEY,
ENAME VARCHAR(30),
DOB DATETIME,
HIREDATE DATETIME,
SAL NUMERIC(13,2),
MGR INT,
DEPTNO INT FOREIGN KEY REFERENCES DEPT(DEPTNO)
)

Another way to creating foreign key after creation of table

Syntax:-     
ALTER TABLE ADD CONSTRAINT FOREIGN KEY (COLUMN_NAME)REFERENCES ()
ALTER TABLE EMP ADD CONSTRAINT FK_EMP FOREIGN KEY (DEPTNO) REFERENCES DEPT(DEPTNO)

3. Unique Key:-  Unique key constraint is use to make sure that there is no duplicate value in that column. Both unique key and primary key both enforces the uniqueness of column but there is one difference between them unique key constraint allow one null value but primary key does not null value.In a table we create one primary key but we can create more than one unique key in Sql Server.

Syntax to add unique key:-

ALTER TABLE ADD CONSTRAINT UNIQUE ()

EXAMPLE:-
ALTER TABLE EMP ADD CONSTRAINT UK_EMP UNIQUE(EMAIL,MOBILENO)

4. Not null constraint:- Not null constraint is used to restricted the insertion of null value at that column. Not null constraint is using for that column which is not ignorable.

Syntax to adding Not Null Constraint:-
ALTER TABLE ALTER COLUMN (DATA TYPE) NOT NULL

EXAMPLE:-

ALTER TABLE EMP ALTER COLUMN EMAIL VARCHAR(50) NOT NULL

5. Check Constraint :-  This constraint is using to check value at the time of insertion like as salary of any employee is always greater than zero. so we can create a check constraint on employee table which is greater than zero.

Syntax:-
ALTER TABLE ADD CONSTRAINT CHECK (COLUMN_NAME WITH CONDITION)

EXAMPLE:-
ALTER TABLE EMP ADD CONSTRAINT CK_GREATER_THAN_ZERO CHECK (SAL>0)

6. Default Constraint:- The Default constraint is using to set a specific value of column if we not passing the value at the time of insertion.Through this constraint we set the default value of column.

Syntax:-
ALTER TABLE ADD CONSTRAINT FOR (COLUMN NAME)
Eg:-
ALTER TABLE EMP ADD CONSTRAINT DF_SAL DEFAULT 5000 FOR SAL

Use of above all constraint at the time of creating table:-
CREATE TABLE EMP123(
EMPNUMBER INT PRIMARY KEY,
ENAME VARCHAR(30) DEFAULT 'NOT KNOWN',
DOB DATETIME NOT NULL,
HIREDATE DATETIME,
EMAIL VARCHAR(50) UNIQUE ,
MOBILE VARCHAR(10) UNIQUE,
SAL NUMERIC(13,2) CHECK (SAL>0)
,MGR INT FOREIGN KEY REFERENCES EMP(EMPNUMBER),
DEPTNO INT FOREIGN KEY REFERENCES DEPT(DEPTNO)
)

For removing the constraint :-
ALTER TABLE DROP CONSTRAINT
ALTER TABLE EMP DROP CONSTRAINT DF_SAL DEFAULT

Thursday, February 27, 2014

Web application Cookies Testing


Website Cookies Basic Test Cases
Check to see what happens if a user deletes cookies while in site
Check to see what happens if a user deletes cookies after visiting a site
Check to see what happens if a user disabling cookies
if user has set browser options to warn before writing any cookie or
disabled the cookies completely then site containing cookie will be completely disabled and cannot perform any operation resulting in loss of site traffic.
Session cookies: This cookie is active till the browser that invoked the cookie is open. When we close the browser this session cookie gets deleted. Sometime session of say 20 minutes can be set to expire the cookie.
Persistent cookies: The cookies that are written permanently on user machine and lasts for months or years.
Password cracking:
If username or password is stored in cookies without encrypting
Cross Site Scripting (XSS
attacker can use scripts like JavaScript to steal user cookies and information stored in the cookies
Where cookies are stored?
When any web page application writes cookie it get saved in a text file on user hard disk drive.
The path where the cookies get stored depends on the browser. Different browsers store cookie in different paths. E.g. Internet explorer store cookies on path “C:\Documents and Settings\Default User\Cookies”
Here the “Default User” can be replaced by the current user you logged in as. Like “Administrator”, or user name like “Vijay” etc.
The cookie path can be easily found by navigating through the browser options. In Mozilla Firefox browser you can even see the cookies in browser options itself. Open the Mozila browser, click on Tools->Options->Privacy and then “Show cookies” button.
How cookies are stored?
Let’s take example of cookie written by rediff.com on Mozilla Firefox browser:
On Mozilla Firefox browser when you open the page rediff.com or login to your rediffmail account, a cookie will get written on your Hard disk. To view this cookie simply click on “Show cookies” button mentioned on above path. Click on Rediff.com site under this cookie list. You can see different cookies written by rediff domain with different names.
Site: Rediff.com Cookie name: RMID
Name: RMID (Name of the cookie)
Content: 1d11c8ec44bf49e0… (Encrypted content)
Domain: .rediff.com
Path: / (Any path after the domain name)
Send For: Any type of connection
Expires: Thursday, December 31, 2020 11:59:59 PM
General Test cases: 
As a Cookie privacy policy make sure from your design documents that no personal or sensitive data is stored in the cookie.
If you have no option than saving sensitive data in cookie make sure data stored in cookie is stored in encrypted format.
Make sure that there is no overuse of cookies on your site under test. Overuse of cookies will annoy users if browser is prompting for cookies more often and this could result in loss of site traffic and eventually loss of business.
Disable the cookies from your browser settings: If you are using cookies on your site, your sites major functionality will not work by disabling the cookies. Then try to access the web site under test. Navigate through the site. See if appropriate messages are displayed to user like “For smooth functioning of this site make sure that cookies are enabled on your browser”. There should not be any page crash due to disabling the cookies. (Please make sure that you close all browsers, delete all previously written cookies before performing this test)
Accepts/Reject some cookies: The best way to check web site functionality is, not to accept all cookies. If you are writing 10 cookies in your web application then randomly accept some cookies say accept 5 and reject 5 cookies. For executing this test case you can set browser options to prompt whenever cookie is being written to disk. On this prompt window you can either accept or reject cookie. Try to access major functionality of web site. See if pages are getting crashed or data is getting corrupted.
Delete cookie: Allow site to write the cookies and then close all browsers and manually delete all cookies for web site under test. Access the web pages and check the behaviour of the pages.
Corrupt the cookies: Corrupting cookie is easy. You know where cookies are stored. Manually edit the cookie in notepad and change the parameters to some vague values. Like alter the cookie content, Name of the cookie or expiry date of the cookie and see the site functionality. In some cases corrupted cookies allow to read the data inside it for any other domain. This should not happen in case of your web site cookies. Note that the cookies written by one domain say rediff.com can’t be accessed by other domain say yahoo.com unless and until the cookies are corrupted and someone trying to hack the cookie data.
Checking the deletion of cookies from your web application page: Sometimes cookie written by domain say rediff.com may be deleted by same domain but by different page under that domain. This is the general case if you are testing some ‘action tracking’ web portal. Action tracking or purchase tracking pixel is placed on the action web page and when any action or purchase occurs by user the cookie written on disk get deleted to avoid multiple action logging from same cookie. Check if reaching to your action or purchase page deletes the cookie properly and no more invalid actions or purchase get logged from same user
Cookie Testing on Multiple browsers: This is the important case to check if your web application page is writing the cookies properly on different browsers as intended and site works properly using these cookies. You can test your web application on Major used browsers like Internet explorer (Various versions), Mozilla Firefox, Netscape, Opera etc.
If your web application is using cookies to maintain the logging state of any user then log in to your web application using some username and password. In many cases you can see the logged in user ID parameter directly in browser address bar. Change this parameter to different value say if previous user ID is 100 then make it 101 and press enter. The proper access message should be displayed to user and user should not be able to see other users account.