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 |
· 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