Software Testing Practices, Test Methodologies and Test Competency Services


Welcome to the world of Software Testing & Best Test Practices.

All you wanted to know about Software Testing, Test Practices, Test Methodologies and building the Test Competency Services !!


Tuesday, February 21, 2012

Security Testing & Basics


When do we use Security Testing?
Security testing is carried out when some important information and assets managed by the software application are of significant importance to the organization. Failures in the software security system can be serious especially when not detected, thereby resulting in a loss or compromise of information without the knowledge of that loss.

The security testing should be performed both prior to the system going into the operation and after the system is put into operation.

Rigorous security testing activities are performed to demonstrate that the system meets the specified security requirements & identify the left out security vulnerabilities, if any.

The extent of testing largely depends upon the security risks, and the test engineers assigned to conduct the security testing are selected according to the estimated sophistication that might be used to penetrate the security.


What are the objectives of Security Testing?
Security defects do not come to surface that easily as other types of defects. Thus security testing is carried out to identify defects that are quite difficult to identify. The security testing is carried out to ensure that the software under test is sufficiently robust and functions in an acceptable manner even in the event of a malicious attack.

The objectives of security testing can be:

1) To ensure that adequate attention is provided to identify the security risks
2) To ensure that a realistic mechanism to define & enforce access to the system is in place
3) To ensure that sufficient expertise exists to perform adequate security testing
4) To conduct reasonable tests to confirm the proper functioning of the implemented security measures
Who should do the Security Testing?
Majority of the security testing techniques are manual, requiring an individual to initiate and conduct the test. Automation tools can be helpful in executing simple tasks, whereas complicated tasks continue to depend largely on the intelligentsia of the test engineer.

Irrespective of the type of testing, the testing engineers that plan and conduct security testing should have significant security and networking related knowledge, including expertise of following areas:

1) Network security
2) Firewalls
3) Intrusion detection system
4) Operating systems
5) Programming and networking protocols like TCP/IP


Security Testing versus Conventional Software Testing
– A Quick Comparison:

Security testing has following attributes:

# It emphasizes what an application should not do rather than what it should do.

# It sometimes tests conformance to positive requirements for instance - "User accounts getting disabled after five unsuccessful login attempts" etc.

# It is aimed to test the negative requirements stating something that should never occur. For example "An external attacker should not be able to modify the contents of the Web page" and "Unauthorized users should not be able to access the data."

Conventional testing has following attributes:

# It is aimed to test a positive requirement i.e. to create the conditions in which the requirement is intended to hold true and verify that the requirement is satisfied by the software.


# To apply conventional testing approach to the negative requirements, we need to create every possible set of non-feasible conditions.


Methods of Security Testing:
To confirm if a particular software application meets the security requirements, usually following two methods of testing are adopted
1) Functional security testing: It is meant to ensure that the software behaves according to certain specified functional requirements and is expected to demonstrate that the specified requirements are totally satisfied at the acceptable level. Functional requirement generally have a form like - "When a certain thing takes place, then the software must respond in a particular way."


2) Risk-based security testing: The first step in risk-based testing is the identification of the security risks and the potential loss associated with those risks. It tries to confirm the immunity against specific risks that have been identified through risk analysis effort. Risk-based testing addresses negative requirements, which state what a software system should not do. Tests for negative requirements are derived from a risk analysis, and generally cover not only the high-level risks identified during the design process but also address low-level risks derived from the software itself.

Testing against Negative Requirements – An Art:
In fact, the risk based testing is more of an art than a science, since it largely depends upon the security knowledge & skills of the tester. Automation tools can also be used for testing negative requirements; while individual intelligence of the test engineers still remains indispensable.

While testing the negative requirements, the security test engineers generally have an objective of finding vulnerabilities & common mistakes in the software. The test engineers try to exploit the software weaknesses by executing test cases exclusively designed for abuse and misuse.


How to define Tests for Negative Requirements?
Past experience remains the fundamental base while defining the test conditions for testing the negative requirements. Past experience helps in following ways.

1) Use of Test Templates: Generally matured test organizations maintain a set of test templates that describe the testing techniques for use against specific risks and requirements in specific types of software modules. The test templates are generally created during various testing projects, and such templates get accumulated over a passage of time capture the past experience of the organization.
2) Use of Incident Reports: It is another way to derive test scenarios from past experience. Incident reports can be simple bug reports, but in the context of security testing they can represent a forensic description of the successful intruder activity.

When designing risk-based tests, it is wise to consult IT security personnel, who are supposed to keep up-to-date information on vulnerabilities, incident reports, and security threats.

3) Use of Attack Pattern Data: While doing security testing, available data on attack patterns can be used effectively to create test cases that reflect attacker behavior and to help identify the test cases that validate secure behavior.

4) Use of Threat Modeling Techniques:
Information related to threat modeling used in the past can be used while designing risk-based tests. For instance, if inexperienced intruders are expected to pose a major threat, then it is advisable to conduct test using automated tools – reason being the intruders generally use similar tools for breaching the security of software applications.

What are the common techniques for Security Testing?
Few of the security testing techniques commonly used are:
# Network scanning
# Vulnerability scanning
# Password cracking
# Log review
# Integrity checkers
# Virus detection
# War dialing
# War driving (wireless LAN testing)
# Penetration testing

