Monday, 23 February 2015

Software testing FAQs


Globalization Vs Localization Testing

 


Topic
Globalization Testing
Localization Testing
Difference between 
Globalized and
 Localized
 Testing
1. Globalization testing
 is to ensure that 
application can function
 in any culture 
or locale (language, 
territory and code page).
 
1. Localization testing 
is the software testing 
process for checking the 
localized version of a 
product for that particular 
culture or locale settings. 
 The areas affected 
by localization testing
 are UI and content.
 
1. Globalization testing
 checks proper 
functionality of the
 product, using every 
type of international 
input possible. 
It ensures that without 
breaking functionality
 the code can handle all 
international support.
For example L18N, is 
the process of planning 
and implementing products
 and services so that 
they can easily be adapted
 to specific languages 
and culture.
1. Localizing testing is 
done to ensure the quality
 of a product for a particular
 target or locale. 
For example, for French
 users the testing product 
is denoted as L10N.
 
1. In a globalized product, 
code is separated
 from the messages or
 information. With the
 help of globalization, it 
enables software to be
 used with different
 languages without having
 to redesign the complete
 software.

1. This is not necessary in
 a Localized product
 
1. Globalization focuses 
your applications
 capabilities on users as 
generic user base.

1. Localization focuses 
onsubset of users in a 
given culture or locale. 
Advantages
1. Separation of testers from
 translators and
 engineers, ensuring a 
thorough and impartial
 approach.

1. It helps reduce time 
for testing since its done
 for just on locale

1.  Formalized bug reporting, 
   allowing to
1. It reduces overall
 testing and support 
costs

Things to be 
taken care
 before Testing
1. Detect potential problems 
in application
 design that could inhibit 
globalization

1. Validation of all 
application resources

1. It ensures that without
 breaking functionality
 code can handle all 
international support

1. Verification of linguistic
  accuracy and
 resource attributes. 
Check Typographical
 errors

1. Verification of linguistic
 accuracy and resource
 attributes Compatibility 
tests of
1. Consistency checking
 of printed 
documentation, messages,
 command key sequence
 etc.

1. Compatibility tests of
 hardware and application
 according to the product’s
 target region

1. Confirmation of input 
and display environment 
standards , adherence to 
system. Usability of User
 Interface




Verification v/s Validation in a Software Testing 



Verification
Validation
 · Verifying process includes checking
documents, design,
code and program


 
 · It is a dynamic mechanism of testing and  validating
the actual product


 
· It does not involve executing the code · It always involves executing the code

 
 · Verification uses methods like reviews,
walkthroughs, inspections and desk- checking etc.

 · It uses methods like black
box testing,white box
 testing and non-functional
 testing
 ·  Whether the software conforms to specification is checked

 · It checks whether software
 meets the requirements and
expectations of customer
 · It finds bugs early in the development cycle

 · It can find bugs that the
verification process can not
catch
 · Target is application and software architecture,
specification, complete
design, high level and data base design etc.
· Target is actual product

 · QA team does verification and mak
e sure that the software is as per the requirement
in the SRS document.

 · With the involvement of
testing team validation is
executed on software code.

· It comes before validation

· It comes after verification





Example of verification and validation· Consider following specificationA clickable button with name Submet · Verification would be check the design doc and correcting the spelling mistake.· Otherwise development team will create button like


 

· So new specification is A clickable button with name Submit · Once the code is ready, Validation is done. A Validation test found –





· Owing to Validation testing, the development team will make the submit button clickable


Test Plan V/s Test Strategy  Test PlanTest Strategy · A test plan for software project can be defined as a document that defines the scope, objective, approach and emphasis on a software testing effort· Test strategy is a set of guidelines that explains test design and determines how testing needs to be done · Components of Test plan include- Test plan id, featureto be tested, test techniques, testing tasks, features pass or fail criteria, test deliverables, responsibilities, and schedule, etc.· Components of Test strategy includes- objectives and scope, documentation formats, test processes, team reporting structure, client communication strategy, etc. · Test plan is carried out by a testing manager or lead that describes how to test, when to test, who will test and what to test· A test strategy is carried out by the project manager. It says what type of technique to follow and which module to test  · Test plan narrates about the specification · Test strategy narrates about the general approaches · Test plan can change· Test strategy cannot be changed · Test planning is done to determine possible issues and dependencies in order to identify the risks. · It is a long-term plan of action.You can abstract information that is not project specific and put it into test approach · A test plan exists individually· In smaller project, test strategy is often found as a section of a test plan  · It is defined at project level· It is set at organization level and can be used by multiple projects

