Reducing test case documentation time

by – Ranjit Shewale jcrvs@hotmail.com
Summary
This article describes about the approach to reduce documentation and correction overhead of test cases for the test team so they can spend more time on creating
innovative test cases and actual testing. This also leads to a structured documentation approach of test case during the test case preparation phase.

Ask yourself
1. How much time does your team spend in documenting test case?
2. How much time do you spend in internal reviews?
3. How much time do you spend in correcting it?
4. How much time do you spend in correcting the test cases if the client sends across the review comments prior to signing it off?
If the answer to above is ‘most of the time’, then you need a structured approach to test documentation.
Why would you want to save the time?
Reducing Test Case Documentation Time

Improving Test Effectiveness Using Fact-Based Test Prioritization

by Impetus.com – Impetus Knowledge Center (via Apeksha Bobde)

Testing is emerging as a very critical component in the product development life cycle and effective testing is being talked about as the key to better quality products, delivered on-time to the market.
Today, organizations spend several hours in testing their products for problems. The testing team creates hundreds of test cases to validate the requirements that are being developed. The test suites that are created often grow over time, requiring companies to conduct tests that need to run manually—a process that takes hours to execute. Many of the tests that get added to the test suites may be redundant, or simply non-productive. Often the tests target the areas..
Read the complete whitepaper below:

Security Testing – Points to take care

Following Things are supposed to take care for the security of any Web based application:

  1. Make ensure the security of the project; you should delete any users who are no longer working on the project/application.
  2. We should Edits IP Address restrictions for web security, so that a particular computer or group of computers
  3. Have certain access rights on the FrontPage web. IP Address masks can include asterisk wildcards, for example “128.109.*.*”. We can do this by typing this command from Run, this htm is existing in each & every windows machine:

C:Program FilesCommon FilesMicrosoft Sharedweb server extensions40admisapiipaddr.htm
C:Program FilesCommon FilesMicrosoft Sharedweb server extensions40admcgiipaddr.htm

  1. Cookies: Cookies are often used to store information about the user and his actions on a particular site. When a user accesses a site that uses cookies, the web server sends information about the user and stores it on the client computer in form of a cookie. These can be used to create more dynamic and custom-made pages or by storing, for example, login info. If you have designed your site to use cookies, they need to be checked. Verify that the information that is to be retrieved is there. If login information is stored in cookies check for correct encryption of these. If your applications require cookies, how does it respond to users that disabled the use of such? Does it still function or will the user get notified of the current situation. How will temporary cookies be handled? What will happen when cookies expire? Depending on what cookies are used for, one should examine the possibilities for other solutions:
  2. Encryption of e.g. login info
  3. Users denying or accepting.
  4. Temporary and expired cookies
  5. Log-files: are a very important in order to maintain security at the site. Verify that relevant information is written to the log-files and that the information is traceable. When secure socket layers are used, verify that the encryption is done correctly and check the integrity of the information, No access to edit scripts on the server without authorization.
  6. Hackers often stress systems by providing loads of wrong in-data until it crash and then gain access to it during start-up. So make sure that login page is capable to handle a heavy load.
Understanding QEngine’s Load Testing Process

Understanding QEngine’s Load Testing Process

Once you plan your load test, the next step is to perform the load testing process. Load testing is the process of identifying performance bottlenecks in your web application under normal and peak loads. This will help you to tune the resources (both the hardware and the software) of your web application and optimize the user experience for maximum performance.
Following are the steps involved in QEngine Load Testing process:
Load Testing process
Step 1: Record User Scenarios
Create a load test script and record the user scenarios or transactions in your web application. Here, the user scenarios are the one identified in your planning phase in Step1.
Step 2:  Parameterize Test Scripts
Once you have your basic recorded load test script, you have to parameterize the load test script to vary the input to the server. This will help you to emulate real-world testing and avoid errors arising out of duplicate values.
Identify the list of values to be parameterized. Replace the recorded values with parameters to pass different set of data to the server each time the script is executed. For example, user name and password values can be parameterized using the Dataset option in a login script to pass different user name and password for each replay. The values for the parameter can be fetched from an external datasource (CSV or database) or from a cookie or from a previous response body or from a hidden field or from a previous URL or by executing a Javascript or using a constant value.
Step 3:  Group User Scenarios as User Profiles and Associate % of Workload
After recording the user scenarios as load test scripts, the next step is to group the user scenarios as user profiles and configure the % of workload for each user scenario.  The objective of grouping the user scenarios as user profiles is to map the real time user activities i.e., users accessing different parts of the web application, performing different operations. User profiles greatly increases the accuracy of your load test, since it better simulates what your web server will be seeing in the real world.
For example, consider the following user scenarios grouped as user profile for the sample online bookstore application:
User Profile: Named testprofile includes three user scenarios where 60% of users are browsing the home page, 20% of users are purchasing items from the shopping cart and the other 20% of users are searching for required items.

