बुधवार, एप्रिल २५, २०१२

Working With CanCan : Basic Implemtation

Starting with CanCan implementation :

For implementing cancan we just have to add below text in gemfile:
gem 'cancan'
and run
bundle install
Then we have to create a class 'Ability'.
rails g cancan:ability
In this new class we can define our authorization code just like:
class Ability
  include CanCan::Ability
    def initialize(user)
      user ||= User.new #guest user
      if user.role?("Admin")
        can :manage, :all
      else
        # Users other than admin have only read access.
        can :read, :all
      end
    end
 end

In my application I have has_many :through relationship for User and Role to manage different roles and users.
You can either have a boolean field admin in your users table, Through which you check whether the user is admin or not.

The authorization part is not handled for the application yet.

To restrict user from accessing the information needs to be handled in views.

Example:
You have edit, update and delete actions for your product. So we can restrict as follow .
<% if can? :update, @product %>
  <%= link_to "Edit", edit_product_path(product.id) %>
<% end %>

<% if can? :destroy, @product %>
  <%= link_to "Delete" , product_path(product.id), :confirm => "Delete this product?", :method => :delete %>
<% end %>
Authorization at view end is alway not enough, it is better to have it in controller part as well..

We can do in two ways
First, we can check in each action whether user has access to the action and unauthorize him.
def new
 @product = Product.new
end

def edit
 @product = Product.find(params[:id])
 unauthorized! if cannnot? :update, @product
end
Checking authorization for each action might be tedious task, but ofcourse depends on the requirement of the controller. If you just want to add it for several actions and not for the whole controller.

Second way is, CanCan provides a method load_and_authorize_resource which actually loads the resource and authorize it. This works as a before filter for your controller
This means we don't have to find our main object in our controller's action, if we are using restful architecture.
class ProductController < ApplicationController
  load_and_authorize_resource
  def new
  end

  def edit
  end
end

This will still work, though we haven't find our @product in new and edit action, load_and_authorize_resource with do it for us..

Now, even if the user tries to acces the unauthorized action through url, it will through error saying,
CanCan::AccessDenied in ProductsController#new
You are not authorized to access this page.

You can also display suitable message or 500 error page as you require.
You just have to define following in your Application controller.
rescue_from CanCan::AccessDenied do |exception|
  flash[:error] = "Access denied."
  redirect_to root_url
end
-------------------------------------------------------------------------------
CanCan implement करण्यासाठी आपल्याला फक्त हि line आपल्या Rails प्रोजेक्ट च्या GemFile मध्ये टाकावी लागते.
gem 'cancan'
नंतर
bundle install
Run करा
आत्ता एक 'Ability' class बनवा.
rails g cancan:ability
ह्या नवीन क्लास मध्ये आपण User ला access प्रमाणे अधिकार देऊ.
class Ability
  include CanCan::Ability
    def initialize(user)
      user ||= User.new #guest user
      if user.role?("Admin")
        can :manage, :all
      else
        # Users other than admin have only read access.
        can :read, :all
      end
    end
 end
माझ्या application मध्ये, मी User's आणि त्यांचे Role's manage करण्याकरिता has_many :through relationship वापरली आहे.
तुम्ही एकतर तुमच्या users table मध्ये admin साठी एक boolean field टाकू शकता, जेच्यात तुम्ही check करू शकता के user admin आहे के इतर user.
अजूनही आपण authorization handle केलेली नाही.

User ला अधिकार नसलेल्या माहिती ला access न होऊ म्हणून आपण view मध्ये check लावू शकतो.
Example:
आपल्या कडे product साठी edit, update आणि delete असे action आहेत. तर आपण user ला restrict अश्या प्रमाणे करू शकतो.
<% if can? :update, @product %>
  <%= link_to "Edit", edit_product_path(product.id) %>
<% end %>

<% if can? :destroy, @product %>
  <%= link_to "Delete" , product_path(product.id), :confirm => "Delete this product?", :method => :delete %>
<% end %>
Authorization फक्त view end ला enough नाही, हे Controller मध्ये असणे पण गरजेचं आहे.