Quality Assurance Vs Quality Control 
Quality Assurance (QA)Quality Control (QC) · It is a procedure that focuses on providing assurance that quality request will be achieved· It is a procedure that focuses on fulfilling the quality request · QA aims to prevent the defect· QC aims to identify and fix defects · It is a method to manage the quality- Verification· It is a method to verify the quality-Validation · It does not involve executing the program· It always involves executing a program · It's a Preventive technique· It's a Corrective technique · It's a Proactive measure· It's a Reactive measure · It is the procedure to create the deliverables· It is the procedure to verify that deliverables · QA involves in full software development life cycle· QC involves in full software testing life cycle · In order to meet the customer requirements QA defines standards and methodologies· QC confirms that the standards are followed while working on the product · It is performed before Quality Control· It is performed only after QA activity is done · It is a Low Level Activity, it can identify an error and mistakes which QC cannot· It is a High-Level Activity, it can identify an error that QA cannot · Its main motive is to prevent defects in the system. It is less time-consuming activity· Its main motive is to identify defects or bugs in the system. It is more time-consuming activity · QA ensures that everything is executed in the right way, and that is why it falls under verification activity· QC ensures that whatever we have done is as per the requirement, and that is why it falls under validation activity · It requires involvement of the whole team· It requires involvement of Testing team · Statistical technique applied on QA is known as SPC or Statistical Process Control (SPC)· Statistical technique applied on QC is known as SQC or Statistical Quality Control


Defect Density: Software Testing Terminology Defect Density is the number of defects confirmed in software/module during a specific period of operation or development divided by the size of the software/module. It enables one to decide if a piece of software is ready to be released. Defect density is counted per thousand lines of code also known as KLOC. 
Formula to measure Defect Density: · Defect Density = Defect count/ size of the release Size of release can be measured in terms of line of code (LoC). 



  Standard for defect densityHowever, there is no fixed standard for defect density, studies suggest that one defect per thousand lines of code is generally considered as a sign of good project quality. Factors that affects the defect density · Code complexity · The type of defects taken into account for the calculation · Time duration which is considered for defect density calculation Developer or Tester skills    Advantages of defect density· It helps measure the testing effectiveness · It helps to differentiate defects in components/software modules · It is useful in identifying the areas for correction or improvement · It is useful in pointing towards high-risk components · It helps in identifying the training needs to various resources · It can be helpful in estimating the testing and rework due to bugs · It can estimate the remaining defects in the software · Before the release we can determine whether our testing is sufficient · We can ensure database with a standard defect density 

Defect Severity in Software Testing In software testing, defect severity can be defined as the degree of impact a defect has on the development or operation of a component application being tested. Higher effect on the system functionality will lead to the assignment of higher severity to the bug. Quality Assurance engineer usually determines the severity level of defect  Defect severity can be categorized into four class · Critical: This defect indicates complete shut-down of the process, nothing can proceed further · Major: It is highly severe defect and collapse the system. However, certain parts of the system remains functional · Medium: It cause some undesirable behavior, but the system is still functional · Low: It won't cause any major break-down of the system 




Tips for determining Severity of a Defect · Decide the frequeny of occurence: In some cases, if the occurrence of a minor-defect is frequent in the code, it can be more severe. So from user's perspective, it is more serious even though it is a minor defect. · Isolate the defect: Isolating the defect can help to find out its severity of impact. 
A software system can have aA very low severity with a high priority: A logo error for any shipment website, can be of low severity as it not going to affect the functionality of the website but can be of high priority as you don't want any further shipment to proceed with wrong logo. · A very high severity with a low priority: Likewise, for flight operating website, defect in reservation functionality may be of high severity but can be a low priority as it can be scheduled to release in a next cycle.

No comments:

Post a Comment