QEngine Scenarios
Step 4: Simulate Load
In this step, you examine your web application’s behavior under simulated load conditions. This will help you to identify whether your application is trending toward or away from its defined performance objectives. Once you identify the load type to be simulated based on the instructions given in Step 4 in Planning Your Load Test, select the appropriate load type and configure the workload details. For example, let us consider the following load for a sample online bookstore application.

    • Load Type – Normal
    • User Count – 100 users
    • Sample Period – 60 seconds
    • Test Duration – 120 seconds

In the above configuration, sample period is 60 seconds and the test duration is 120 seconds. With this configuration, QEngine will run for 2 (120/60) samples. You should always ensure that the given sample period is enough to complete all the urls within the given test duration time.  
Load Distribution for the above load configuration in Step 4 and user profile configuration as given in Step 3 will be as follows:
QEngine Scenarios 2

Step 5: Create Load Test Cases
Create load test cases where you associate the user profiles (one or more user scenarios) created in Step 3 with the workload (users to be simulated against the web application) created in Step 4. Each test case consists of the following:
· User Profiles with key user scenarios and unique settings specific to each scenario.
· Workload details which includes load type, users to be simulated, sample period and test duration.
· Report Sample Period.
Here, report sample period is the length of time over which the values collected during the testcase execution should be reported. For example, if the sample period is 15 seconds, the statistics views showing the results of a test will have values every 15 seconds. This value should be shorter for short tests, and longer for long tests.
Step 6: Run Load Test Cases
Run the load test case. You can run the load test case created in Step 5 using the verify mode to verify it with a single user or with the configured load using the following steps:

    • Click on the Start Play option from QEngine Toolbar.
    • From the Play Details pane, select the load test case to be verified from the Select a Test Case combo and choose the Run with Verify mode or Configured mode radio option. 

During load test execution, QEngine automatically simulates the test runs for various workload models emulating real-time user roles and access patterns.  Displays runtime graphs during execution and after test completion, displays the detailed reports and graphs.
Step 7: Analyze Test Results
The final step is to analyze the test results which is both the most important and the most difficult part of performance testing process. To make this process easier, the reports and graphs page that gets displayed after load test execution is organized in a clear and easy to understand format. This will help you to just click the various links in the left pane and identify the performance bottlenecks.
When you run the load test for the test case created in Step 4, the results will be as follows:

Avg. Hits/sec or load generated against server: 20 hits per second.
Avg. Page Download Time: 4,371 milliseconds.
Avg. Throughput or Data Transfer Rate: 83,552 bytes per second.
Avg. Response Time or How Fast your Server Responds: 4,334 milliseconds response time.
Avg. Error Percentage: 25% for 120 active users when the elapsed time is at 30 seconds.
Server Monitoring Results:
% CPU Usage: 40 percent
Memory Usage: 60 percent

References:

http://www.manageengine.com/products/qengine/web-performance-evaluation-guide.html
https://qengine.wiki.zoho.com/Understanding-Load-Testing-Process-.html

Basics of Test Effort Estimation

– By Murali Chemuturi

Why Testing is carried out? Why Software Testing is important? Testing is carried out primarily for unearthing any defects present in the system and to prevent a defective product reaching the customers. Secondarily, testing is also carried out to convince the customer that the product conforms to and fulfills the specifications and the functionality agreed to.
Software Testing is recognized as a very important activity in software development. Of late, the importance of independent testing – that is testing by persons not involved in the development of software – is increasingly being recognized, so much so, software companies specialized only in testing are established and are doing good business. Also significant is the fact that as the complexity and size of the software increased multi-fold – so has the complexity of testing as well as the types of testing. As a result, there is a paradigm shift in the estimation of testing effort from being taken as a percentage of development effort, to independent size estimation and effort estimation. Practitioners have come out with a size measure called “Test Points”. To the extent that I saw, the Test Points address the “Black Box” testing as used in Integration, System and Acceptance testing activities.
This paper intends to throw light on the complete testing activity and suggest a few solutions to estimation of testing effort.
Read more at below document:Basics of Software Test Effort Estimation