आपण हे दोन पद्धतीने करू शकतो.
एक, आपण प्रत्येक controller च्या प्रत्येक action मध्ये check करू सक्तो के user authorize आहे के नाही आणि मग त्याला unauthorize करू शकतो.
def new
 @product = Product.new
end

def edit
 @product = Product.find(params[:id])
 unauthorized! if cannnot? :update, @product
end
प्रत्येक action मध्ये access check करणे खूप कंटाळवाणे होऊ शकते. दुसरी पद्धत आहे.
Cancan मध्ये आपल्या एक method available आहे load_and_authorize_resource म्हणून. हि method प्रत्येक action च्या आधी आपले user resource load करते आणि त्याला authorize करते. हे आपल्या controller मध्ये before filter सारखा काम करते.

ह्याचा अर्थ असा आहे क आपल्या प्रत्येक action च्यामध्ये आपले main object find करण्याची गरज नाही, जर आपण proper restful architecture use करत आहोत तर.
class ProductController < ApplicationController
  load_and_authorize_resource
  def new
  end

  def edit
  end
end
जरी आपण आपला main object @product new आणि edit action find नाही केले तरी हे सुद्धा एकदम व्यवस्थित work करेल. @product हे load_and_authorize_resource method आपल्यासाठी find करते.
आता जरी user unauthorized action ला url through access करायचे प्रयत्न केले तरी त्याला हा error दिसेल.
CanCan::AccessDenied in ProductsController#new
You are not authorized to access this page.
आपण ह्या error च्या ऐवजी 500 error page किंवा काही message दाखवू शकतो.

आपल्याला फक्त खालील code आपल्या Application controller मध्ये टाकावा लागेल.
rescue_from CanCan::AccessDenied do |exception|
  flash[:error] = "Access denied."
  redirect_to root_url
end

मंगळवार, मार्च २७, २०१२

Ruby समजुन घेण्याकरता

जर ROR मध्ये fresher किंवा नविन असाल आणि जर तुम्हाला OOPs concept ची माहिती नसेल तर थोड़े कठीण होते ruby समजुन घेण्याकरता. म्हणजे कुठून अभ्यास करायचा किंवा कुठली site चांगली किंवा समजण्यासारखी आहे ज्याचा reference घेऊ शकतो? हा नेहमीच प्रश्न असतो.
तसेच एवढ्या सर्व sitesमध्ये कुठली फायदेशीर आहे हे समजण्यामध्ये गड़बड़ होते.
नक्कीच आपल्याकड़े guides आणि अजुन काही महत्वाच्या sites आहेतच.
ह्या बरोबरच अजुन काही sites आहेत ज्या तुम्ही ruby साठी refer करू शकता.

Ruby समजुन घेण्याकरता Struggling with Ruby हा blog वाचा.

हा blog खरच फायदेशीर आहे ruby टप्या टप्या ने समजुन घ्यायला. मग तुम्ही कुठल्या विषयामध्ये अडकला आहात ते content page वर  पहा .

एकदा ह्या site वर जाउन बघा तुम्हांला फायदेशीर वाटेल .

The original post can be viewed on Growing Fog as Understand Ruby

मंगळवार, मार्च २०, २०१२

STLC: Software Testing Life Cycle

माझ्या आधीच्या post मध्ये मी software आणि testing बद्दल बोलेली. ह्या post मध्ये software testing cycle बद्दल बोलेन, जसे ते कसे चालू होते, कधी चालू होते, काही issues असले तर काय, application crash झाले तर काय?, software ची quality कशी decide करायची आणि बरेच काही, काय, कधी, कसे ची उत्तरे.

आपल्याला माहित आहे की software हे लहान गोष्टीना एकत्र करून वापरण्या सारखे बनवलेले असते. जर आपण individual units चा विचार केला तर त्यांना existence नाही आणि असे units चा काही अर्थ राहत नाही . त्यांना वापरता येण्या सारखे करण्या साठी त्यांना एकत्र आशा प्रकारे जोडावे लेगेल की त्याचा एक प्रोडक्ट बनेल आणि कुठलाही task execute करता येइल.