In actual practice combination of many such techniques may be used to have a more comprehensive assessment of the overall security aspect.

Top 10 Negative Test cases


Negative test cases are designed to test the software in ways it was not intended to be used, and should be a part of your testing effort.  Below are the top 10 negative test cases you should consider when designing your test effort:
 
  1. Embedded Single Quote – Most SQL based database systems have issues when users store information that contain a single quote (e.g. John’s car).  For each screen that accepts alphanumeric data entry, try entering text that contains one or more single quotes.
  2. Required Data Entry - Your functional specification should clearly indicate fields that require data entry on screens.  Test each field on the screen that has been indicated as being required to ensure it forces you to enter data in the field.
  3. Field Type Test – Your functional specification should clearly indicate fields that require specific data entry requirements (date fields, numeric fields, phone numbers, zip codes, etc).  Test each field on the screen that has been indicated as having special types to ensure it forces you to enter data in the correct format based on the field type (numeric fields should not allow alphabetic or special characters, date fields should require a valid date, etc).
  4. Field Size Test – Your functional specification should clearly indicate the number of characters you can enter into a field (for example, the first name must be 50 or less characters).  Write test cases to ensure that you can only enter the specified number of characters. Preventing the user from entering more characters than is allowed is more elegant than giving an error message after they have already entered too many characters.
  5. Numeric Bounds Test – For numeric fields, it is important to test for lower and upper bounds. For example, if you are calculating interest charged to an account, you would never have a negative interest amount applied to an account that earns interest, therefore, you should try testing it with a negative number.   Likewise, if your functional specification requires that a field be in a specific range (e.g. from 10 to 50), you should try entering 9 or 51, it should fail with a graceful message.
  6. Numeric Limits Test – Most database systems and programming languages allow numeric items to be identified as integers or long integers.  Normally, an integer has a range of -32,767 to 32,767 and long integers can range from
    -2,147,483,648 to 2,147,483,647.  For numeric data entry that do not have specified bounds limits, work with these limits to ensure that it does not get an numeric overflow error.
  7. Date Bounds Test – For date fields, it is important to test for lower and upper bounds. For example, if you are checking a birth date field, it is probably a good bet that the person’s birth date is no older than 150 years ago.  Likewise, their birth date should not be a date in the future.
  8. Date Validity – For date fields, it is important to ensure that invalid dates are not allowed (04/31/2007 is an invalid date).  Your test cases should also check for leap years (every 4th and 400th year is a leap year).
  9. Web Session Testing – Many web applications rely on the browser session to keep track of the person logged in, settings for the application, etc.  Most screens in a web application are not designed to be launched without first logging in.   Create test cases to launch web pages within the application without first logging in.  The web application should ensure it has a valid logged in session before rendering pages within the application.
  10. Performance Changes – As you release new versions of your product, you should have a set of performance tests that you run that identify the speed of your screens (screens that list information, screens that add/update/delete data, etc).   Your test suite should include test cases that compare the prior release performance statistics to the current release.  This can aid in identifying potential performance problems that will be manifested with code changes to the current release.

3 Goals of Usability Testing


The study of user behaviour on the Web shows that they do not perceive the slow sites and sites with complex designs. People do not want to wait. Also, they do not want to learn how to use the home page. There are no such things as web-site training or instructions for the website. People want to grasp the functionality of the site immediately after a cursory scan the page for a few seconds.
 
From the point of view of some companies, usability testing is part of a larger effort to improve the profitability of products. There are many aspects to doing so, which in the end also benefits users greatly: design decisions are informed by data gathered from representative users to expose design issues so they can be remedied, thus minimizing or eliminating frustration for users.

Informing Design

The overall goal of usability testing is to inform design by gathering data from which to identify and rectify usability deficiencies existing in products and their accompanying support materials prior to release. The intent is to ensure the creation of products that:
  • Are useful to and valued by the target audience
  • Are easy to learn
  • Help people be effective and efficient at what they want to do
  • Are satisfying (and possibly even delightful) to use

Eliminating Design Problems and Frustration

One side of the profitability coin is the ease with which customers can use the product. When you minimize the frustration of using a product for your target audience by remedying flaws in the design ahead of product release, you also accomplish these goals:
  • Set the stage for a positive relationship between your organization and your customers.
  • Establish the expectation that the products your organization sells are high quality and easy to use.
  • Demonstrate that the organization considers the goals and priorities of its customers to be important.
  • Release a product that customers find useful, effective, efficient, and satisfying.

Improving Profitability

Goals or benefits of testing for your organization are:
  • Creating a historical record of usability benchmarks for future releases. By keeping track of test results, a company can ensure that future products either improve on or at least maintain current usability
  • standards.
  • Minimizing the cost of service and support calls. Amore usable product will require fewer service calls and less support from the company.
  • Increasing sales and the probability of repeat sales. Usable products create happy customers who talk to other potential buyers or users.
  • Happy customers also tend to stick with future releases of the product, rather than purchase a competitor’s product.

The customer’s benefits at a glance

  • Increased efficiency of applications use;
  • Reducing of application study time by end users;
  • Reducing of you resources required for usability testing.