Agile Testing @ Google Tech Talks

Watch out the Google Video Talk

Check out the PDF

Few Security testing fundas for Web Apps

How to test Web site login security

Security is a major aspect of any Web site. Before testing the functionality, first you need to check the login page, because the login page is the main entry for hackers to any Web site. It is the tester's responsibility to check whether the login page is properly secured or not.

The technique you can use to check the security of the login page is this:

Username: ' or 1=1--
Password: any

If you enter the script given, you can easily log in to the system if developer has not applied proper validation in the code. This technique is called SQL Injection, and it means you are terminating the existing query using your script.

Few more techniques on securing web applications from sql injection

SQL Injection exploits may soon be as common as those targeting Windows and Unix flaws, experts say. An estimated 60% of Web applications that use dynamic content are likely vulnerable, with devastating consequences for an enterprise. Learn how to recognize whether your sites are vulnerable.

Step 1. Open the Web site in a browser.

Step 2. Mouse over the links of the Web site with your cursor while paying attention to the bottom status bar. You will notice the URLs that the links point to. Try to find a URL with parameters in it. Ex. http://www.site.com/articleid.asp?id=42. Most SQL injection problems are present when the file extensions are ".asp" or ".cfm". When trying to test a site for SQL injection vulnerabilities, look for these files specifically.

Note: If you don't see any URL's in the status bar, then just click on links and watch the address bar until you find a URL that has parameters.

Step 3. Once a URL with parameters has been found, click the link and go to that page. In the Address bar you should now see the URL that was seen in the status bar.

Step 4. Here is where the actual testing takes place. There are two methods for testing script for SQL injection. Be sure to test each parameter value one at a time with both methods.

Method 1. Go to the address bar, click your cursor, and highlight a parameter value Ex. Highlight the word value in "name=value" and replace it with a single quote (').It should now look like "name='"

Method 2. Go to the address bar, click your cursor, and put a single quote (') in the middle of the value. It should now look like "name=val'ue"

Step 5. Click the 'GO' button. This will send your request to the Web server.

Step 6. Analyze the response from the Web server for any error messages. Most database error messages will look similar to the examples below:

Example error 1:
Microsoft OLE DB Provider for SQL Server error '80040e14'
Unclosed quotation mark before the character string '51 ORDER BY
some_name'. /some_directory/some_file.asp, line 5

Example error 2:
ODBC Error Code = S1000 (General error)
[Oracle][ODBC][Ora]ORA-00933: SQL command not properly ended

Step 7. Sometimes the error message is not obvious and is hidden in the source of the page. To look for it, you must view the HTML source of the page and search for the error. To do this in Internet Explorer, click the 'View' menu, and select the 'Source' option. This will cause notepad to open with the HTML source of the page. In notepad, click the 'Edit' menu and select 'Find'. A dialog box will appear that will ask you to 'Find What'. Type the phrase 'Microsoft OLE DB' or '[ODBC]' and click 'Find Next'.

Step 8. If either step 6 or 7 is successful, then the Web site is vulnerable to SQL injection

Quick and simple differences between Smoke & Sanity tests

Many testers assumes that Smoke and Sanity testing are same but there are deviations between those two here are they:

SMOKE TESTING:

• Smoke testing originated in the hardware testing practice of turning on a new piece of hardware for the first time and considering it a success if it does not catch fire and smoke. In software industry, smoke testing is a shallow and wide approach whereby all areas of the application without getting into too deep, is tested.
• A smoke test is scripted, either using a written set of tests or an automated test
• A Smoke test is designed to touch every part of the application in a cursory way. It’s shallow and wide.
• Smoke testing is conducted to ensure whether the most crucial functions of a program are working, but not bothering with finer details. (Such as build verification).
• Smoke testing is normal health check up to a build of an application before taking it to testing in depth.

SANITY TESTING:

• A sanity test is a narrow regression test that focuses on one or a few areas of functionality. Sanity testing is usually narrow and deep.
• A sanity test is usually unscripted.
• A Sanity test is used to determine a small section of the application is still working after a minor change.
• Sanity testing is a cursory testing, it is performed whenever a cursory testing is sufficient to prove the application is functioning according to specifications. This level of testing is a subset of regression testing.
• Sanity testing is to verify whether requirements are met or not, checking all features breadth-first.

Manual and Automation testing Challenges

So here we go with the top challenges:

1) Testing the complete application:
Is it possible? I think impossible. There are millions of test combinations. It’s not possible to test each and every combination both in manual as well as in automation testing. If you try all these combinations you will never ship the product

2) Misunderstanding of company processes:
Some times you just don’t pay proper attention what the company-defined processes are and these are for what purposes. There are some myths in testers that they should only go with company processes even these processes are not applicable for their current testing scenario. This results in incomplete and inappropriate application testing.

3) Relationship with developers:
Big challenge. Requires very skilled tester to handle this relation positively and even by completing the work in testers way. There are simply hundreds of excuses developers or testers can make when they are not agree with some points. For this tester also requires good communication, troubleshooting and analyzing skill.

4) Regression testing :
When project goes on expanding the regression testing work simply becomes uncontrolled. Pressure to handle the current functionality changes, previous working functionality checks and bug tracking.

5) Lack of skilled testers:
I will call this as ‘wrong management decision’ while selecting or training testers for their project task in hand. These unskilled fellows may add more chaos than simplifying the testing work. This results into incomplete, insufficient and ad-hoc testing throughout the testing life cycle

6) Testing always under time constraint:
Hey tester, we want to ship this product by this weekend, are you ready for completion? When this order comes from boss, tester simply focuses on task completion and not on the test coverage and quality of work. There is huge list of tasks that you need to complete within specified time. This includes writing, executing, automating and reviewing the test cases.

7) Which tests to execute first?
If you are facing the challenge stated in point no 6, then how will you take decision which test cases should be executed and with what priority? Which tests are important over others? This requires good experience to work under pressure.

8 ) Understanding the requirements:
Some times testers are responsible for communicating with customers for understanding the requirements. What if tester fails to understand the requirements? Will he be able to test the application properly? Definitely No! Testers require good listening and understanding capabilities.

9) Automation testing:
Many sub challenges - Should automate the testing work? Till what level automation should be done? Do you have sufficient and skilled resources for automation? Is time permissible for automating the test cases? Decision of automation or manual testing will need to address the pros and cons of each process.

10) Decision to stop the testing:
When to stop testing? Very difficult decision. Requires core judgment of testing processes and importance of each process. Also requires ‘on the fly’ decision ability.

11) One test team under multiple projects:
Challenging to keep track of each task. Communication challenges. Many times results in failure of one or both the projects.

12) Reuse of Test scripts:
Application development methods are changing rapidly, making it difficult to manage the test tools and test scripts. Test script migration or reuse is very essential but difficult task.

13) Testers focusing on finding easy bugs:
If organization is rewarding testers based on number of bugs (very bad approach to judge testers performance) then some testers only concentrate on finding easy bugs those don’t require deep understanding and testing. A hard or subtle bug remains unnoticed in such testing approach.

14) To cope with attrition:
Increasing salaries and benefits making many employees leave the company at very short career intervals. Managements are facing hard problems to cope with attrition rate. Challenges - New testers require project training from the beginning, complex projects are difficult to understand, delay in shipping date!

These are some top software testing challenges we face daily. Project success or failure depends largely on how you address these basic issues.