Some misconceptions about agile testing

Agile development is become popular to organizations day by day. Testing persons needs to perform ‘Agile Testing’ for agile development. There are lots of misconceptions about agile testing. Some very common myths are discussed below:

Myth1: Agile Testing is ad hoc

Ad hoc testing is performed without planning and documentation. Agile involves with planning sprints and resources forward of time. The test cycles are sync with development cycles; that are an inherent part of the planning.  The agile test plans are based on the user stories of a sprint. The stories may be included or removed from a sprint. Agile testing is centered on the developed stories; so, it is not ad hoc.

Myth2: Testing in Agile is undocumented, quick and dirty

Documentation is an important part of agile project. Agile insists on rapid communication. The only difference with other mythologies is that agile gives more important to face-to-face interaction than extreme dependence on written communication. Agile maintains tools for communication.  

The agile teams are usually provided with guidelines and requirements on the level of documentation and coding comments that they need to incorporate.

Myth3: Agile Testing does not have defined strategies

Testing cycle is synchronized with development, and it acts as quality gateways for the sprints in agile project. Multiple approaches are followed to quickly test the stories of a sprint. Also, agile testing helps in continuous monitoring of the application after release; and ensuring a complete feedback loop for the next sprints.

Myth4: Agile testing is tool oriented

Agile is a person oriented methodology. Agile gives more importance to person over process and tools. Efficient development and testing practices are more important than just being able to use tools. Test teams are engaged with daily sprint meetings from the start of user story identification. So, it helps to identify issues on early in the sprint.

Myth5: Agile Testing is best done by developers

Testing is inspired through the agile methodology. It is done by both developers and testers. It is a collaborative work approach between developers and testers. Testing teams are seamlessly integrated with the development life-cycle. The role of a tester in agile becomes more proactive.  

Testers seamlessly collaborate with the developers to meet their goal of delivering a bug free product by finding the bugs, fixing those, and verifying those before a sprint release.

Myth6: Agile Testing should all be at same geographical location

It is definitely good to have the whole team in one geographical location. Teams are assembled from different geographical locations with the help of technology in a global company. Meetings can be held involving people all around the world at the click of a button. There are some tools available for collaboration and file sharing.

Testing teams should be ready to accommodate different time zones and leverage technology to adopt efficient meeting practices. With a little effort, flexibility, adaptability and the proper mind-set, distributed teams can just be as agile as the co-located teams.

So, try to avoid the above listed misconceptions and start Agile from today.

Web apps vulnerability: Why & how to protect – The Basics

Businesses are concerned with the problem of penetration into their using web apps by unauthorized persons. Organization uses applications to provide better service to customers. But if these apps are compromised by unauthorized code then the business loses integrity.

Now a day, it is our big concern to protect our business apps from being compromised. The first step is to understand how and why apps are compromised.

Why the web apps are vulnerable?

Web codes are mainly HTML. HTML is a clear text language which is visible to anyone by visiting the sites. Hackers can easily modify the code and add functionalities that either act differently or obstruct existing functionality.

Hackers can penetrate code in the following ways:

Injection: The attacker injects malicious code into the web code. This malicious code is written to extract information from the client’s computer or device for unscrupulous use.

Cross Site Scripting (XSS):  Hacker inserts a script into the code that is run at the client’s site. This script may be for extracting information or providing misinformation in order to undermine competition.

Identity Theft: Here the attacker assumes the identity of the user and accesses important or sensitive data. The hacker then can use this data to cause inconvenience or loss to the user.

Direct Object Reference: This type of risk occurs when objects such as tables within a database are directly referenced in the URL. The hacker can use this object to access related objects within the database.

Insecure cryptography: Sensitive data such as credit card information, bank details, SSN etc. may be hacked by corrupt persons if they are stored, or travel over the internet, encoded in a simple and easy to break code.

Insufficient Layering: Applications that do not encrypt and decrypt data or authenticate users, or check certificates, may be used by hackers to gather personal data of the users.

How to avoid these risks

The above list is not full but does cover some major areas of vulnerability. Developers, web designers, SQA/Test staffs can counter these vulnerabilities by being aware of them and including code that will look out for malicious code.

Basic Security Practices for Web Applications:

• Applications use data entered into forms to access databases. If this data is validated before accessing the database, injections can frequently come to light. Proper validation can also detect malicious scripts entered into the code.

• Coders must assume that any data entered by users is untrusted. All inputs must be validated before use. Checking for type, length, format, and range are the common ways in which inputs are validated.

•  Identity thefts and broken authentications can be prevented by forcing a user to re-login even though he has not explicitly logged out. When a user logs in to a site an id is created. If this id is created using a predictable formula then hackers can pinch that identity and resend it to access client information. Generating random id is the best way to avoid risks of identity thefts.

• Randomizing ids can also mitigate attacks due to direct object reference. In fact, databases should never be directly accessed by user entered data. Applications should validate and clean data before accessing databases.

• Most importantly, the infrastructure used to run applications including hardware, software, OS and other components must be secured.

 So, we need to concern about above listed practice to avoid vulnerability of our business apps.