हे units development team तयार करतात. एकदा का सर्व units उभारले आणि टेस्ट केले, integration झाल्यानंतर complete software वापरण्यासारखे होते. हे units पण तपासले जातात आणि त्या unit चे तपासणी developer करतो . Unit testing नंतर integration होते.

Unit Testing: Software लहान units ने बनवले जातात. हे units development team स्वतः टेस्ट करते . ह्यालाच unit testing असे बोलतात.

Integration Testing: Unit testing नंतर हे सगळे लहान units एकत्र केले जातात आणि एखादी task चालवायला वापरले जातात.

Interface Testing: ह्या testing मध्ये , दुसरया applications चे interface किंवा माझ्या software ला जे resource communicate करत आहेत त्याचे checking होते . उदाहरनार्थ : माझे application dusrya application, OS, H/W किंवा environment बरोबर communicate करत आहे . ह्यासाठी सर्वात चांगले उदाहरण असेल online shopping. Online shopping मध्ये खरेदी करण्यासाठी product select केल्यानंतर ग्राहकला payment gateway system चा वापर करतो ज्यामध्ये third party जसे banks, credit cards, master किंवा visa cards वगैरेचा वापर ग्राहकाच्या selection प्रमाणे केला जातो. दुसरं उदाहरण म्हणजे print command जे कुठल्या हि MS word किंवा pdf साठी दिले जाते. ह्या मध्ये MS word माझ्या P.C ला connected माझ्या Printer ला निर्देश देतो.

Smoke Testing(Smoke Testing): जेंव्हा पूर्ण build testing team ला दिला जातो तेंव्हा smoke testing होते. Smoke testing negative attitude आणि system ब्रेक करायच्या इराद्याने केला जातो . दिलेल्या build मध्ये जर system तुटले किंवा खूप महत्वाचा किंवा कठीण feature वास्तव्यात नसेल, तर build नाकारले जाते . Smoke testing test manager कडून केले जाते आणि हे जास्तीत जास्त अर्धा तास घेते. ह्याचे महत्वाचे check करण्याचे कारण म्हणजे system आहे कि नाही हे बघितले जाते .

System Testing(System Testing): System testing ह्यामध्ये system ची तपासणी किंवा पूर्ण application ची तपासणी केली जाते . सर्व workflow सुरुवातीपासून शेवटपर्यंत तपासले जाते . त्यामध्ये तुटलेल्या links किंवा flows नसले पाहिजेत. प्रत्येक सुरुवातीला शेवट असलाच पाहिजे. ह्यामध्ये, test environment हे production किंवा live environment सारखेच असायला पाहिजे . कुठले हि issues किंवा defects ह्या phase मध्ये मिळतील ते bugs म्हणून report होतील. bugzilla सारखे tools defect tracking साठी bugs band होईपर्यंत वापरले जातात. हे सर्व excelsheet मध्ये ठेवता येते पण excelsheet मध्ये ठेवणे किचकट काम असते, म्हणून एखादा tool वापरला जातो . हे tools साधारण पणे open source किंवा freeware असतात आणि net वर सोप्यारित्या मिळून जातात .

Retesting testing(Retesting testing): जे काही bugs log होतात ते development team ला दिले जातात . Development team ते fix करते आणि test team ला fixed build दिले जाते . ह्या नवीन build मध्ये system testing जे bugs log झालेले त्याचा fixes समाविष्ट असतात . ह्या bug fixes न test करायचे त्यालाच Retesting म्हणतात. Retesting हे s/w च्या बदल केलेल्या जागी केले जाते .

Regression Testing(Regression Testing): Regression testing हे change न केलेल्या जागांवर केले जाते . system testing करते वेळी असे काही features असतील जे flawless किंवा defect नसलेले असतात . Regression मध्ये , हेच flawless किंवा defect नसलेले features तपासले जातात , म्हणजे त्यामध्ये defects fix केल्या कारणाने नवीन bug येऊ नये. Development team जेंव्हा नवीन build देते तेव्हा regression testing हि केली जाते . म्हणजे नवीन build वर 2 प्रकारचे testing केले जाते . Resting आणि Regression testing. कुठला हि defect ह्या दरम्यान सापडला तर log केला जातो आणि आधी पासून असलेला defect जर बरोबर work नाही झाला तर reassign केला जातो . हे 2 प्रकार ची testing ते defects बंद होत नाही तो पर्यंत केले जातात.

