Why your website be tested for SQL Injection?

SQL injection is one of the common techniques of attacks used by the hackers where malicious users can inject SQL commands into an SQL statement, via web page input.
SQL commands can be injected and alter SQL statement to compromise the security of a web application.

An Example:
SQL Injection Based on 1=1 is Always True
The intention of the code is to create an SQL statement to select a user with a given user id.
If the web application is made in such a way that there is nothing to prevent a user from entering “wrong” input, the user can enter some “smart” input like this:
SELECT * FROM Users WHERE UserId = 10 or 1=1
The above SQL is valid. It will return all rows from the table Users, since WHERE 1=1 is logically always true.
The above example will seem dangerous If the Users table contains names and passwords.

The SQL statement above is much the same as this:
SELECT UserId, Name, Password FROM Users WHERE UserId = 10 or 1=1

A smart hacker might get access to all the user names and passwords in a database by simply inserting 10 or 1=1 into the input box.

Conclusion
Web sites require constant access to the database. Firewalls provide little or no defense against SQL injection attacks. Antivirus programs are equally ineffective at blocking SQL injection attacks. They are intended to spot and stop an entirely different kind of incoming data.

The most commonly used SQL injection defense is made up of two components –
• Routine updating and patching of all servers, services and applications.
• Producing and using well written and well tested website code that disallows unexpected SQL commands.

 

Saarah Nadia

Test Analyst

Adactin Group

Agile Estimation and Planning – Planning Poker

Agile is not a process, it’s a philosophy or set of values to move quickly and easily. In this article I am going to discuss one of the effective agile planning and estimation method.

Planning Poker:

It is an Agile estimating technique which has become very popular in the last few years. Agile teams have taken advantage in using Planning poker cards as it is extremely simple to play and also powerful technique to extricate the collective wisdom of the team.

How to Play??

The basic rules are:

  • Each participant gets a deck of cards as shown in the fig 1.2 which represents a sequence of numbers or the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, etc.), which is more popular.
  • Product owner explains one User story from the Product Backlog to the team
  • Product owner answers all the relevant questions that the team have got about the User story.
  • Every participant selects a card which represents an estimate of the time, risk involved, complexity, and other relevant factors involved.
  • When everybody are ready with an estimate, all the cards are presented on a board for finalizing.
  • If there is a harmony /agreement on one particular number then the estimation is recorded and move to another User story.
  • Repeat the same process for all the User stories in the product Backlog as shown in the fig 1.3

Reasons behind the success of using Planning poker:

poker

  • Estimates are done in groups, logic behind is simple – Each person in the team have different experience and different ideas, there by benefit of teams collective intelligence.
  • Strengthen collaboration by engaging entire team.
  • Creates harmony in estimating rather than having a single person control the estimate.
  • Reveal issues early through timely discussions for each story.

Conclusion:

By following the correct process and making an estimate for each User story allows the team to understand clearly how much the team can deliver the working software at the end of each Sprint/iteration.

 

Hope you enjoyed reading…have a great day.

 

Sujatha Nalluri

Test Analyst

Adactin Group

Agile Projects: How should Test Teams Adapt ?

When quality assurance teams and management who have adopted Agile practices first put the ideas to work, they face a significant impediment in unlearning the traditional mind-set and practices that experience in traditional practices has instilled in them.

The following adaptation practice was documented after our experience in couple of key projects that moved to Agile methodology. These practices are a real life saver for project teams that are new to Agile.

The following are some of the key aspects that need to be unlearned before attempting to deploy Agile practices, from a QA perspective:

 

  • The testing team needs to be independent and independently empowered in order to be effective.
  • Without a separate test strategy and test plan, it’s tough to manage testing.
  • The V-model for verification and validation cannot be applied in an Agile sprint.
  • Independent testing teams don’t do white-box testing.
  • The value of testing is realized only when defects are logged.
  • Automation is optional and is required only when regression testing is needed.
  • Testing nonfunctional aspects, such as performance of the system, is not possible in a sprint.
  • Testing must follow planning, specification, execution, and completion sequentially.
  • We don’t have to write new test cases for detected defects.
  • Poorly written code is not the testing team’s focus, as long as the code addresses the required functionality.
  • Test-process improvement models do not address aspects of Agile testing.