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, July 31, 2012

Security Testing - Penetration Checklist


1) Check if web application is able to identify spam attacks on contact forms used in the website.
2) Proxy server – Check if network traffic is monitored by proxy appliances. Proxy server make it difficult for hackers to get internal details of the network thus protecting the system from external attacks.
3) Spam email filters – Verify if incoming and outgoing email traffic is filtered and unsolicited  emails are blocked. Many email clients come with in-build spam filters which needs to be configured as per your needs. These configuration rules can be applied on email headers, subject or body.
4) Firewall – Make sure entire network or computers are protected with Firewall. Firewall can be a software or hardware to block unauthorized access to system. Firewall can prevent sending data outside the network without your permission.
5) Try to exploit all servers, desktop systems, printers and network devices.
6) Verify that all usernames and passwords are encrypted and transferred over secured connection like https.
7) Verify information stored in website cookies. It should not be in readable format.
8 ) Verify previously found vulnerabilities to check if the fix is working.
9) Verify if there is no open port in network.
11) Verify all telephone devices.
12) Verify WIFI network security.
13) Verify all HTTP methods. PUT and Delete methods should not be enabled on web server .
14) Password should be at least 8 character long containing at least one number and one special character.
15) Username should not be like “admin” or “administrator”.
16) Application login page should be locked upon few unsuccessful login attempts.
17) Error messages should be generic and should not mention specific error details like “Invalid username” or “Invalid password”.
19) Verify if special characters, html tags and scripts are handled properly as an input value.
20) Internal system details should not be revealed in any of the error or alert messages.
21) Custom error messages should be displayed to end user in case of web page crash.
22) Verify use of registry entries. Sensitive information should not be kept in registry.
23) All files must be scanned before uploading to server.
24) Sensitive data should not be passed in urls while communicating with different internal modules of the web application.
25) There should not be any hard coded username or password in the system.
26) Verify all input fields with long input string with and without spaces.
27) Verify if reset password functionality is secure.
28) Verify application for SQL Injection.
29) Verify application for Cross Site Scripting.
31) Important input validations should be done at server side instead of JavaScript checks at client side.
32) Critical resources in the system should be available to authorized persons and services only.
33) All access logs should be maintained with proper access permissions.
34) Verify user session ends upon log off.
35) Verify that directory browsing is disabled on server.
36) Verify that all applications and database versions are up to date.
37) Verify url manipulation to check if web application is not showing any unwanted information.
38) Verify memory leak and buffer overflow.
39) Verify if incoming network traffic is scanned to find Trojan attacks.
40) Verify if system is safe from Brute Force Attacks – a trial and error method to find sensitive information like passwords.

10 Reasons to Fix Bugs


Monday, July 30, 2012

Testing and Checking

Testing and Checking

 

Checking

  • Doesn’t mean the product works
  • Help us know that the product works within expectations
  • Can ‘pass’ but still have serious problems
  • Automated tests are checks
  • Need specifications
  • Helps answer – does the system do what it is supposed to do?
  • Great programmers do alot of checking
Is
  • Confirmation
  • Verification
  • Validation
  • Making sure the program doesn’t fail
  • Verifying beliefs we expect to be true
Checks
Are machine decidable:
  • Yes
  • No
  • True
  • False
  • Pass
  • Fail

Testing

Is
  • Exploration
  • Learning
  • Finding new information
  • Discovery
  • Investigation
  • Evaluating
  • Finding problems
  • Searching for extents and limitations
  • Driven by questions
  • Finding problems not covered in checks
Tests
  • Have open ended results
  • Asks if there is a problem here?
  • Can be about finding out if checks have been good enough
  • Problems found from testing can be used to create checks to stop them appearing in the future
  • Do not require specifications
  • Involves some checking

The Debate

  • Why do we need to define the difference?
  • Does more terminology just cause more confusion?
  • What problem is this distinction solving?
  • Should it not be ‘versus’ it should be Testing AND Checking

Friday, July 13, 2012

Test Plan Mindmap


Testing Terminology Redefined | Just For Reading


*   Aggression Testing: If this doesn’t work, I’m gonna kill somebody.
*   Compression Testing: []
*   Confession Testing: Okay, Okay, I did program that bug.
*   Congressional Testing: Are you now, or have you ever been a bug?
*   Depression Testing: If this doesn’t work, I’m gonna kill myself.
*   Egression Testing: Uh-oh, a bug… I’m outta here.
*   Digression Testing: Well, it works, but can I tell you about my truck…
*   Expression Testing: #@%^&*!!!, a bug.
*   Obsession Testing: I’ll find this bug if it’s the last thing I do.
*   Oppression Testing: Test this now!
*   Poission Testing: Alors! Regardez le poission!
*   Repression Testing: It’s not a bug, it’s a feature.
*   Secession Testing: The bug is dead! Long lives the bug!
*      Suggestion Testing: Well, it works but wouldn’t it be better if…