Sanity testing(Sanity testing): Sanity testing हि smoke testing सारखीच असते . Sanity testing positive attitude नी केली जाते . ह्या मध्ये कुठले हि failures, defects, issues किंवा crashes नाही मिळणार असे समजले जाते . हे साध्या पद्धतीने फक्त product किंवा website ला navigate केले जाते.

Acceptance testing(Acceptance testing): म्हणजेच UAT(User Acceptance Testing). हे एक formal तपासणी असते जी system built वर केली जाते . Development, bug fixing आणि function testing पूर्ण झाल्या नंतर ही तपासणी केली जाते . ही साधारण पणे ग्राहक करतो. ह्या मध्ये 2 प्रकार आहेत: अल्फा & Beta .
Alpha Testing: ही ग्राहक किंवा बाहेर चे व्यक्ति जे ग्राहकाला represent करतात जे developers आणि testers च्या बरोबर
Beta testing: ही testing customer किंवा बाहेर चे व्यक्ति त्यांच्या स्वताच्या साईटवर करतात. ह्या टेस्टिंग च्या पद्धतीत development team चे testers involve असू किंवा नासु पुन सक्तात.

आतासाठी फ़क्त इतकेच. नवीन post सोबत लवकरच येईन.
तो पर्यंत आनंदाने वाचत रहा.


STLC: Software Testing Life Cycle


In my previous post I talked about the Software and testing. In this post I will talk about the Software testing cycle like how does it starts, when does it starts, what if there are some issues, what is application crashes, how to decide the quality of software and lot many WHAT, WHEN, HOW. We know that s/w is collection of small units joined together to make it usable. If we consider individual units, then they don’t have existence and units independently do not make any sense. To make them useful, we need to join them in such a way that they can form a product and can be used to execute any task. These units are developed by the development team. Once all the units are build and tested individually, integration is done to make the complete s/w usable. These individual units are also tested and its testing is done by developer of that unit itself. This testing is k/as Unit testing. After unit testing integration is done.

Unit Testing: S/w is made up of small units. These units are tested by development team itself. This is known as unit testing.

Integration Testing: After Unit testing, all these small units are combined together to perform or execute any task.

Interface testing: In this testing, we check the interfaces of any other application or resource communicating to my s/w. E.g. My application is talking to other s/w , OS, H/W, environment. The best example for this can be any e-commerce website i.e. online shopping. In online shopping, after selecting the product to buy, user navigates to payment gateway systems, in which third party are included like banks, credit cards, master or Visa cards etc and further it is navigated according to user’s selection. Other example can be giving print command from any MS Word or pdf. In this MS Word Is talking to my Printer connected to my PC.

Smoke testing: When a complete build is given to the testing team then smoke testing is done. Smoke testing done with negative attitude and to break the system. If system crashes or any important or critical feature is not present in the given build, then it is rejected. Smoke testing is generally done by Test manager and takes hardly half an hour. Its main purpose is to check that whether the system is dead or alive.

System Testing: System testing is testing the system or application as whole. All the workflows are executed end to end. There should not be broken links or broken flows. For each start there should be an end. In this, the test environment is same as production or Live environment. Any issues or defects found during this phase are reported as bugs. Defect tracking tools like bugzilla are used to keep track of these bugs till closure. It can be maintained in excel sheet as well, but to maintain the excel sheet is very tedious task, so a tool is used. These tools are generally open source or freeware and are easily available on net.

Retesting testing: All the bugs logged are assigned to development team. Development team fixes them and gives the fixed build to test team. This new build contains the fixes of the bugs which were logged during system testing. Now testing these bugs is known as "Retesting". Retesting is done for the changed part of the software.

Regression Testing: Regression testing is done for the unchanged part of the software. While doing the system testing, there may number of features which may be flawless or defect free. In regression, these flawless or defect free features are tested, so that there should not be possibility of initiating any new bug due to fixing the defects. When development team gives the new build for the defects found, at that time regression is also performed. So on the new build two types of testing are done. Retesting and Regression testing. Any new defect found during this phase is logged and any existing defect which is not working is re-assigned. These two testing are performed till the closure of all the defects. Sanity testing: Sanity testing is as good as smoke testing. Sanity testing done with positive attitude. In this we don’t expect any failures, any defects, any issues or any crashes. It is also done like simple navigation across the product or website.

Acceptance testing: aka UAT(User Acceptance Testing). This is formal testing done on the actual system built. After completion of development, Bug fixing and Functional Testing, this testing is done. It done with real data. It is generally done by Customer or clients. It is of two types: अल्फा & Beta
Alpha Testing: It is an in house testing done customer or external entities representing customer at developers site in presence of developers and testers.
Beta Testing: It is done by customer or external entities at there own site by there own people. In this case testers of development side may present or may not be.

This much for now. Will come up with new posts later.
Till then Happy Reading!!!

गुरुवार, फेब्रुवारी २३, २०१२

Ruby Require vs Load

ही पोस्ट दिग्गज हितेश रावल यांच्या personal blog Hello World मधून घेतली आहे.

Load व Require methods चा वापर अतिरिक्त source files चा समावेश करण्याकरिता होतो. या दोन्ही methods चा वापर तेव्हा केला जातो जेव्हा तुम्ही load करत असलेल्या library चे definition वेगळ्या file मध्ये केले गेलेले असते. हे दोन्ही methods Ruby च्या Kernel module मध्ये define केलेले आहेत.

Require: Require method तुम्हाला library load करून देतं आणि त्याला परत load होण्यापास्न रोखतं. जर तुम्ही तीच library परत load करायचा प्रयत्न केला तर Require method 'false' return करतं. या वरून आपल्याला कळते कि Require method एखादी library load झाली आहे कि नाही याची पाहणी करतं. तुम्हाला त्या library file च्या नावाचे '.rb' extension चा उल्लेख करायची गरज नाही.
उदाहरणार्थ,
'boot.rb' चा code:
require 'rubygems'

# Set up gems listed in the Gemfile.
ENV['BUNDLE_GEMFILE'] ||= File.expand_path('../../Gemfile', __FILE__)

require 'bundler/setup' if File.exists?(ENV['BUNDLE_GEMFILE'])

Load: Load method व Require method मध्ये बरेचसे साम्य आहे, पण Load हा एखादी library load झाली आहे कि नाही याची पाहणी करत नाही. याचा वापर तेव्हाच केला गेला पाहिजे जेव्हा module मध्ये वारंवार बदल केले जात अस्तील आणि आपल्याला एखादी library प्रत्येक वेळेला load करायची गरज पडत असेल. Load मध्ये तुम्हाला file extension चा उल्लेख करावा लागेल.
load(File.dirname(__FILE__) + "/schema.rb")

The original post can be viewed on Hitesh Rawal's personal blog Hello World! as Ruby Require vs Load

मंगळवार, फेब्रुवारी ०७, २०१२

Software testing: मुळ परिचय (Software testing: A Basic Intro)

जेव्हा आपण software testing चा विचार करतो तेव्हा २ प्रश्न आपल्या समोर उभे रहातात. Software म्हणजे  काय? आणि testing म्हणजे काय?

Software काय आहे? : Software हे एक operating information आहे जे आपले प्रत्येक दिवसाचे काम सुरळीत करते. आणि Testing म्हणजे एखाद्या system ला तपासणे व त्याचे अपेक्षित निष्पन्न व्यवस्थित पार पाडले जात आहे का? हे पडताळणे. System जे अपेक्षित आहे तेच करतय का? Software आणि Testing चं वरील वर्णन साधं आहे, अतिशय साधं. हे अजुन चांगल्या शब्दांमध्ये प्रचलित करू शकतो जे नामांकित शब्द्कोशातुन जमा केलेत.
Software: Computer Software किंवा Software म्हणजे computer programmes व संबंधित data चा संग्रह असतो, जे काही नियम computer ला आखून देत आणि सांगत की काय कधी करायच. हे programs तुमच्या computer च्या hard drives मध्ये जतन केले जातात.

Testing: टेस्टिंग ही अशी एक प्रोसेस आहे ज्यामध्ये एखाद्या item च्या features चे मुल्यांकन केले जाते व सध्याच्या आणि अपेक्षित परिणाम या मधला फरक शोधला जातो
मग जर तुम्ही दोन्ही terms एकत्र केले तर software testing बनते.
तर Software Testing म्हणजे Software ची नीट चाचणी करणे आणि ते अपेक्षितपणे चालत आहे का हे तपासून पाहणे. Software जसे पाहिजे तसे चालत आहे का?

Software testing: Software testing हे एक अशी process आहे ज्यामध्ये software ची सुरुवाती पासून शेवत पर्यंत workflow आणि functionality check केली जाते. ह्या मध्ये सर्वात जास्त software ची कमतरता तपासली  जाते ज्याला bugs असेही  म्हणतात. तसे बघितले तर functional किंवा non-functional testing द्वारे system break करण्याचा पूर्ण प्रयत्न केला जातो. ह्यालाच software ची quality वाढवण्याची तार्हा समजली जाते.

Objectives of testing:
  1. Software ची functionality सुरुवातीपासून शेवटपर्यंत check करायला.
  2. जसे चालायला पाहिजे तसे चलते का?
  3. तुटलेल्या links किंवा workflows शोधायला.
  4. System मधले bugs शोधायला.
  5. Positive तसेच negative ways शोधायला.
मग मनात अजुन एक प्रश्न येतो की कोण सांगत की software नी नक्की कसे चालायला पाहिजे? किंवा कुठल्या artifacts च्या विरुध software check करायला हवे? कुठल्या components च्या आधारे आपण म़त ठेवू शकतो की ते पाहिजे तसे चालत आहे?
ह्याचे उत्तर असे की baseline requirement दस्तावेज. आणि हे requirement दस्तावेज customer किंवा client कडून दिले जातात. जेव्हा हे दस्तावेज customer आपल्या service provider ला देतो तेव्हा ते draft format मध्ये असतात. हे analyze आणि review केल्या नंतर जर service provider company ला काही requirement बदलाविशी वाटली किंवा नाकबुल किंवा काही कमीपण, तर customer ला सांगितले जाते. अजुन काही विचाराननंतर requirement पक्की केली जाते. ह्याच पक्क्या केलेल्या requirement ला Base line Requirements असे बोलतात.

Characteristics of Requirement:
  1. स्पष्ट: काय, कधी, कसे असले अगदी स्पष्ट असले पाहिजे.
  2. पूर्ण: workflow ची पूर्ण cycle असायला पाहिजे. म्हणजेच त्याची सुरुवात तसेच शेवट दोन्ही असायला पाहिजेत.
  3. मोजता येण्यासारखे: एखाद्याला ते मोजण्यासारखे असावेत जसे बैंकचे खाते क्रमांक हयात फक्त अंक असले पाहिजेत आणि त्याना अक्षराने sort करता नाही आले पाहिजे.
  4. Test करता येण्यासारखे: अशा requirements ची testing करता येणे शक्य झाले पाहिजे. उदाहरनार्थ software ची testing OS वर, जे अजुनही आले नाही!!!  ह्यालाच future requirements असेही बोलतात आणि हे पूर्ण नाही करू शकत. म्हणून हे test plan च्या out of scope section मध्ये येते.
  5. Not conflicting: Two requirements परस्परविरोधी असू नयेत.
Product or Project Categories:
एखाद्या product आणि project ची criticality त्याच्या targeted आणि त्याचा वापर करणारया वर आधारित असता म्हणजेच कोणत्या लोकांचा गट आणि हे software त्याच्यावर काय परिणाम करणार आहे. एखाद्या software ची Product or Project समजुन जेव्हा testing केली जाते तेव्हा tester ला module च्या काही parts वर जोर द्यावा लागतो. ह्यालाच आपण categorized करू शकतो:
  1. Life Affecting software: उधारण : Medical Domain - जर कोंटा Software Medical Domain किवंह Healthcare domain करीता बनवण्यात आला आहे तर त्याचा effect प्रत्यक्ष किंवा अप्रत्यक्षपणे end users वर पडतो. म्हणून, अशा software चा अचूकपणा, गति आणि स्पष्टता यावर जास्त जोर देला जातो. म्हणून असे softwares मध्ये fail नाही झाले पाहिजेत.
  2. Money Affecting software : कोणतीही Share marketing sites, banking sites किवंह transactional related sites जे प्रत्यक्ष किंवा अप्रत्यक्षपणे आपल्या targeted customer च्या financial life ला affect करतात.
  3. Simulated testing : Space research किंवा असेच काही simulation करीता तयार करण्यात आलेले Software किंवा products(NASA मध्ये वापरण्यात येणारे Software).
  4. Others : इतर सर्व Software ह्या category मध्ये नामांकित करता येतात.
माझ्या पुढच्या post मध्ये मी software requirements , त्याचे प्रकार आणि अजुन काही testing च्या माहित बद्दल बोलेन. तो पर्यंत आनंदाने वाचा...!!!



Software testing: A Basic Intro


When we talk about the software testing, the word itself has two good questions: What is software? & what is testing?

So what is software? A Software is operating information used by computer to automate & easy going our day to day life. What is testing: Testing is to check any system & its desired expectations whether they are fulfilled or not. Is it doing what it is supposed to do? The above description for software & testing is very basic, just to keep simple. It can be defined in good words, collected from good dictionaries:

Software: Computer software, or just software, is a collection of computer programs and related data that provides the instructions for telling a computer what to do and how to do it. These programs are stored in hard drives of your computer.

Testing: Testing is the process of analyzing an item to detect the differences between existing and required conditions and to evaluate its features.
So if we combine the two terms, then it becomes software testing.
So software testing is test the software and check whether it works as expected or not. Is the software doing what it is supposed to do?

Software testing: Software testing is the process of checking the software’s end to end workflows and functionalities. It more about finding out the discrepancy in the software which is known as bugs.
It is more about breaking the system at some point, being functional or non functional. It is also known as an art of improving the quality of the software build.

Objectives of testing:
  1. To check s/w for its end to end functionality.
  2. Is it working what it is supposed to do?
  3. To find out the broken links or broken workflows.
  4. To find out the bugs in the system.
  5. To check it in positive as well as negative ways.
So, another question comes in mind, who decides that what should software do? Or against what artifacts we should check the software? What are the components on which we can decide that it working as desired?
Answer to all the questions is Baseline requirement docs. And these requirement docs are provided by our customer or by clients. When a customer provides a requirement doc to its service provider, it is in draft format. After analyzing them and reviewing them, if the service provider company founds any requirements to be changed or contradictory or any discrepancy, is reported to customer. After few more rounds of discussions, the requirements are finalized. These finalized requirements are known as Base line Requirements. Characteristics of Requirement:
  1. Clear: Should be very clear that what, when, how is required.
  2. Complete: There should be complete cycle of any workflow. It should have some start point as well as end point.
  3. Measureable: One should be able to measure them like Account number in a bank can only be numeric values and cannot be sorted alphabetically.
  4. Testable: Testing of these requirements should be possible. Eg. Testing the s/w on an OS, which is not launched yet!!. These are also known as future requirements and cannot be fulfilled. So it comes under Out of Scope section in Test Plan Document.
  5. Not conflicting: Two requirements should not be conflicting.

Product or Project Categories:
The criticality of any product or project can be decided by the targeted end user i.e. who is group of end user and how this software is going to affect them. While testing any software as Product or Project, tester needs to emphasis on some part or module of the software. This can categorized as: 
  1. Life Affecting software: Eg Medical domain. If any software is build in medical domain or healthcare domain, then directly or indirectly, life of the end user will be affected. So the accuracy, speed, clarity in the results is more emphasized. Also, the failure of these s/w is not accepted.
  2. Money Affecting software: Any Share marketing sites, banking sites, or other transactional related sites, which will directly or indirectly affect the finances of the targeted customer.
  3. Simulated testing: Software or products built for Space research, or any such kind of simulation. (S/w used by NASA)
  4. Others: rest all the s/w can be classified in this category.

In the next post I will talk more on software requirements, its types and more about the testing
Till that Happy Reading….:) !!!