Software Quality Assurance

(1) A planned and systematic pattern of all actions necessary to provide adequate confidence that an item
or product conforms to established technical requirements.
(2) A set of activities designed to evaluate the process by which products are developed or manufactured.
What's difference between client/server and Web Application ?
Client/server based is any application architecture where one server application and one or many client
applications are involved lie your mail server and !" outloo #$press% it can be a web application as well%
where the &eb Application is a ind of client server application that is hosted on the web server and
accessed over the internet or interanet. 'here are lots of things that differs between testing of the two
type above and cann(t be posted in one post but you can loo into the data flow% communication and
servside variable lie session and security etc
Software Quality Assurance Activities
) Application of 'echnical !ethods (#mploying proper methods and tools for developing software)
) Conduct of *ormal 'echnical +eview (*'+)
) 'esting of "oftware
) #nforcement of "tandards (Customer imposed standards or management imposed standards)
) Control of Change (Assess the need for change% document the change)
) !easurement ("oftware !etrics to measure the quality% quantifiable)
) +ecords ,eeping and +ecording (-ocumentation% reviewed% change control etc. i.e. benefits of docs).
What's the difference between STATIC TESTI! and "#A$IC TESTI!?
Answer1.
-ynamic testing. +equired program to be e$ecuted
static testing. -oes not involve program e$ecution
'he program is run on some test cases / results of the program0s performance are e$amined to chec
whether the program operated as e$pected
#.g. Compiler tas such as "ynta$ / type checing% symbolic e$ecution% program proving% data flow
analysis% control flow analysis
Answer2.
"tatic 'esting. 1erification performed with out e$ecuting the system code
-ynamic 'esting. 1erification and validation performed by e$ecuting the system code
Software Testin%
"oftware testing is a critical component of the software engineering process. 2t is an element of software
quality assurance and can be described as a process of running a program in such a manner as to uncover
any errors. 'his process% while seen by some as tedious% tiresome and unnecessary% plays a vital role in
software development.
'esting involves operation of a system or application under controlled conditions and evaluating the results
(eg% (if the user is in interface A of the application while using hardware 3% and does C% then - should
happen(). 'he controlled conditions should include both normal and abnormal conditions. 'esting should
intentionally attempt to mae things go wrong to determine if things happen when they shouldn(t or
things don(t happen when they should. 2t is oriented to (detection(.
4rgani5ations vary considerably in how they assign responsibility for 6A and testing. "ometimes they(re
the combined responsibility of one group or individual. Also common are pro7ect teams that include a mi$
of testers and developers who wor closely together% with overall 6A processes monitored by pro7ect
managers. 2t will depend on what best fits an organi5ation(s si5e and business structure.
What's difference between QA/testin%
'he quality assurance
process is a process for providing adequate assurance that the software products and processes in the
product life cycle conform to their specific requirements and adhere to their established plans.8
'he purpose of "oftware 6uality Assurance is to provide management with appropriate visibility into the
process being used by the software pro7ect and of the products being built
What blac& bo' testin% types can you tell (e about?
3lac bo$ testing is functional testing% not based on any nowledge of internal software design or code.
3lac bo$ testing is based on requirements and functionality. *unctional testing is also a blac9bo$ type of
testing geared to functional requirements of an application.
"ystem testing is also a blac bo$ type of testing. Acceptance testing is also a blac bo$ type of testing.
*unctional testing is also a blac bo$ type of testing. Closed bo$ testing is also a blac bo$ type of testing.
2ntegration testing is also a blac bo$ type of testing.
What is software testin% (ethodolo%y?
4ne software testing methodology is the use a three step process of...
1. Creating a test strategy:
2. Creating a test plan/design: and
;. #$ecuting tests. 'his methodology can be used and molded to your organi5ation(s needs. +ob -avis
believes that using this methodology is important in the development and ongoing maintenance of his
clients( applications.
What)s the difference between QA and testin%?
'#"'2<= means >6uality Control?: and
6@AA2'B C4<'+4A measures the quality of a product: while
6@AA2'B A""@+A<C# measures the quality of processes used to create a quality product.
Why Testin% CA*T Ensure Quality
'esting in itself cannot ensure the quality of software. All testing can do is give you a certain level of
assurance (confidence) in the software. 4n its own% the only thing that testing proves is that under specific
controlled conditions% the software functioned as e$pected by the test cases e$ecuted.
+ow to find all the ,u%s durin% first round of Testin%?
Answer1.
2 understand the problems you are facing. 2 was involved with a web9based C+ system that was
encountering the same problems. &hat 2 ended up doing was going bac over a few release cycles and
analy5ing the types of defects found and when (in the release cycle including the various testing cycles)
they were found. 2 started to notice a distinct trend in certain areas.
*or each defect type% 2 started looing into the possibility if it could have been caught in the prior phase
(lots of things were being found in the "ystems test phase that should have been caught earlier). 2f so%
why wasn(t it caughtD Could it have been caught even earlier (say via a peer review)D 2f so% why notD 'his
led me to start e$amining the various processes and found a definite problem with peer reviews (not very
thorough 2* they were even being done) and with the testing process (not rigorous enough). &e wored
with the customer and fols doing the testing to start educating them and improving the processes. 'he
result was the number of defects found in the latter test stages ("ystem test for e$ample) were cut by
over halfE 2t was getting harder to find problems with the product as they were discovering them earlier in
the process 99 saving time / moneyE
Answer2.
'here could be several reasons for not catching a showstopper in the first or second build/rev. A found
defect could either functionally or physiologically mas a second or third defect. *unctionally the thread or
path to the second defect could have been boen or rerouted to another path or physiologically the tester
who found the first defect nows the app must go bac and be rewritten so he/she procedes halfheartedly
on and misses the second one. 2(ve seen both cases. 2t is difficult to eep testing on a nown defective
app. 'he testers seem to lose interest nowing that what effort they put in to test it% will have to be
redone on the ne$t iteration. 'his will test your metal as a lead to get them to follow through and maintain
a professional attitude.
Answer;.
'he best way is to prevent bugs in the first place. Also testing doesn(t fi$ or prevent bugs. 2t 7ust provides
information. Applying this information to your situation is the important part.
'he other thing that you may be encountering is that testing tends to be e$ploratory in nature. Bou have
stated that these are e$isting bugs% but not stated whether tests already e$isted for these bugs.
3ugs in early cycles inhibit e$ploration. Additionally% a tester(s understanding of the application and its
relationships and interactions will improve with time and thus more (interesting( bugs tend to be found in
later iterations as testers e$pand their e$ploration (ie. thin of new tests).
<o matter how much time you have to read through the documents and inspect artefacts% seeing the
actual application is going to trigger new thoughts% and thus introduce previously unthought of tests.
#$posure to the application will trigger new thoughts as well% thus the longer your testing goes% the more
new tests (and potential bugs) are going to be found. 2terative development is a good way to counter this%
as testers get to see something physical earlier% but this issue will always e$ist to some degree as the
passing of time% and e$ploration of the application allow new tests to be thought of at inconvenient
moments.
Is re%ression testin% perfor(ed (anually?
'he answer to this question depends on the initial testing approach. 2f the initial testing approach was
manual testing% then the regression testing is usually performed manually. Conversely% if the initial testing
approach was automated testing% then the regression testing is usually performed by automated testing.
+ow to choose which defect to re(ove in -...... defects? /because It will ta&e too (uch
resources in order to re(ove the( all01
Answe1.
Are you the programmer who has to fi$ them% the pro7ect manager who has to supervise the
programmers% the change control team that decides which areas are too high ris to impact% the
staeholder9user whose organi5ation pays for the damage caused by the defects or the testerD
'he tester does not choose which defects to fi$.
'he tester helps ensure that the people who do choose% mae a well9informed choice.
'esters should provide data to indicate the )severity) of bugs% but the pro7ect manager or the
development team do the prioriti5ation.
&hen 2 say 8indicate the severity8% 2 don(t 7ust mean writing "; on a piece of paper. 'est groups often do
follow9up tests to assess how serious a failure is and how broad the range of failure9triggering conditions.
Friority depends on a wide range of factors% including code9change ris% difficulty/time to complete the
change% which staeholders are affected by the bug% the other commitments being handled by the person
most nowledgeable about fi$ing a certain bug% etc. !any of these factors are not within the nowledge of
most test groups.
Answe2.
As a tester we don(t fi$ the defects but we surely can prioriti5e them once detected. 2n our org we assign
severity level to the defects depending upon their influence on other parts of products. 2f a defect doesnt
allow you to go ahead and test test the product% it is critical one so it has to be fi$ed A"AF. &e have G
levels as
19critical
29Cigh
;9!edium
H9Aow
G9Cosmetic
-ev can group all the critical ones and tae them to fi$ before any other defect.
Answer;.
Friority/"everity F1 F2 F;
"1
"2
";
=enerally the defects are classified in aboveshown grid. #very organi5ation / software has some target of
fi$ing the bugs.
#$ample 9
F1"1 9I JKL of the bugs reported should be fi$ed.
F;"; 9I GL of the bugs reported may be fi$ed. +est are taen in letter service pacs or versions.
'hus the organi5ation should decide its target and act accordingly.
3asically bugfree software is not possible.
AnswerH.
2deally% the customer should assign priorities to their requirements. 'hey tend to resist this. 4n a large%
multi9year pro7ect 2 7ust completed% 2 would often (in the lac of customer guidelines) rely on my
nowledge of the application and the potential downstream impacts in the modeled business process to
prioriti5e defects.
2f the customer doesn(t then 2 fell the test organi5ation should based on ris or other% similar
considerations.
'he quality of the software varies widely from system to system. "ome common quality attributes are
stability% usability% reliability% portability% and maintainability.
What is software 2uality?
What are the five di(ensions of the 3is&s?
"chedule. @nrealistic schedules% e$clusion of certain activities when chaling out a schedule etc. could be
deterrents to pro7ect delivery on time. @nstable communication lin can be considered as a probable ris if
testing is carried out from a remote location.
Client. Ambiguous requirements definition% clarifications on issues not being readily available% frequent
changes to the requirements etc. could cause chaos during pro7ect e$ecution.
Cuman +esources. <on9availability of sufficient resources with the sill level e$pected in the pro7ect are
not available: Attrition of resources 9 Appropriate training schedules must be planned for resources to
balance the nowledge level to be at par with resources quitting. @nderestimating the training effort may
have an impact in the pro7ect delivery.
"ystem +esources. <on9availability of /delay in procuring all critical computer resources either hardware
and software tools or licenses for software will have an adverse impact.
6uality. Compound factors lie lac of resources along with a tight delivery schedule and frequent changes
to requirements will have an impact on the quality of the product tested.
What is %ood code?
A good code is code that wors% is free of bugs and is readable and maintainable. 4rgani5ations usually
have coding standards all developers should adhere to% but every programmer and software engineer has
different ideas about what is best and what are too many or too few rules. &e need to eep in mind that
e$cessive use of rules can stifle both productivity and creativity. Feer reviews and code analysis tools can
be used to chec for problems and enforce standards.
+ow do you perfor( inte%ration testin%?
'o perform integration testing% first% all unit testing has to be completed. @pon completion of unit testing%
integration testing begins. 2ntegration testing is blac bo$ testing. 'he purpose of integration testing is to
ensure distinct components of the application still wor in accordance to customer requirements. 'est
cases are developed with the e$press purpose of e$ercising the interfaces between the components. 'his
activity is carried out by the test team.
2ntegration testing is considered complete% when actual results and e$pected results are either in line or
differences are e$plainable% or acceptable% based on client input.
Why bac&4end testin% is re2uired5 if we are %oin% to chec& the front4end0 What errros/bu%s we
are (issin% out by not doin% bac&4end testin%0
Why we need to do unit testin%5 if all the features are bein% tested in Syste( testin%0 What
e'tra thin%s are tested in unit testin%5 which can not be tested in Syste( testin%0
Answer1.
Assume that you(re thining client9server or web. 2f you test the application on the front end only you can
see if the data was stored and retrievd correctly. Bou can(t see if the servers are in an error state or not.
many server processes are monitored by another process. 2f they crash% they are restarted. Bou can(t see
that without looing at it.
'he data may not be stored correctly either but the front end may have cached data lying around and it
will use that instead. 'he least you should be doing is verifying the data as stored in the database.
2t is easier to test data being transferred on the boundaries and see the results of those transactions when
you can set the data in a driver.
Answer2.
3ac9#nd testing . 3asically the requirement of this testing depends on ur pro7ect. lie "ay if ur pro7ect
is .'icet booing system%*ront end u will provided with an 2nterface % where u can boo the ticet by
giving the appropriate details ( Aie Flace to go% and 'ime when u wanna go etc..). 2t will have a -ata
storage system (-atabase or MA sheet etc) which is a 3ac end for storing details entered by the user.
After submitting the details %@ might have provided with a correct acnowledgement.3ut in bac end % the
details might not updated correctly in -atabase beco5 of wrong logic development. 'hen that will cause a
ma7or problem.
and regarding @nit level testing and "ystem testing @nit level testing is for testing the basic checs
whether the application is woring fyn with the basic requirements.'his will be done by developers before
delivering to the 6A.2n "ystem testing % 2n addition to the unit checs %u will be performing all the checs (
all possible integrated checs which required) .3asically this will be carried out by tester
Answer;.
#ver heard about divide and conquer tactic D 2t is a same method applied in bacend and frontend testing.
A good bac end test will help minimi5e the burden of frontend test.
Another point is you can test the bacend while develope the frontend. A true pararelism could be achived.
3acend testing has another problem which must addressed before front end could use it. 'he problem is
concurency. 3uilding a scenario to test concurency is formidable tas.
A comple$ thing is hard to test. 'o create such scenarios will mae you unsure which test you already
done and which you haven(t. &hat we need is an effective methods to test our application. 'he simplest
method i now is using divide and conquer.
AnswerH.
A wide range of errors are hard to see if you don(t see the code. *or e$ample% there are many
optimi5ations in programs that treat special cases. 2f you don(t see the special case% you don(t test the
optimi5ation. Also% a substantial portion of most programs is error handling. !ost programmers anticipate
more errors than most testers.
Frogrammers find and fi$ the vast ma7ority of their own bugs. 'his is cheaper% because there is no
communication overhead% faster because there is no delay from tester9reporter to programmer% and more
effective because the programmer is liely to fi$ what she finds% and she is liely to now the cause of the
problems she sees. Also% the rapid feedbac gives the programmer information about the weanesses in
her programming that can help her write better code.
!any tests 99 most boundary tests 99 are done at the system level primarily because we don(t trust that
they were done at the unit level. 'hey are wasteful and tedious at the system level. 2(d rather see them
properly done and properly automated in a suite of programmer tests.
What is Software 6Quality7?
6uality software is reasonably bug9free% delivered on time and within budget% meets requirements and/or
e$pectations% and is maintainable.
Cowever% quality is a sub7ective term. 2t will depend on who the Ncustomer0 is and their overall influence in
the scheme of things. A wide9angle view of the Ncustomers0 of a software development pro7ect might
include end9users% customer acceptance testers% customer contract officers% customer management% the
development organisation0s management/accountants/testers/salespeople% future software maintenance
engineers% stocholders% maga5ine reviewers% etc. #ach type of Ncustomer0 will have their own view on
Nquality0 9 the accounting department might define quality in terms of profits while an end9user might
define quality as user9friendly and bug9free.
What is retestin%?
Answer1.
+etesting is usually equated with regression testing (see above) but it is different in that is follows a
specific fi$99such as a bug fi$99and is very narrow in focus (as opposed to testing entire application again
in a regression test). A product should never be released after any change has been applied to the code%
with only retesting of the bug fi$% and without a regression test.
Answer2.
1. +e9testing is the testing for a specific bug after it has been fi$ed.(one given by your definition).
2. +e9testing can be one which is done for a bug which was raised by 6A but could not be found or
confirmed by -evelopment and has been re7ected. "o 6A does a re9test to mae sure the bug still e$ists
and again assigns it bac to them.
when entire pro7ect is tested / client have some doubts about the quality of testing% +e9'esting can be
called. 2t can also be testing the same application again for better 6uality.
Answer;.
+egression 'esting is% the selective retesting of a system that has been modified to ensure that any bugs
have been fi$ed and that no other previously woring functions have failed as a result of the reparations
and that newly added features have not created problems with previous versions of the software. Also
referred to as verification testing
2t is important to determine whether in a given set of circumstances a particular series of tests has been
failed. 'he supplier may want to submit the software for re9testing. 'he contract should deal with the
parameters for retests% including (1) will test program which are doomed to failure be allowed to finish
early% or must they be completed in their entiretyD (2) when can% or must% the supplier submit his software
for retestingD% and (;) how many times can the supplier fail tests and submit software for retesting O is
this based on time spent% or the number of attemptsD A well drawn contract will grant the customer
options in the event of failure of acceptance tests% and these options may vary depending on how many
attempts the supplier has made to achieve acceptance.
"o the conclusion is retesting is more or less regression testing. !ore appropriately retesting is a part of
regression testing.
AnswerH.
+e9testing is simply e$ecuting the test plan another time. 'he client may request a re9test for any reason
9 most liely is that the testers did not properly e$ecute the scripts% poor documentation of test results% or
the client may not be comfortable with the results.
2(ve performed re9tests when the developer inserted unauthori5ed code changes% or did not document
changes.
+egression testing is the e$ecution of test cases 8not impacted8 by the specific pro7ect. 2 am currently
woring on testing of a system with poor system documentation (and no user documentation) so our
regression testing must be e$tensive.
AnswerG.
) 6A gets a bug fi$% and has to verify that the bug is fi$ed. Bou might want to chec a few things that are
a >gut feel? if you want to and get away by calling it retesting% but not the entire function / module /
product. ) -evelopment +efuses a bug on the basis of it being ><on +eproducible?% then retesting%
preferably in the presence of the -eveloper% is needed.
+ow to establish QA 8rocess in an or%ani9ation?
1.C@++#<' "2'@A'24<
'he first thing you should do is to put what you currently do in a piece of paper in some sort of a flowchart
diagram. 'his will allow you to analy5e what is being currently done.
2.-#1#A4F!#<' F+4C#"" "'A=#
4nce you have the 8big picture8% you have to be aware of the current status of your development pro7ect
or pro7ects. 'he processes you select will vary depending if you are in early stages of developing a new
application (i.e.. developing a version 1.K)% or maintaining an e$isting application (i.e.. woring on release
P.Q.1).
;. F+24+2'2#"
'he ne$t thing you need to do is identify the priorities of your pro7ect% for e$ample. 9 Compliance with
industry standards 9 1alidation of new functionality (new =@2s% etc) 9 "ecurity 9 Capacity Flanning ( Bou
should see 8#ffective !ethods for "oftware 'esting8 for more info). !ae a list of the priorities% and then
assign them values of (C)igh% (!)edium and (A)ow.
H. '#"'2<= 'BF#"
4nce you are aware of the priorities% focus on the Cigh first% then !edium% and finally evaluate whether
the Aow ones need immediate attention.
3ased on this% you need to select those 'esting 'ypes that will provide coverage for your priorities.
#$ample of testing types.
9 *unctional 'esting
9 2ntegration 'esting
9 "ystem 'esting
9 "ystem9to9"ystem 'esting (for testing interfaces)
9 +egression 'esting
9 Aoad 'esting
9 Ferformance 'esting
9 "tress 'esting
#tc.
G. &+2'# A '#"' FAA<
4nce you have determined your needs% the simplest way to document and implement your process is to
elaborate a 8'est Flan8 for every effort that you are engaged into (i.e.. for every release).
*or this you can use generic 'est Flan templates available in the web that will help you brainstorm and
define the scope of your testing.
9 "cope of 'esting (defects% functionality% and what will be and will not be tested).
9 'esting 'ypes (*unctional% +egression% etc).
9 +esponsible people
9 +equirements traceability matri$ (match test cases with requirements to ensure coverage)
9 -efect tracing
9 'est Cases
-@+2<= A<- F4"'9'#"'2<= AC'212'2#"
!ae sure you eep trac of the completion of your testing activities% the defects found% and that you
comply with an e$it criteria prior to moving to the ne$t stage in testing (i.e. @ser Acceptance 'esting% then
Froduction +elease).
!ae sure you have a mechanism for.
9 +eporting
9 'est tracing
What is software testin%?
1) "oftware testing is a process that identifies the correctness% completenes% and quality of software.
Actually% testing cannot establish the correctness of software. 2t can find defects% but cannot prove there
are no defects.
2) 2t is a systematic analysis of the software to see whether it has performed to specified requirements.
&hat software testing does is to uncover errors however it does not tell us that errors are still not present.
Any reco((endation for esti(ation how (any bu%s the custo(er will find till %old release?
Answer1.
2f you tae the total number of bugs in the application and subtract the number of bugs you found% the
difference will be the ma$imum number of bugs the customer can find.
"eriously% 2 doubt you will find any sort of calculations or formula that can answer your question with
much accuracy. 2f you could refernce a previous application release% it might give you a rough idea. 'he
best thing to do is insure your test coverage is as good as you can mae it then hope you(ve found the
ones the customer might find.
+emember "oftware testing is +is !anagementE
Answer2.
*or doing estimation .
1.)*ind out the Coverage during testing of ur software and then estimate eeping in mind RK92K principle.
2.)Bou can also loo at the deepening of your test cases e.g. how much unit level testing and how much
life cycle teting have you performed (3elieve that most of the bugs from customer comes due to real use
of lifecycle in the software)
;.)Bou can also refer the defect density from earlier releases of the same product line.
by doing these evaluation you can find out the probability of bugs at an appro$imately optimum
estimation.
Answer;.
Bou can loo at the customer issues mapping from previous release (2f you have the same product line) to
the current release %'his is the best way of finding estimation for gold release of migration of any
product."econdly% till gold release most of the issues comes from various combination of installation
testing lie cross9platform%i1R issues%Customi5ation%upgradation and migration.
"o %these can be taen as a parameter and then can estimation be completed.
When the build co(es to the QA tea(5 what are the para(eters to be ta&en for consideration
to re:ect the build upfront without co((ittin% for testin% ?
Answer1.
Agree with +/- a set of tests that if one fails you can re7ect the build. 2 usually have some build
verification tests that 7ust mae sure the build is stable and the ma7or functionality is woring.
'hen if one test fails you can re7ect the build.
Answer2.
'he only way to legitimately re7ect a build is if the entrance criteria have not been met. 'hat means that
the entrance criteria to the test phase have been defined and agreed upon up front. 'his should be
standard for all builds for all products. #ntrance criteria could include.
9 'urn9over documentation is complete
9 All unit testing has been successfully completed and @/' cases are documented in turn9over
9 All e$pected software components have been turned9over (staged)
9 All walthroughs and inspections are complete
9 Change requests have been updated to correct status
9 Configuration !anagement and build information is provided% and correct% in turn9over
'he only way we could really re7ect a build without any testing% would be a failure of the turn9over
procedure. 'here may% but shouldn(t be% politics involved. 'he only way the test phase can proceed is for
the test team to have all components required to perform successful testing. Bou will have to define
entrance (and e$it) criteria for each phase of the "-AC. 'his is an effort to be taen together by the whole
development team. -evelopments entrance criteria would include signed requirements% CA- doc% etc.
Caving this criteria pre9established sets everyone up for success
Answer;.
'he primary reason to re7ect a build is that it is untestable% or if the testing would be considered invalid.
*or e$ample% suppose someone gave you a 8bad build8 in which several of the wrong files had been
loaded. 4nce you now it contains the wrong versions% most groups thin there is no point continuing
testing of that build.
#very reason for re7ecting a build beyond this is reached by agreement. *or e$ample% if you set a build
verification test and the program fails it% the agreement in your company might be to re7ect the program
from testing. "ome 31's are designed to include relatively few tests% and those of core functionality.
*ailure of any of these tests might reflect fundamental instability. Cowever% several test groups include a
lot of additional tests% and failure of these might not be grounds for re7ecting a build.
2n some companies% there are firm entry criteria to testing. !any companies pay lipservice to entry criteria
but start testing the code whether the entry criteria are met or not. <either of these is right or wrong99it(s
the culture of the company. 3e sure of your corporate culture before re7ecting a build.
AnswerH.
=enerally a company would have set some sort of minimum goals/criteria that a build needs to satisfy 9 if
it satisfies this 9 it can be accepted else it has to be re7ected
*or eg.
<il 9 high priority bugs
2 9 !edium Friority bugs
"anity test or !inimum acceptance and 3asic acceptance should pass 'he reasons for the new build 9 say
a change to a specific case 9 this should pass <ot able to proceed 9 non 9 testability or even some more
which is in relation to the new build or the product 2f the above criterias don(t pass then the build could be
re7ected.
What is software testin%?
"oftware testing is more than 7ust error detection:
'esting software is operating the software under controlled conditions% to (1) verify that it behaves >as
specified?: (2) to detect errors% and (;) to validate that what has been specified is what the user actually
wanted.
1erification is the checing or testing of items% including software% for conformance and consistency by
evaluating the results against pre9specified requirements. S1erification. Are we building the system rightDT
#rror -etection. 'esting should intentionally attempt to mae things go wrong to determine if things
happen when they shouldn0t or things don0t happen when they should.
1alidation loos at the system correctness U i.e. is the process of checing that what has been specified is
what the user actually wanted. S1alidation. Are we building the right systemDT
2n other words% validation checs to see if we are building what the customer wants/needs% and
verification checs to see if we are building that system correctly. 3oth verification and validation are
necessary% but different components of any testing activity.
'he definition of testing according to the A<"2/2### 1KGJ standard is that testing is the process of
analysing a software item to detect the differences between e$isting and required conditions (that is
defects/errors/bugs) and to evaluate the features of the software item.
+emember. 'he purpose of testing is verification% validation and error detection in order to find problems
U and the purpose of finding those problems is to get them fi$ed.
What is the testin% lifecycle?
'here is no standard% but it consists of.
'est Flanning ('est "trategy% 'est Flan(s)% 'est 3ed Creation)
'est -evelopment ('est Frocedures% 'est "cenarios% 'est Cases)
'est #$ecution
+esult Analysis (compare #$pected to Actual results)
-efect 'racing
+eporting
+ow to validate data?
2 assume that you are doing #'A (e$tract% transform% load) and cleaning. 2f my assumetion is correct then
1. you are builing data warehouse/ data minning
2. you as right question to wrong place
What is 2uality?
6uality software is software that is reasonably bug9free% delivered on time and within budget% meets
requirements and e$pectations and is maintainable. Cowever% quality is a sub7ective term. 6uality depends
on who the customer is and their overall influence in the scheme of things. Customers of a software
development pro7ect include end9users% customer acceptance test engineers% testers% customer contract
officers% customer management% the development organi5ation(s management% test engineers% testers%
salespeople% software engineers% stocholders and accountants. #ach type of customer will have his or her
own slant on quality. 'he accounting department might define quality in terms of profits% while an end9
user might define quality as user friendly and bug free.
what is ,ench(ar&?
Cow it is lined with "-AC ("oftware -evelopment Aife Cycle)D
or "-AC and 3enchmar are two unrelated things.D
&hat are the compoments of 3enchmarD
2n "oftware 'esting where 3enchmar fits inD
A 3enchmar is a standard to measure against. 2f you benchmar an application% all future application
changes will be tested and compared against the benchmared application.
Which of the followin% State(ents about %erneratin% test cases is false?
1. 'est cases may contain multiple valid conditions
2. 'est cases may contain multiple invalid conditions
;. 'est cases may contain both valid and invalid conditions
H. 'est cases may contain more than 1 step.
G. test cases should contain #$pected results.
Answer1.
all the conditions mentioned are valid and not a single condition can be stated as false.
Cere i thin% the condition means the input type or situation (some may call it as valid or invalid% positive
or negative)
Also a single test case can contain both the input types and then the final result can be verified (it
obviously should not bring the required result% as one of the input condition is invalid% when the test case
would be e$ecuted)% this usually happens while writing secnario based test cases.
*or e$. Consider web based registration form% in which input data type for some fields are positive and for
some fields it is negative (in a scenario based test case)
Above screen can be tested by generating various scenario(s and combinations. 'he final result can be
verified against actual result and the registration should not be carried out sucessfully (as one/some input
types are invalid)% when this test case is e$ecuted.
'he writing of test case also depends upon the no. of descriptive fields the tester has in the test case
template. "o more elaborative is the test case template% more is the ease of writing test cases and
generating scenario(s. "o writing of test cases totally depends on the indepth thining of the tester and
there are no predefined or hard coded norms for writing test case.
'his is according to my understanding of testing and test case writing nowledge (as for many
applications% i have written many positive and negative conditions in a single test case and verified
different scenario(s by generating such test cases)
Answer2.
'he answer to this question will be ; 'est cases may contain both valid and invalid conditions.
"ince there is no restriction for the test case to be of multiple steps or more than one valid or invalid
conditions. 3ut A test case whether it is feature %unit level or end to end test case %it can not contain both
valid and invalid condition in a unit test case.
3ecause if this will happen then the concept of test case for a result will be dwindled and hence has no
meaning.
What is 6Quality Assurance7?
>6uality Assurance? measures the quality of processes used to create a quality product.
"oftware 6uality Assurance (N"6A0 or N6A0) is the process of monitoring and improving all activities
associated with software development% from requirements gathering% design and reviews to coding% testing
and implementation.
2t involves the entire software development process 9 monitoring and improving the process% maing sure
that any agreed9upon standards and procedures are followed% and ensuring that problems are found and
dealt with% at the earliest possible stage. @nlie testing% which is mainly a Ndetection0 process% 6A is
Npreventative0 in that it aims to ensure quality in the methods / processes U and therefore reduce the
prevalence of errors in the software.
4rganisations vary considerably in how they assign responsibility for 6A and testing. "ometimes they0re
the combined responsibility of one group or individual. Also common are pro7ect teams that include a mi$
of testers and developers who wor closely together% with overall 6A processes monitored by pro7ect
managers or quality managers.
6uality Assurance and "oftware -evelopment
6uality Assurance and development of a product are parallel activities. Complete 6A includes reviews of
the development methods and standards% reviews of all the documentation (not 7ust for standardisation
but for verification and clarity of the contents also). 4verall 6uality Assurance processes also include code
validation.
A note about quality assurance. 'he role of quality assurance is a superset of testing. 2ts mission is to help
minimise the ris of pro7ect failure. 6A people aim to understand the causes of pro7ect failure (which
includes software errors as an aspect) and help the team prevent% detect% and correct the problems. 4ften
test teams are referred to as 6A 'eams% perhaps acnowledging that testers should consider broader 6A
issues as well as testing.
Which thin%s to consider to test a (obile application throu%h blac& bo' techni2ue?
Answer1.
<ot sure how your device/server is to operate% so mold these ideas to fit your app. "ome highlights are.
+ange testing. #nsure that you can reconnect when leaving and returning bac into range.
Fort/2F/firewall testing 9 change ports and ips to ensure that you can connect and disconnect. modify the
firewall to shutoff the connection.
!ultiple devices 9 mae sure that a user receives his messages with other devices connected to the same
ip/port. Bour app should have a method to determine which device/user sent the message and only return
to it. "hould be in the message string sent and received. @nless you have conferencing capabilities within
the application.
Cycle the power of the server and watch the mobile unit reconnect automatically.
!obile unit sends a message and then power off the unit% when powering bac on and reconnecting%
ensure that the message is returned to the mobile unit.
Answer2.
<ot clearly mentioned which area of the mobile application you are testing with. &hether is it simple "!"
application or &AF application% you need to specify more details.2f you are woring with &AF then you can
download simulators from net and start testing over it.
What is the %eneral testin% process?
'he general testing process is the creation of a test strategy (which sometimes includes the creation of
test cases)% creation of a test plan/design (which usually includes test cases and test procedures) and the
e$ecution of tests. 'est data are inputs that have been devised to test the system
'est Cases are inputs and outputs specification plus a statement of the function under the test.
'est data can be generated automatically (simulated) or real (live).
'he stages in the testing process are as follows.
1. @nit testing. (Code 4riented)
2ndividual components are tested to ensure that they operate correctly. #ach component is tested
independently% without other system components.
2. !odule testing.
A module is a collection of dependent components such as an ob7ect class% an abstract data type or some
looser collection of procedures and functions. A module encapsulates related components so it can be
tested without other system modules.
;. "ub9system testing. (2ntegration 'esting) (-esign 4riented)
'his phase involves testing collections of modules% which have been integrated into sub9systems. "ub9
systems may be independently designed and implemented. 'he most common problems% which arise in
large software systems% are sub9systems interface mismatches. 'he sub9system test process should
therefore concentrate on the detection of interface errors by rigorously e$ercising these interfaces.
H. "ystem testing.
'he sub9systems are integrated to mae up the entire system. 'he testing process is concerned with
finding errors that result from unanticipated interactions between sub9systems and system components. 2t
is also concerned with validating that the system meets its functional and non9functional requirements.
G. Acceptance testing.
'his is the final stage in the testing process before the system is accepted for operational use. 'he system
is tested with data supplied by the system client rather than simulated test data. Acceptance testing may
reveal errors and omissions in the systems requirements definition( user 9 oriented) because real data
e$ercises the system in different ways from the test data. Acceptance testing may also reveal requirement
problems where the system facilities do not really meet the users needs (functional) or the system
performance (non9functional) is unacceptable.
Acceptance testing is sometimes called alpha testing. 3espoe systems are developed for a single client.
'he alpha testing process continues until the system developer and the client agrees that the delivered
system is an acceptable implementation of the system requirements.
&hen a system is to be mareted as a software product% a testing process called beta testing is often
used.
3eta testing involves delivering a system to a number of potential customers who agree to use that
system. 'hey report problems to the system developers. 'his e$poses the product to real use and detects
errors that may not have been anticipated by the system builders. After this feedbac% the system is
modified and either released fur further beta testing or for general sale.
What's nor(al practices of the QA specialists with perspective of software?
'hese are the normal practices of the 6A specialists with perspective of software
Snote. these are all 6C activities% not 6A activities.T
19-esgin +eview !eetings with the "ystem Analyst and 2f possible should be the part in +equirement
gathering
29Analysing the requirements and the desing and to trace the desing with respect to the requirements
;9'est Flanning
H9'est Case 2dentification using different techniques (&ith respect to the &eb 3ased Applciation and
-estoip Applications)
G9'est Case &riting ('his part is to be assigned to the testing engineers)
P9'est Case #$ecution ('his part is to be assigned to the testing engineers)
Q93ug +eporting ('his part is to be assigned to the testing engineers)
R93ug +eview and thier Analysis so that future bus can be removed by desgining some standards
from low9level to high level ('esting in "tages)
#$cept for small programs% systems should not be tested as a single unit. Aarge systems are built out of
sub9systems% which are built out of modules that are composed of procedures and functions. 'he testing
process should therefore proceed in stages where testing is carried out incrementally in con7unction with
system implementation.
'he most widely used testing process consists of five stages
Component testing @nit 'esting1erification
(Frocess 4riented) &hite 3o$ 'esting 'echniques
('ests that are derived from nowledge of the program(s structure and implementation)
!odule 'esting
2ntegrated testing "ub9system 'esting
"ystem 'esting
@ser testing Acceptance 'esting 1alidation
(Froduct 4riented) 3lac 3o$ 'esting 'echniques
('ests are derived from the program specification)
Cowever% as defects are discovered at any one stage% they require program modifications to correct them
and this may require other stages in the testing process to be repeated.
#rrors in program components% say may come to light at a later stage of the testing process. 'he process
is therefore an iterative one with information being fed bac from later stages to earlier parts of the
process.
+ow to test and to %et the difference between two i(a%es which is in the sa(e window?
Answer1.
Cow are you doing your comparisonD 2f you are doing it manually% then you should be able to see any
ma7or differences. 2f you are using an automated tool% then there is usually a comparison facility in the
tool to do that.
Answer2.
Vasper "oftware is an open9source utility which can be compiled into CWW and has a imgcmp function
which compares VF#= files in very good detail as long as they have the same dimentions and number of
components.
Answer;.
+ational has a comparison tool that may be used. 2(m sure !ercury has the same tool.
AnswerH.
'he ey question is whether we need a bit9by9bit e$act comparison% which the current tools are good at%
or an equivalency comparison. &hat differences between these images are not differencesD <ear9match
comparison has been the sub7ect of a lot of research in printer testing% including an !."c. thesis at *lorida
'ech. 2t(s a tough problem.
'esting "trategies
"trategy is a general approach rather than a method of devising particular systems for component tests.
-ifferent strategies may be adopted depending on the type of system to be tested and the development
process used. 'he testing strategies are
'op9-own 'esting
3ottom 9 @p 'esting
'hread 'esting
"tress 'esting
3ac9 to 3ac 'esting
1. 'op9down testing
&here testing starts with the most abstract component and wors downwards.
2. 3ottom9up testing
&here testing starts with the fundamental components and wors upwards.
;. 'hread testing
&hich is used for systems with multiple processes where the processing of a transaction threads its way
through these processes.
H. "tress testing
&hich relies on stressing the system by going beyond its specified limits and hence testing how well the
system can cope with over9load situations.
G. 3ac9to9bac testing
&hich is used when versions of a system are available. 'he systems are tested together and their outputs
are compared. P. Ferformance testing.
'his is used to test the run9time performance of software.
Q. "ecurity testing.
'his attempts to verify that protection mechanisms built into system will protect it from improper
penetration.
R. +ecovery testing.
'his forces software to fail in a variety ways and verifies that recovery is properly performed.
Aarge systems are usually tested using a mi$ture of these strategies rather than any single approach.
-ifferent strategies may be needed for different parts of the system and at different stages in the testing
process.
&hatever testing strategy is adopted% it is always sensible to adopt an incremental approach to sub9
system and system testing. +ather than integrate all components into a system and then start testing% the
system should be tested incrementally. #ach increment should be tested before the ne$t increment is
added to the system. 'his process should continue until all modules have been incorporated into the
system.
&hen a module is introduced at some stage in this process% tests% which were previously unsuccessful%
may now% detect defects. 'hese defects are probably due to interactions with the new module. 'he source
of the problem is locali5ed to some e$tent% thus simplifying defect location and repai
-ebugging
3rute force% bactracing% cause elimination.
@nit 'esting Coding *ocuses on each module and whether it wors properly. !aes heavy use of
white bo$ testing
2ntegration 'esting -esign Centered on maing sure that each module wors with another
module.
Comprised of two inds.
'op9down and
3ottom9up integration.
4r focuses on the design and construction of the software architecture.
!aes heavy use of 3lac 3o$ testing.(#ither answer is acceptable)
1alidation 'esting Analysis #nsuring conformity with requirements
"ystems 'esting "ystems #ngineering !aing sure that the software product wors with the e$ternal
environment% e.g.% computer system% other software products.
-river and "tubs
-river. dummy main program
"tub. dummy sub9program
'his is because the modules are not yet stand9alone programs therefore drive and or stubs have to be
developed to test each unit.
When do we prepare a Test 8lan?
SAlways prepared a 'est Flan for every new version or release of the productD T
*or four or five features at once% a single plan is fine. &rite new test cases rather than new test plans.
&rite test plans for two very different purposes. "ometimes the test plan is a product: sometimes it(s a
tool.
What is boundary value analysis?
3oundary value analysis is a technique for test data selection. A test engineer chooses values that lie
along data e$tremes. 3oundary values include ma$imum% minimum% 7ust inside boundaries% 7ust outside
boundaries% typical values% and error values. 'he e$pectation is that% if a systems wors correctly for these
e$treme or special values% then it will wor correctly for all values in between. An effective way to test
code is to e$ercise it at its natural boundaries.
3oundary 1alue Analysis is a method of testing that complements equivalence partitioning. 2n this case%
data input as well as data output are tested. 'he rationale behind 31A is that the errors typically occur at
the boundaries of the data. 'he boundaries refer to the upper limit and the lower limit of a range of values
or more commonly nown as the 8edges8 of the boundary.
-escribe methods to determine if you are testing an application too muchD
Answer1.
&hile testing% you need to eep in mind following two things always.
99 Fercentage of requirements coverage
99 <umber of 3ugs present W +ate of fall of bugs
99 *irstly% 'here may be a case where requirement is covered quite adequately but number of bugs do not
fall. 'his indicates over testing.
999 "econdly% 'here may be a case where those parts of application are also being tested which are not
affected by a CCA<=# or 3@= *2M'@+#. 'his is again a case of over testing.
99 'hird is the case as you have suggested% with slight modification% i.e bug has sufficiently dropped off but
still testing is being at "A!# levels as before.
!ethods to determine if an application is being over9tested are99
1. Comparison of (+ate of -rop in number of 3ugs( / (#ffort 2nvested in 'esting( (&ith all +equirements
been met) 'hat is% if bug rate is falling (as it generally happens in all applications)% but effort invested in
man hours does not fall% this implies 4ver testing.
2. Comparison of (Achievment of bug rate threshold( / (#ffort 2nvested in 'esting( (&ith all +equirements
been met) 'hat is% if bug rate has already achieved the agreed9upon value with business and still the
testing efforts are being invested with no/little reduction.
;. 1erifying if the (2mpact Analysis( for (Change +equests( has been done properly and being implemented
correctly. 'hat is% to chec and verify that the components of A@' which have got impacted by the new
change are being tested only and no other unrequired component is being tested unneccessarily. 2f
unaffected components are being tested% this implies 4ver testing.
Answer2.
2f the bug find rate has dropped off considerably% the test group should shift its testing strategy. 4ne of
the ey problems with heavy reliance on regression testing is that the bug find rate drops off even though
there are plenty of bugs not yet found. 'o find new bugs% you have to run new tests.
#very test technique is stronger for some types of bugs and weaer for others. !any test groups use only
a few techniques. 2n our consulting% Vames 3ach and 2 repeatedly wored with companies that relied on
only one or two main techniques.
&hen one technique% any one test technique% yields few bugs% shifting to new technique(s) is liely to
e$pose new problems.
At some point% you can use a measure that is only partially statistical 99 if your bug find rate is low A<-
you can(t thin of any new testing approaches that loo promising% 'C#< you are at the limit of your
effectiveness and you should ship the product. 'hat still doesn(t mean that the application is overtested. 2t
7ust means that B4@(+# not going to find many new bugs.
Answer;.
3est way is to monitor the test defects over the period of time
+efer williams perry boo% where he has mentioned the concept of (under test( and (over test(% in fact the
data can be plotted to see the criteria.
Bes one of the criteria is to monitor the defect rate and see if it is almost 5ero second method would be
using test coverage when it reach 1KKL (or 1KKL requirement coverage)
Frocedural "oftware 'esting 2ssues
"oftware testing in the traditional sense can miss a large number of errors if used alone. 'hat is why
processes lie "oftware 2nspections and "oftware 6uality Assurance ("6A) have been developed.
Cowever% even testing all by itself is very time consuming and very costly. 2t also ties up resources that
could be used otherwise. &hen combined with inspections and/or "6A or when formali5ed% it also
becomes a pro7ect of its own requiring analysis% design and implementation and supportive
communications infrastructure. &ith it interpersonal problems arise and need managing. 4n the other
hand% when testing is conducted by the developers% it will most liely be very sub7ective. Another problem
is that developers are trained to avoid errors. As a result they may conduct tests that prove the product is
woring as intended (i.e. proving there are no errors) instead of creating test cases that tend to uncover
as many errors as possible.
What is the purpose of a test plan?
+eason number 1. &e create a test plan because preparing it helps us to thin through the efforts needed
to validate the acceptability of a software product.
+eason number 2. &e create a test plan because it can and will help people outside the test group to
understand the why and how of product validation.
+eason number ;. &e create a test plan because% in regulated environments% we have to have a written
test plan.
+eason number H. &e create a test plan because the general testing process includes the creation of a
test plan.
+eason number G. &e create a test plan because we want a document that describes the ob7ectives%
scope% approach and focus of the software testing effort.
+eason number P. &e create a test plan because it includes test cases% conditions% the test environment%
a list of related tass% pass/fail criteria% and ris assessment.
+eason number Q. &e create test plan because one of the outputs for creating a test strategy is an
approved and signed off test plan document.
+eason number R. &e create a test plan because the software testing methodology a three step process%
and one of the steps is the creation of a test plan.
+eason number J. &e create a test plan because we want an opportunity to review the test plan with the
pro7ect team.
+eason number 1K. &e create a test plan document because test plans should be documented% so that
they are repeatable.
Can we prepare Test 8lan without S3S?
2t is not always mandatory that you should have "+" document to prepare a 'est Flan. 'his ind of
-ocuments Cierarchy is maintained to maintain 4rgani5ational standards and also to have clear
understanding of the things.
Bes you can Frepare a 'est plan directly without "+"% &hen the +equirements are clear with your
clients%and when your @+-(@ser +equirement -ocument ) is supportive enough to clarify the issues.
'hough we don(t have "+" clients will be giving some information "+" only contains mainly Froduct
information
3ut we will not now the 'esting effort if we don(t have "+".
"+" contains Cow many cycles we are testing% and on the platforms we are testing % etc.
Actually there won(t be any harm in doing so% beco5% ultimately you will send your 'est plan document to
your client and after getting approval from him only you start 'esting.
(<ote.9 "+" is the document which you get in the Analysis phase of your "oftware -evelopment. 'est plan
is the document % which contains the details of Froduct interms of % 'set strategy % "cope of testing% 'ypes
of tests to be conducted%+is !anagemnet % !ention of Automation 'ool %About 3ug tracing 'ool% etc..%)
+ow do test plan te(plates loo& li&e?
'he test plan document template helps to generate test plan documents that describe the ob7ectives%
scope% approach and focus of a software testing effort. 'est document templates are often in the form of
documents that are divided into sections and subsections. 4ne e$ample of a template is a H9section
document where section 1 is the description of the 8'est 4b7ective8% section 2 is the the description of
8"cope of 'esting8% section ; is the the description of the 8'est Approach8% and section H is the 8*ocus of
the 'esting #ffort8.
All documents should be written to a certain standard and template. "tandards and templates maintain
document uniformity. 'hey also help in learning where information is located% maing it easier for a user
to find what they want. &ith standards and templates% information will not be accidentally omitted from a
document. 4nce +ob -avis has learned and reviewed your standards and templates% he will use them. Ce
will also recommend improvements and/or additions.
A software pro7ect test plan is a document that describes the ob7ectives% scope% approach and focus of a
software testing effort. 'he process of preparing a test plan is a useful way to thin through the efforts
needed to validate the acceptability of a software product. 'he completed document will help people
outside the test group understand the why and how of product validation.
+ow to Test a des&top syste(s ?
Bou will liely have to use a programming or scripting language to interact with the service directly. Bou
will have more control over the raw information that way.
Bou will have to determine what the service is supposed to do and how it is supposed to interact with
other applications and services. A data dictionary liely e$ists. 2t may not be called that however. &hat
this document does is e$plain what commands the service will respond to and what sort of data should be
sent. Bou will have to use this document to do your testing. =et close to the person or people who created
the document or the service and e$pect them to eep you in the loop when changes tae place (it doesn(t
help anyone if you report a defect and it(s really only reflecting an e$pected change in the operation of the
service).
-estop applications are generally designed to run and quit. Bou have to be concerned with memory leas
and system usage.
+ow do you create a test strate%y?
'he test strategy is a formal description of how a software product will be tested. A test strategy is
developed for all levels of testing% as required. 'he test team analy5es the requirements% writes the test
strategy and reviews the plan with the pro7ect team. 'he test plan may include test cases% conditions% the
test environment% a list of related tass% pass/fail criteria and ris assessment.
2nputs for this process.
) A description of the required hardware and software components% including test tools. 'his information
comes from the test environment% including test tool data.
) A description of roles and responsibilities of the resources required for the test and schedule constraints.
'his information comes from man9hours and schedules.
) 'esting methodology. 'his is based on nown standards.
) *unctional and technical requirements of the application. 'his information comes from requirements%
change request% technical and functional design documents.
) +equirements that the system can not provide% e.g. system limitations.
4utputs for this process.
) An approved and signed off test strategy document% test plan% including test cases.
) 'esting issues requiring resolution. @sually this requires additional negotiation at the pro7ect
management level.
+ow to do Esti(atin% Testin% effort ?
'ime #stimation method for 'esting Frocess
<ote . folloing method is based on use case driven specification.
"tep 1 . count number of use cases (<@C) of system
step 2 . "et Avg 'ime 'est Cases(A''C) as per test plan
step ; . #stimate total number of test cases (<'C)
'otal number of test cases X <umber of usecases M Avg testcases per a use case
"tep H . "et Avg #$ecution 'ime (A#') per a test case (idelly 1G min depends on your system)
"tep G . Calculate 'otal #$ecution 'ime ('#')
'#' X 'otal number of test cases ) A#'
"tep P . Calculate 'est Case Creation 'ime ('CC')
useually we will tae 1.G times of '#' as 'CC'
'CC' X 1.G ) '#'
"tep Q . 'ime for +e'est Case #$ecution (+'C#) this is for retesting
useually we tae K.G times of '#'
+'C# X K.G ) '#'
"tep R . "et +eport generation 'ime (+='
usually we tae K.2 times of '#'
+=' X K.2 ) '#'
"tep J . "et 'est #nvironment "etup 'ime ('#"')
it also depends on test plan
"tep 1K . 'otal #stimation time X '#' W 'CC'W +'C# W +=' W '#"' W some buffer...:)
#$ample
'otal <o of use cases (<@C) . 22Q
Average test cases per @se cases(A#') . 1K
#stimated 'est cases(<'C) . 22Q ) 1K X 22QK
'ime estimation e$ecution ('#') . 22QK/H X GPQ.G hr
'ime for creating testcases ('CC') . GPQ.G)H/; X QGP.P hr
'ime for retesting (+'C#) . GPQ.G/2 X 2R;.QG hr
+eport =eneration(+=') X 1KK hr
'est #nvironment "etup 'ime('#"') X 2K hr.
9999999999999999999
'otal Crs 1Q2Q.RG W buffer
9999999999999999999
here H means <umber of testcases e$ecuted per hour
i.e 1G min will tae for e$ecution of each test case
&hat is the purpose of test strategyD
+eason number 1. 'he number one reason of writing a test strategy document is to 8have8 a signed%
sealed% and delivered% *-A (or *AA) approved document% where the document includes a written testing
methodology% test plan% and test cases.
+eason number 2. Caving a test strategy does satisfy one important step in the software testing process.
+eason number ;. 'he test strategy document tells us how the software product will be tested.
+eason number H. 'he creation of a test strategy document presents an opportunity to review the test
plan with the pro7ect team.
+eason number G. 'he test strategy document describes the roles% responsibilities% and the resources
required for the test and schedule constraints.
+eason number P. &hen we create a test strategy document% we have to put into writing any testing
issues requiring resolution (and usually this means additional negotiation at the pro7ect management
level).
+eason number Q. 'he test strategy is decided first% before lower level decisions are made on the test
plan% test design% and other testing issues.
What's Quality Approach docu(ent? what should be the contents and thin%s li&e that000
Answer1.
you should start thining from your company business type% and according to it define different processes
for your organi5ation. lie procurment% C! etc
'hen thin over different matrices you will be calculating for each process% and define them with formula%
the ind of analysis will be doing and when shall the red flag to be raised%
-ecide on your audit policies frequencies etc. 'hin on the change control board if any process needs
modification.
Answer2.
3y defining the process i mean the structured collection of practices that describe the characteristics of the
wor and its quality. writting process means creating a system with which every one will wor% the
benefits of it are lie common language and a shared vision across organi5ation% its will be a frame wor
for prioriti5ing actions.
*rom implementation point of view first you need to brea the complete life cycle of your product in
diffrent meaningful steps% and setting the goals for each phase.
you can create different document templates which every one shall follow% -efine the dependencies among
different groups for each pro7ect% -efine riss for each pro7ect and what is mitigation plan for each ris.
etc
Bou can read the C!!2 model% customi5e that as per your organi5ation goal. for a start up company As
per my personal opinion% its better to define and reach at the process for Aevel ; *irst and then go for
level G.
What does a test strate%y docu(ent contain?
'he test strategy document contains test cases% conditions% the test environment% a list of related tass%
pass/fail criteria and ris assessment. 'he test strategy document is a formal description of how a
software product will be tested. &hat is the test strategy document developed forD 2t is developed for all
levels of testing% as required. Cow is it written% and who writes itD 2t is the test team that analy5es the
requirements% writes the test strategy% and reviews the plan with the pro7ect team.
Why Q/A should not report to develop(ent?
3ased on research from the 6uality Assurance 2nstitute% the percent of quality groups in each location is
noted%
GKL 9 reports to "enior 2' !anager 9 'his is the best positioning because it gives the 6uality !anager
immediate access to the 2' !anager to discuss and promote 6uality issues% when the quality manager
reports elsewhere% quality issues may not be raised to the appropriate level or receive the necessary
action.
2GL 9 reports to !anager of systems/programming
1G L reports to !anger oprerations.
1K L outside 2' function.
Which of the followin% state(ents about 3e%ression state(ents are true?
1999+egression testing must consist of a fi$ed set of tests to create a base line
2999+egression tests should be used to detect defects in new feature
;999+egression testing can be run on every build
H999 +egression testing should be targeted areas of high ris and nown code change
G999+egression testing when automated% is highly effective in preventing defects.
Answer1.
1999+egression testing must consist of a fi$ed set of tests to create a base line
-on(t thin it is true as a 8must8 99 it
depends on whether your regression testing style involves repeating identical tests or redoing testing in
previously tested areas with similar tests or tests that address the same riss. *or e$ample% some people
do regression testing with tests whose specific parameters are determined randomly. 'hey broaden the set
of values they test while achieving essentially the same testing. "econd e$ample99some regression test
suites include random stringing together of test cases (they include load testing and duration testing in
their regression series% reporting their results as part of the assessment of each build). -epending on your
theory of the YpointY of regression testing% these may or may not be entirely valid regression tests.
2999+egression tests should be used to detect defects in new feature
Cow do you create new regression testsD "hould you design new tests as standalone% or should you
develop a strategy in which the tests you use for bug9hunting are designed to be reusable as regression
testsD 2f the latter% and 2 have certainly heard some silled testers argue that the latter approach wored
well in their sistuation% then Z2 is sometimes true.
;999+egression testing can be run on every build
'his is true% though it might be silly and a big waste of time.
H999 +egression testing should be targeted areas of high ris and nown code change
Cmmm% there(s a area of computer science called program slicing and one of the ob7ectives of this class of
wor is to figure out how to restrict the regression test suite to a smaller number of tests% which test only
those things that might have been impacted by a change. 3ob =lass has critici5ed the results of some of
this wor% but if ZH is false% some Fh.-.(s and big research grants should be retracted.
G999+egression testing when automated% is highly effective in preventing defects.
@nit9level automated regression testing is highly effective in preventing defects99read up on test9driven
development.
Answer2.
Aet me e$plain why 2 thin 2 / G are false
2999+egression tests should be used to detect defects in new feature
"ince regression tests only address e$isting features and functionality% it can(t find defects in new features.
2t can only find where e$isting features and functionality have been broen by changes.
G999+egression testing when automated% is highly effective in preventing defects.
"ince no tests prevent defects% they only find them% it(s impossible to prevent defects with a regression
test. 2 will add% however% that if a developer can use an automated regression test to test their own code
before submitting it to the code repository (say in the form a series of unit tests coupled to a library% etc.)
then you could in some way prevent defects with a regression test.
2 also don(t lie 19 and H. 19 since a regression test suite grows as the product does. 'herefore the tests
are not fi$ed. H9 because a regression test tests the whole application% not 7ust a targeted area. 2n the
past% 2 have used the concept of test depth (level 1 being the basic regression tests99higher number
reflect additional functionality) so you could run a level one regression on the whole program but do level
three on the transport layer 8because we(ve updated the library8. '
an automated set of tests would be the most liely way to mae ;9 a possibility. 2t is unliely that with
daily builds% as many companies run their build process% that anything short of an automated regression
test suite would be able to be run daily with any efficacy. if the builds were weely% then a manual
regression test would be liely.
Answer;.
As per the difinition of regression testing and actual woraround if you have to have answer this question
then option ; / H is the best choice among all.'he reason behind it is .
;999+egression testing can be run on every build 2t is a normal phenomenon if there is build coming on
weely basis or it is a +C build."ince%there is nothing mention about daily build %only thing mention is
every build so it can be correct.
H999+egression testing should be targeted areas of high ris and nown code change 'his is also true in
most of the situation%it is not universally true but in certain condition where there is code change and the
related modules are only tested in regression automation rather than whole code.
G is not true co5 in regression we detect the defect not prevent normally.
+ow do you e'ecute tests?
#$ecution of tests is completed by following the test documents in a methodical manner. As each test
procedure is performed% an entry is recorded in a test e$ecution log to note the e$ecution of the procedure
and whether or not the test procedure uncovered any defects. Checpoint meetings are held throughout
the e$ecution phase. Checpoint meetings are held daily% if required% to address and discuss testing
issues% status and activities.
) 'he output from the e$ecution of test procedures is nown as test results. 'est results are evaluated by
test engineers to determine whether the e$pected results have been obtained. All discrepancies/anomalies
are logged and discussed with the software team lead% hardware test lead% programmers% software
engineers and documented for further investigation and resolution. #very company has a different process
for logging and reporting bugs/defects uncovered during testing.
) A pass/fail criteria is used to determine the severity of a problem% and results are recorded in a test
summary report. 'he severity of a problem% found during system testing% is defined in accordance to the
customer(s ris assessment and recorded in their selected tracing tool.
) Froposed fi$es are delivered to the testing environment% based on the severity of the problem. *i$es are
regression tested and flawless fi$es are migrated to a new baseline. *ollowing completion of the test%
members of the test team prepare a summary report. 'he summary report is reviewed by the Fro7ect
!anager% "oftware 6A !anager and/or 'est 'eam Aead.
) After a particular level of testing has been certified% it is the responsibility of the Configuration !anager
to coordinate the migration of the release software components to the ne$t test level% as documented in
the Configuration !anagement Flan. 'he software is only migrated to the production environment after
the Fro7ect !anager(s formal acceptance.
) 'he test team reviews test document problems identified during testing% and update documents where
appropriate.
2nputs for this process.
) Approved test documents% e.g. 'est Flan% 'est Cases% 'est Frocedures.
) 'est tools% including automated test tools% if applicable.
) -eveloped scripts.
) Changes to the design% i.e. Change +equest -ocuments.
) 'est data.
) Availability of the test team and pro7ect team.
) =eneral and -etailed -esign -ocuments% i.e. +equirements -ocument% "oftware -esign -ocument.
) A software that has been migrated to the test environment% i.e. unit tested code% via the
Configuration/3uild !anager.
) 'est +eadiness -ocument.
) -ocument @pdates.
4utputs for this process.
) Aog and summary of the test results. @sually this is part of the 'est +eport. 'his needs to be approved
and signed9off with revised testing deliverables.
) Changes to the code% also nown as test fi$es.
) 'est document problems uncovered as a result of testing. #$amples are +equirements document and
-esign -ocument problems.
) +eports on software design issues% given to software developers for correction. #$amples are bug
reports on code issues.
) *ormal record of test incidents% usually part of problem tracing.
) 3ase9lined pacage% also nown as tested source and ob7ect code% ready for migration to the ne$t level.
What is a re2uire(ents test (atri'?
'he requirements test matri$ is a pro7ect management tool for tracing and managing testing efforts%
based on requirements% throughout the pro7ect(s life cycle.
'he requirements test matri$ is a table% where requirement descriptions are put in the rows of the table%
and the descriptions of testing efforts are put in the column headers of the same table.
'he requirements test matri$ is similar to the requirements traceability matri$% which is a representation
of user requirements aligned against system functionality. 'he requirements traceability matri$ ensures
that all user requirements are addressed by the system integration team and implemented in the system
integration effort.
'he requirements test matri$ is a representation of user requirements aligned against system testing.
"imilarly to the requirements traceability matri$% the requirements test matri$ ensures that all user
requirements are addressed by the system test team and implemented in the system testing effort.
Can you %ive (e a re2uire(ents test (atri' te(plate?
*or a requirements test matri$ template% you want to visuali5e a simple% basic table that you create for
cross9referencing purposes.
"tep 1. *ind out how many requirements you have.
"tep 2. *ind out how many test cases you have.
"tep ;. 3ased on these numbers% create a basic table. 2f you have a list of JK requirements and ;PK test
cases% you want to create a table of J1 rows and ;P1 columns.
"tep H. *ocus on the the first column of your table. 4ne by one% copy all your JK requirement numbers%
and paste them into rows 2 through J1 of the table.
"tep G. <ow switch your attention to the the first row of the table. 4ne by one% copy all your ;PK test case
numbers% and paste them into columns 2 through ;P1 of the table.
"tep P. #$amine each of your ;PK test cases% and% one by one% determine which of the JK requirements
they satisfy. 2f% for the sae of this e$ample% test case number PH satisfies requirement number 12% then
put a large 8M8 into cell 1;9PG of your table... and then you have it: you have 7ust created a requirements
test matri$ template that you can use for cross9referencing purposes.
What (etrics are used for bu% trac&in%?
!etrics that can be used for bug tracing include the followings. the total number of bugs% total number of
bugs that have been fi$ed% number of new bugs per wee% and the number of fi$es per wee. !etrics for
bug tracing can be used to determine when to stop testing% for e$ample% when bug rate falls below a
certain level. Bou CA< learn to use defect tracing software.
-0 In QA tea(5 everyone tal&s about process0 What e'actly they are ta&in% about?
;0 Are there any different type of process?
Answer1.
&hen you tal about 8process8 you are generally taling about the actions used to accomplish a tas.
Cere(s an e$ample. Cow do you solve a 7igsaw pu55leD
Bou start with a bo$ full of oddly shaped pieces. 2n your mind you come up with a strategy for matching
two pieces together (or no strategy at all and simply grab random pieces until you find a match)% and
continue on until the pu55le is completed.
2f you were to describe the )way) that you go about solving the pu55le you would be describing the
process.
"ome follow9up questions you might thin about include things lie.
9 Cow much time did it tae you to solve the pu55leD
9 -o you now of any sills% trics or practices that might help you solve the pu55le quicerD
9 &hat if you try to solve the pu55le with someone elseD -oes that help you go faster% or slowerD (why or
why notD) Can you have )too) many people on this one tasD
9 'o answer your second question% 2(ll as )you) the question. Are there different ways that people can
solve a 7igsaw pu55leD
'here are many interesting process9related questions% ideas and theories in 6uality Assurance. =enerally
the identification of worplace processes lead to the questions of improvement in efficiency and
productivity. 'he motivation behind that is to try and mae the processes as efficient as possible so as to
incur the least amount of time and e$pense% while providing a general sense of repeatability% visibility and
predictability in the way tass are performed and completed.
'he idea behind this is generally good% but the e$ecution is often flawed. 'hat is what maes 6A so
interesting. Bou see% when you wor with people and processes% it is very different than woring with the
processes performed by machines. "ome people in 6A forget that distinction and often become
disillusioned with the whole thing.
2f you always remember to approach processes in the worplace with a people9centric view% you should do
fine.
Answer2.
'here is.
) &aterfall
) "piral
) +apid prototype
) Clean room
) Agile (MF% "crum% ...)
What (etrics are used for test report %eneration?
!etrics that can be used for test report generation include...
!cCabe metrics. cyclomatic comple$ity metric (v(=))% actual comple$ity metric (AC)% module design
comple$ity metric (iv(=))% essential comple$ity metric (ev(=))% pathological comple$ity metric (pv(=))%
design comple$ity metric ("K)% integration comple$ity metric ("1)% ob7ect integration comple$ity metric
(4"1)% global data comple$ity metric (gdv(=))% data comple$ity metric (-1)% tested data comple$ity
metric ('-1)% data reference metric (-+)% tested data reference metric ('-+)% maintenance severity
metric (maintYseverity)% data reference severity metric (-+Yseverity)% data comple$ity severity metric
(-1Yseverity)% global data severity metric (gdvYseverity).
!cCabe ob7ect9oriented software metrics. encapsulation percent public data (FC'F@3)% access to public
data (F@3-A'A)% polymorphism percent of unoverloaded calls (FC'CAAA)% number of roots (+44'C<')%
fan9in (*A<2<)% quality ma$imum v(=) (!AM1)% ma$imum ev(=) (!AM#1)% and hierarchy quality (6@AA).
4ther ob7ect9oriented software metrics. depth (-#F'C)% lac of cohesion of methods (A4C!)% number of
children (<4C)% response for a class (+*C)% weighted methods per class (&!C)% Calstead software metrics
program length% program volume% program level and program difficulty% intelligent content% programming
effort% error estimate% and programming time.
Aine count software metrics. lines of code% lines of comment% lines of mi$ed code and comments% and lines
left blan.
What is 2uality plan?
Answer1.
the test plan is the document created before starting the testing process% it includes that types of testing
that will be performed% high level scope of the pro7ect% the envirnmental requirements of the testing
process% what automated testing tools will be used (2f available)% the schedule of each test% when it will
start and end.
Answer2.
you should not only understand what a 6uality Flan is% but you should understand why you(re maing it. 2
don(t beleieve that 8because 2 was told to do so8 is a good enough reason. 2f the person who told you to
create it can(t tell you 1) what it is% and 2) how to create it% 2 don(t thin that they actually now why it(s
needed. 'hat breas the primary rule of all plans used in testing.
&e write quality plans for two very different purposes. "ometimes the quality plan is a product:
sometimes it(s a tool. 2t(s too easy% but also too e$pensive% to confuse these goals.
2f it(s not being used as a tool% don(t waste your time (and your company(s money) doing this.
What is the difference between verification and validation?
1erification taes place before validation% and not vice versa.
1erification evaluates documents% plans% code% requirements% and specifications. 1alidation% on the other
hand% evaluates the product itself.
'he inputs of verification are checlists% issues lists% walthroughs and inspection meetings% reviews and
meetings. 'he input of validation% on the other hand% is the actual testing of an actual product.
'he output of verification is a nearly perfect set of documents% plans% specifications% and requirements
document. 'he output of validation% on the other hand% is a nearly perfect% actual product.
What is the difference between efficient and effective?
8#fficient8 means having a high ratio of output to input: which means woring or producing with a
minimum of waste. *or e$ample% 8An efficient engine saves gas.8 4r% 8An efficient test engineer saves
time8.
8#ffective8% on the other hand% means producing or capable of producing an intended result% or having a
striing effect. *or e$ample% 8*or rapid long9distance transportation% the 7et engine is more effective than
a witch(s broomstic8. 4r% 8*or developing software test procedures% engineers speciali5ing in software
testing are more effective than engineers who are generalists8.
+ow effective can we i(ple(ent si' si%(a principles in a very lar%e software services
or%ani9ation?
Answer1.
#ffective way of implementing si$sigma.
there are quite a few things one needs
1. management buyin
2. dedicated team both drivers as well as adopters
;. training
H. culture building 9 if you have a pro process culture% life is easy
G. sustained effort over a period towards transforming% people% thoughts and actions Fersonally technical
content is never a challenge% but adoption is a challenge.
Answer2.
8"i$ sigma8 is a combination of process recommendations and mathematical model. 'he name 8si$ sigma8
reflects the notion of reducing variation so much that errors 99 events out of tolerance 99 are si$ standard
deviations from a desired mean. 'he mathematics are at the core of the process implementation.
'he problem is that software is not hardware. "oftware defects are designed in% not the result of
manufacturing variation.
'he other side of si$ sigma is the drive for continuous improvement. Bou don(t need the si$ sigma math
for this and the concept has been around long before the si$ sigma movement.
'o improve anything% you need some type of indicator of its current state and a way to tell that it is
improved. Flus determination to improve it. !anagement support helps.
Answer;.
'here are different methodologies adopted in si$sigma. Cowever% it is commonly referenced from the
variance based approach. 2f you are trying to loo at si$sigma from that% for software services%
fundamentally the measurement system should be reliable 9 industry has not reached the maturity level of
manufacturing industry where it fits to a '. 'he differences between "& and C&/manufacturing industry is
slightly difficult to address.
'here are some areas you can adopt si$sigma in its full statistical form(eg in9process error rate%
productivity improvements etc)% some areas are difficult.
'he narrower the problem area is% the better it gets even in software services to address adopting the
statistical method.
'here are methodologies that have a bundle of tools%along with statistical techniques% are used on the full
"-AC.
A generic observation is %"" helps if we loo for proper fitment of methodology for the purpose. #lse
doubts creep in
What sta%e of bu% fi'in% is the (ost cost effective?
3ug prevention techniques (i.e. inspections% peer design reviews% and wal9throughs) are more cost
effective than bug detection.
What is "efect <ife Cycle0?
Answer1.
-efect life cycle is....different stages after a defect is identified.
<ew (&hen defect is identified)
Accepted (when -evelopment team and 6A team accepts it(s a 3ug)
2n Frogress (when a person is woring to resolve the issue9defect)
+esolved (once the defect resolved)
Completed ("ome one who can tae up the responsibly 'eam lead)
Closed/reopened (+etested by '# and he will update the "tatus of the bug)
Answer2.
-efect Aife Cycle is nothing but the various phases a 3ug undergoes after it is raised or reported.
A general 2nterview answer can be given as.
1. <ew or 4pened
2. Assinged
;. *i$ed
H. 'ested
G. Closed.
What is the difference between a software bu% and software defect?
8"oftware bug8 is nonspecific: it means an ine$plicable defect% error% flaw% mistae% failure% fault% or
unwanted behavior of a computer program. 4ther terms% e.g. 8software defect8% or 8software failure8% are
more specific.
&hile the word 8bug8 has been a part of engineering 7argon for many9many decades: many9many decades
ago even 'homas #dison% the great inventor% wrote about a 8bug8 9 today there are many who believe the
word 8bug8 is a reference to insects that caused malfunctions in early electromechanical computers.
&hat is the difference between a software bug and software defectD
2n software testing% the difference between 8bug8 and 8defect8 is small% and also depends on the end
client. *or some clients% bug and defect are synonymous% while others believe bugs are subsets of defects.
-ifference number one. 2n bug reports% the defects are easier to describe.
-ifference number two. 2n my bug reports% it is easier to write descriptions as to how to replicate defects.
2n other words% defects tend to require only brief e$planations.
Commonality number one. &e% software test engineers% discover both bugs and defects% before bugs and
defects damage the reputation of our company.
Commonality number two. &e% software 6A engineers% use the software much lie real users would% to
find both bugs and defects% to find ways to replicate both bugs and defects% to submit bug reports to the
developers% and to provide feedbac to the developers% i.e. tell them if they(ve achieved the desired level
of quality.
Commonality number three. &e% software 6A engineers% do not differentiate between bugs and defects. 2n
our reports% we include both bugs and defects that are the results of software testing.
Are developers s(arter than tester? Any su%%estion about the future prospects and
technicality involvedin the testin% :ob?
Answer1.
6A / 'esting are thanless 7obs. 2n a software development company developer is a core person. As you
are a fresh graduate% it would be good for you to wor as a developer. *rom development you can always
move to testing or 6A or other admin/support tass. 3ut from 'esting or 6A it is little difficult to go bac
to development% though not impossible(as u are 3# comp)
"eeing the 7ob maret% it is not possible for each / every fresher to get into development. 3ut you can
eep searching for it.
"ome big company(s have seperate 1erifiction / 1alidation groups where only testing pro7ects are
e$ecuted. 'hose teams have 'As% FAs who are testing e$perts. 'hey earn good salary same as
development people.
2n technical pro7ects the testing team does lot of technical wor. Bou can do certifications to improve your
technical sills / maret value.
2t all depends on your way of handling things / interpersonal% communication and leadership sills. 2f it is
difficult for you to get a 7ob in developement or you really lie testing% 7ust go ahead. 'ry to achieve
e$cellence as a testing professional. Bou will never have a 7ob problem .Also you will always get onsite
opportunities tooEE Buo might have to struggle for initial few years lie all other freshers.
Answer2.
6A and 'esting are thanless only in some companies.
'esting is part of development. +ather than distinguish between testing and development%distinguish
between testing and programming.
Frogramming is also thanless in some companies.
<ot suggesting that anyone should or should not go into testing. 2t depends on your sills and interests.
"ome people are better at programming and worse at testing% some better at testing and worse at
programming% some are not suited for either role. Bou should decide what you are good at and what
fascinates you. &hat type of wor would mae you &A<' to stay at wor for PK9RK hours a wee for a
few years because it is so interestingD
"uggesting that there are e$cellent testing 7obs out there% but there are bad ones too (in testing and in
programming% both).
Cave not seen any certification in software testing that improves the technical sill of anyone. Apparently%
testing certification improves a tester(s maret value in some marets.
!ost companies mean testing when they say 86A8. 4r they mean 'esting plus !etrics% where the metrics
tass are low9sill data collection and basic data analysis rather than thining up and 7ustifying
measurement systems appropriate to the questions at hand. 2n terms of sill% salary% intellectual challenge
and value to the company% testingWmetrics is the same as testing. "ome companies see 6A more
strategically% and hire more senior people into their groups. Cere is a hint99if you can get a 7ob in a group
called 6A with less than G years of e$perience% it(s a testing group or something equivalent to it.
Answer;.
<othing is considered as great or a mean 7ob. As long as you lie and love to do% everything in that seems
to be interesting.
2 started as a developer and slowly moved to 'esting. 2 find testing to be more challenging and interesting.
2 have solid P years of testing e$perience alone and many sernior people are there in my team% who are
professional testers.
AnswerH.
testing is low9sill wor in many companies.
"cripted testing of the ind pushed by 2"#3% 2"'63% and the other certifiers is low sill% low prestige%
offers little return value to the company that pays for it% and is often pushed to offsite contracting firms
because it isn(t worth doing in9house. 2n many cases% it is 7ust a process of 8going through the motions8 99
pretending to do testing (and spending a lot of money in the pretense) but without really looing for any
important information and without creating any artifacts that will be useful to the pro7ect team.
'he only reason to tae a 7ob doing this ind of wor is to get paid for it. -oing it for too long is bad for
your career.
'here are much higher9sill ways to do testing. "ome of them involve partial automation (writing or using
programs to help you investigate the program more effectively)% but automation tools are 7ust tools. 'hey
are often used 7ust as mind9numbingly and valuelessly as scripted manual testing. &hen you(re offered
this ind of position% try to find out how much 7udgment you will have to e$ercise in the analysis of the
product under test and the ways that it provides value to the users and other staeholders% in the design
of tests to chec that value and to chec for other threats to value (security failures% performance failures%
usability failures% etc.)99and how much this position will help you develop your 7udgment. 2f you will
become a more silled and more creative investigator who has a better collection of tools to investigate
with% that might be interesting. 2f not% you will be maring time (maing money but learning little) while
the rest of the technical world learns new ideas and sills.
What's the difference between priority and severity?
'he word 8priority8 is associated with scheduling% and the word 8severity8 is associated with standards.
8Friority8 means something is afforded or deserves prior attention: a precedence established by urgency
or order of or importance.
"everity is the state or quality of being severe: severe implies adherence to rigorous standards or high
principles and often suggests harshness: severe is mared by or requires strict adherence to rigorous
standards or high principles. *or e$ample% a severe code of behavior.
'he words priority and severity do come up in bug tracing. A variety of commercial% problem9tracing /
management software tools are available. 'hese tools% with the detailed input of software test engineers%
give the team complete information so developers can understand the bug% get an idea of its severity%
reproduce it and fi$ it. 'he fi$es are based on pro7ect priorities and severity of bugs. 'he severity of a
problem is defined in accordance to the end client(s ris assessment% and recorded in their selected
tracing tool. A buggy software can severely affect schedules% which% in turn can lead to a reassessment
and renegotiation of priorities.
+ow to test a web based application that has recently been (odified to %ive support for "ouble
,yte Character Sets?
Answer1.
should apply blac bo$ testing techniques (boundary analysis% equivalence partioning)
Answer2.
'he Vapanese and other #ast Asian Customers are very particular of the loo and feel of the @2. "o please
mae sure% there is no truncation at any place.
4ne !a7or difference between Vapanese and #nglish is that there is no concept of spaces between the
words in Vapanese. 'he line breas in #nglish usually happens whenever there is a "pace. 2n Vapanese this
leads to a lot of problem with the wrapping on the te$t and if you have a table with defined column length%
you might see te$t appearing vertical.
4n the functionality side.
1. Chec for the date format and <umber format. (it should be in the native locale)
2. Chec that your system accepts 29byte numerals and characters.
;. 2f there is any fields with a boundary value of 1KK characters% the field should accept% the same number
of 29byte character as well.
H. 'he application should wor on a <ative (Chinese% Vapanese% ,orean) 4" as well as on an #nglish 4"
with the language pac installed.
&riting a high level test plan for 29byte support will require some nowledge of the application and its
architecture.
What is the difference between software fault and software failure?
"oftware failure occurs when the software does not do what the user e$pects to see. "oftware fault% on
the other hand% is a hidden programming error.
A software fault becomes a software failure only when the e$act computation conditions are met% and the
faulty portion of the code is e$ecuted on the CF@. 'his can occur during normal usage. 4r% when the
software is ported to a different hardware platform. 4r% when the software is ported to a different complier.
4r% when the software gets e$tended.
before creatin% test cases to =brea& the syste(=5 a few principles have to be observed>
'esting should be based on user requirements. 'his is in order to uncover any defects that might cause
the program or system to fail to meet the client(s requirements.
'esting time and resources are limited. Avoid redundant tests.
2t is impossible to test everything. #$haustive tests of all possible scenarios are impossible% simple
because of the many different variables affecting the system and the number of paths a program flow
might tae.
@se effective resources to test. 'his represents use of the most suitable tools% procedures and individuals
to conduct the tests. 'he test team should use tools that they are confident and familiar with. 'esting
procedures should be clearly defined. 'esting personnel may be a technical group of people independent of
the developers.
'est planning should be done early. 'his is because test planning can begin independently of coding and as
soon as the client requirements are set.
'esting should begin at the module. 'he focus of testing should be concentrated on the smallest
programming units first and then e$pand to other parts of the system.
&e loo at software testing in the traditional (procedural) sense and then describe some testing strategies
and methods used in 4b7ect 4riented environment. &e also introduce some issues with software testing in
both environments.
Would li&e to &now whether ,lac& ,o' testin% techni2ues li&e ,oundary ?alue Analysis and
E2uivalence 8artitionin% 4 durin% which phases of testin% are they used5if possible with
e'a(ples ?
Answer1.
Also 3oundary 1alue Analysis and #quivalence Fartitioning can be used in unit or component testing% and
generally is used in system testing
#$ample% you have a module designed to wor out the ta$ to be paid.
An employee has [HKKK of salary ta$ free. 'he ne$t [1GKK is ta$ed at 1KL
'he ne$t [2RKKK is ta$ed at 22L
Any further amount is ta$ed at HKL
Bou must define test cases that e$ercise valid and invalid equivalence classes.
Any value lower than HKKK is ta$ free
Any value between HKKK and GGKK must paid 1KL
Any value between GGK1 and ;;GKK must paid 22L
Any value bigger than ;;GKK must paid HKL
And the boundary values are. HKKK% HKK1% GGK1% ;;GK1
Answer2.
'his 3oundary value analysis and #quivalence partitioning is used to prepare the positive and negative
type test cases.
#quivalence partitioning. 2f you want to validate the te$t bo$ which accepts the value between 2KKK to
1KKKK % then the test case input is partitioned as the following way
1. \X2KKK
2. IX2KKK and \X1KKKK
;. I1KKKK
'he boundary 1alues analysis is checing the input values on boundaries. 2< the above case it can
checed with whether the input values is on the boundary or above the boundary or in low boundary.
'est Case -esign
'est cases should be designed in such a way as to uncover quicly and easily as many errors as possible.
'hey should 8e$ercise8 the program by using and producing inputs and outputs that are both correct and
incorrect. 1ariables should be tested using all possible values (for small ranges) or typical and out9of9
bound values (for larger ranges). 'hey should also be tested using valid and invalid types and conditions.
Arithmetical and logical comparisons should be e$amined as well% again using both correct and incorrect
parameters. 'he ob7ective is to test all modules and then the whole system as completely as possible
using a reasonably wide range of conditions.
+ow to use (ethods/techni2ues to test the bandwidth usa%e of a client/server application?
3andwidth @tili5ation.
3asically at the client9server model you will be most concerned about the bandwidth usage if your
application is a web based one. 2t surely is a part of concern when the throughput and the data transfer
comes into the picture.
2 suggest you to use the +adview(s &ebload for the Aoad and "tress testing tool for the same.
Available at the demoware.. you can record the scenarios of the normal user over the variable connection
speed and then run it for hours to now about the bandwidth utilisation and the throughput and data
trasfer rate% hits per sec% etc... there is a huge list of parameters which can be tested over a n no of
combinations..
+ow do test case te(plates loo& li&e?
"oftware test case templates are blan documents that describe inputs% actions% or events% and their
e$pected results% in order to determine if a feature of an application is woring correctly. 'est case
templates contain all particulars of test cases. *or e$ample% one test case template is in the form of a P9
column table% where column 1 is the 8test case 2- number8% column 2 is the 8test case name8% column ; is
the 8test ob7ective8% column H is the 8test conditions/setup8% column G is the 8input data
requirements/steps8% and column P is the 8e$pected results8.
All documents should be written to a certain standard and template. &hyD 3ecause standards and
templates do help to maintain document uniformity. Also because they help you to learn where
information is located% maing it easier for users to find what they want. Also because% with standards and
templates% information is not be accidentally omitted from documents.
+ow to insert a chec& point to a i(a%e to chec& enable property in QT8?
Answer1.
A" you are saying that the all images are as push button than you can chec the property enabled or
disabled. 2f you are not able to find that property than go to ob7ect repository for that ob7ecct and clic on
add remove to add the available properties to that ob7ect. Aet me now if that wors. And if you tae it as
image than you need to chec visible or invisible property tht also might help you are there are no enable
or disable properties for the image ob7ect.
Answer2.
'he 2mage Checpoint does not have any property to verify the enable/disable property.
4ne thing you need to chec is.
) *ind out form the -eveloper if he is showing different images for activating/deactiving i.e greyed out
image. 'hat is the only way a developer can show deactivate/activate if he is using an 8image8. #lse he
might be using a button having a headsup with an image.
) 2f it is a button used to display with the headsup as an image you woudl need to use the ob7ect
Froperties as a checpoint.
+ow do you write test cases?
&hen 2 write test cases% 2 concentrate on one requirement at a time. 'hen% based on that one
requirement% 2 come up with several real life scenarios that are liely to occur in the use of the application
by an end user.
&hen 2 write test cases% 2 describe the inputs% action% or event% and their e$pected results% in order to
determine if a feature of an application is woring correctly. 'o mae the test case complete% 2 also add
particulars e.g. test case identifiers% test case names% ob7ectives% test conditions (or setups)% input data
requirements (or steps)% and e$pected results.
Additionally% if 2 have a choice% 2 lie writing test cases as early as possible in the development life cycle.
&hyD 3ecause% as a side benefit of writing test cases% many times 2 am able to find problems in the
requirements or design of an application. And% because the process of developing test cases maes me
completely thin through the operation of the application.
"iferences ,etween Syste( Testin% and @ser Acceptance Testin%?
Answer1.
system testing. 'he process of testing an integrated system to verify that it meets specified requirements.
acceptance testing. *ormal testing with respect to user needs% requirements% and business processes
conducted to determine whether or not a system satisfies the acceptance criteria and to enable the user%
customers or other authori5ed entity to determine whether or not to accept the system.
*irst% 2 don0t classify the incidents or defects regarding the phase the software development process or
testing% 2 prefer classify them regarding their type% e. g. +equeriments% features and functionality%
structural bugs% data% integration% etc 'he value of categorising faults is that it helps us to focus our
testing effort where it is most important and we should have distinct test activietis that adrress the
problems of poor requerimients% structure% etc.
Bou don0t do @ser Acceptance 'est only because the software is deliveredE 'ae care about the concepts of
testingE
Answer2.
2n my company we do not perform user acceptance testing% our clients do. 4nce our system testing is
done (and other validation activities are finished) the software is ready to ship. 'herefore any bug found in
user acceptance testing would be issued a tracing number and taen care of in the ne$t release. 2t would
not be counted as a part of the system test.
Answer;.
'his is what i feel is user acceptance testing% i hope u find it useful. -efinition.
@ser Acceptance testing is a formal testing conducted to determine whether a software satisfies it(s
acceptance criteria and to enable the buyer to determine whether to accept the system.
4b7ective.
@ser Acceptance testing is designed to determine whether the software is fit for the user to use. And also
to determine if the software fits into user(s business processes and meets his/her needs.
#ntry Criteria.
#nd of development process and after the software has passed all the tests to determine whether it meets
all the predetermined functionality% performance and other quality criteria.
Exit Criteria:
After the verification that the docs delivered are adequate and consistent with the executable system. Software system meets all the
requirements of the customer
Deliverables:
User Acceptance est !lan
User Acceptance estcases
User "uides#docs
User Acceptance estreports
Answer$:
System estin": Done by %A at developemnt end.&t is done after inter"ration is complete and all inte"ration !'#!(#!) bu"s are fixed.
the code is free*ed. +o more code chan"es are ta,en. hen All the requirements are tested and all the inter"ration bu"s are verified.
UA: Done by %A-trained li,e end users .. All the requiement are tested and also whole system is verified and validated.
What is the difference between a test plan and a test scenario?
Difference number ': A test plan is a document that describes the scope/ approach/ resources/ and schedule of intended testin"
activities/ while a test scenario is a document that describes both typical and atypical situations that may occur in the use of an
application.
Difference number (: est plans define the scope/ approach/ resources/ and schedule of the intended testin" activities/ while test
procedures define test conditions/ data to be used for testin"/ and expected results/ includin" database updates/ file outputs/ and report
results.
Difference number ): A test plan is a description of the scope/ approach/ resources/ and schedule of intended testin" activities/ while a
test scenario is a description of test cases that ensure that a business process flow/ applicable to the customer/ is tested from end to end.
Can you give me an example on reliability testing?
0or example/ our products are defibrillators. 0rom direct contact with customers durin" the requirements "atherin" phase/ our sales
team learns that a lar"e hospital wants to purchase defibrillators with the assurance that 11 out of every '22 shoc,s will be delivered
properly.
&n this example/ the fact that our defibrillator is able to run for (32 hours without any failure in order to demonstrate the reliability/ is
irrelevant to these customers. &n order to test for reliability we need to translate terminolo"y that is meanin"ful to the customers into
equivalent delivery units/ such as the number of shoc,s. herefore we describe the customer needs in a quantifiable manner/ usin" the
customer4s terminolo"y. 0or example/ our quantified reliability testin" "oal becomes as follows: 5ur defibrillator will be considered
sufficiently reliable if '2 -or fewer. failures occur from '/222 shoc,s.
hen/ for example/ we use a test # analy*e # fix technique/ and couple reliability testin" with the removal of errors. 6hen we identify a
failed delivery of a shoc,/ we send the software bac, to the developers/ for repair. he developers build a new version of the software/
and then we deliver another '/222 shoc,s -into dummy resistor loads.. 6e trac, failure intensity -i.e. failures per '/222 shoc,s. in
order to "uide our reliability testin"/ and to determine the feasibility of the software release/ and to determine whether the software
meets our customers7 reliability requirements.
Need function to find all the positions?
Ex: a strin" 8abcd/ ef"h/i"ht8 .
6ant brea, this strin" based on the criteria here ever found the..
Answer':
And return the delimited fields as a list of strin"9 Sound li,e a perl split function. his could be built on one of your own containin":
: ; ##,noc,ed this to"ether in a few min. & am sure there is a much more efficent way of doin" thin"s
: ; ##but this is with the coblin" to"ether of several built in functions
:<; =&S 50 S>&+? Split-S>&+? sDelim/ S>&+? sData.
: ; =&S 50 S>&+? ls>eturn
: ; S>&+? sSe"ment
:<; while @atchStr-8ABsDelimCA8/ sData.
: ; sSe"ment D ?et0ield-sData/ sDelim/ '.
: ; =istAppend-ls>eturn/ rim-sSe"ment..
: ; ##crude chun,in":
: ; sSe"ment ED 8/8
: ; sData D ?et0ield-sData/ sSe"ment/ (.
:<; if =en-sData. F 2
: ; =istAppend-ls>eturn/ rim-sData..
: ; return ls>eturn
Answer(:
Gou could use somethin" li,e this.... hope & am understandin" the problem
:E; testcase '-.
: ; strin" sest D 8hello/ there & am happy8
: ; strin" sest' D -?et0ield -sest/ 8/8/ (..
: ; !rint-sest'.
: ;
: ; his !rints 8there & am happy8
: ; ?et0ield-sest/8/8'.. would !rint hello/ etc....
Answer):
Helow is the function which return all fields -list of Strin"..
:E; =&S 50 S>&+? Converto=ist -S>&+? sStr/ S>&+? sDelim.
: ; &+E?E> i&ndexD '
: ; =&S 50 S>&+? lsStr
: ; S>&+? so,en D ?et0ield -sStr/ sDelim/ i&ndex.
: ;
:E; if -i&ndex DD ' II so,en DD 88.
: ; i&ndex D i&ndex E '
: ; so,en D ?et0ield -sStr/ sDelim/ i&ndex.
: ;
:E; while -so,en JD 88.
: ; =istAppend -lsStr/ so,en.
: ; i&ndex D i&ndexE'
: ; so,en D ?et0ield -sStr/ sDelim/ i&ndex.
: ; return lsStr
What is the difference between monkey testing and smoke testing?
Difference number ': @on,ey testin" is random testin"/ and smo,e testin" is a nonrandom testin". Smo,e testin" is nonrandom
testin" that deliberately exercises the entire system from end to end/ with the the "oal of exposin" any maKor problems.
Difference number (: @on,ey testin" is performed by automated testin" tools/ while smo,e testin" is usually performed manually.
Difference number ): @on,ey testin" is performed by 8mon,eys8/ while smo,e testin" is performed by s,illed testers.
Difference number $: 8Smart mon,eys8 are valuable for load and stress testin"/ but not very valuable for smo,e testin"/ because they
are too expensive for smo,e testin".
Difference number 3: 8Dumb mon,eys8 are inexpensive to develop/ are able to do some basic testin"/ but/ if we used them for smo,e
testin"/ they would find few bu"s durin" smo,e testin".
Difference number L: @on,ey testin" is not a thorou"h testin"/ but smo,e testin" is thorou"h enou"h that/ if the build passes/ one can
assume that the pro"ram is stable enou"h to be tested more thorou"hly.
Difference number M: @on,ey testin" either does not evolve/ or evolves very slowly. Smo,e testin"/ on the other hand/ evolves as the
system evolves from somethin" simple to somethin" more thorou"h.
Difference number N: @on,ey testin" ta,es 8six mon,eys8 and a 8million years8 to run. Smo,e testin"/ on the other hand/ ta,es much
less time to run/ i.e. from a few seconds to a couple of hours.
It's a good thing to share test cases with customers
That's generally a good thing but the !uestion is why do they want to see them?
!otential problems are that they may be considerin" chan"in" outsourcin" firms and want to use the test cases elsewhere. &f that can
be prevented/ please do so.
Another problem is that they want to micro mana"e your testin" efforts. &t7s one thin" to audit your wor, to prove to themselves that
you7re doin" a "ood Kob/ it7s an entirely different matter if they intend to tell you that you don7t have enou"h test covera"e on the
activity of module foo and far too much covera"e on module bar/ please correct it.
Another issue may be that they are see,in" liti"ation and they need proof that you were ne"li"ent in some area of testin".
&t7s never a bad thin" to have your customer wantin" to be involved/ unless you7re a lar"e company and this is a small -in terms of
sales. customer.
6hat are your concerns about this9 Can you "ive more information on your situation and the customer7s9
ell me about daily builds and smo,e tests.
he idea is to build the product every day/ and test it every day. he software development process at @icrosoft and many other
software companies requires daily builds and smo,e tests. Accordin" to their process/ every day/ every sin"le file has to be compiled/
lin,ed/ and combined into an executable pro"ramO and then the pro"ram has to be 8smo,e tested8.
Smo,e testin" is a relatively simple chec, to see whether the product 8smo,es8 when it runs.
!lease note that you should add revisions to the build only when it ma,es sense to do so. Gou should to establish a build "roup/ and
build dailyO set your own standard for what constitutes 8brea,in" the build8/ and create a penalty for brea,in" the build/ and chec, for
bro,en builds every day.
&n addition to the daily builds/ you should smo,e test the builds/ and smo,e test them Daily. Gou should ma,e the smo,e test evolve/
as the system evolves. Gou should build and smo,e test Daily/ even when the proKect is under pressure.
hin, about the many benefits of this processJ he process of daily builds and smo,e tests minimi*es the inte"ration ris,/ reduces the
ris, of low quality/ supports easier defect dia"nosis/ improves morale/ enforces discipline/ and ,eeps pressure coo,er proKects on trac,.
&f you build and smo,e test DA&=G/ success will come/ even when you7re wor,in" on lar"e proKectsJ
"ow to #ead data from the Telnet session?
Declared
:E; window Dialo"Hox !utty
: ; ta" 8A < !uG8
: ;
: ; ## Capture the screen contents and return as a list of strin"s
:E; =&S 50 S>&+? "etScreenContents-.
: ;
: ; =&S 50 S>&+? ClipboardContents
: ;
: ; ## open the system menu and select copy all to clipboard menu command
: ; this.ypePeys-8QA=<S!ACEFo8.
: ;
: ; ## "et the clipboard contents
: ;
: ; ClipboardContents D Clipboard."etext-.
: ; return ClipboardContents
& then created a function that searches the screen contents for the required data to validate. his wor,s fine for me. Rere it is to study.
Rope it may help
void Chec,5ut!ut-strin" sError@essa"e.
: ;!utty.setActive -.
: ;
: ; ## Capture screen contents
: ; lsScreenContents D !utty.?etScreenContents -.
: ; Sleep-'.
: ; ## rim Screen Contents
: ; lsScreenContents D rimScreenContents -lsScreenContents.
: ; Sleep-'.
:<; if -sHatchSuccess DD 8Ges8.
:<; if -=ist0ind -lsScreenContents/ 8HU&=D 0A&=ED8..
: ; =o"Error-8!rocess should not have failed.8.
:<; if -=ist0ind -lsScreenContents/ 8HU&=D SUCCESS0U=8..
: ; !rint-8Successful8.
: ; brea,
: ; ## Chec, to see if launcher has finished
:<; else
:<; if -=ist0ind -lsScreenContents/ 8HU&=D 0A&=ED8. DD 2.
: ; =o"Error-8Error should have failed.8.
: ; brea,
:<; else
: ; ## Chec, for Date Conversion Error
:<; if -=ist0ind -lsScreenContents/ sError@essa"e. DD 2.
: ; =o"Error -8Error handle8.
: ; !rint-8Expected < BsError@essa"eC8.
: ; =ist!rint-lsScreenContents.
: ; brea,
:<; else
: ; brea,
: ;
: ; ## >aise exception if ,!latform not equal to windows or putty
:E; default
: ; raise '/ 8Unable to run console: < !lease specify settin"8
: ;
What is the difference between system testing and integration testing?
8System testin"8 is a hi"h level testin"/ and 8inte"ration testin"8 is a lower level testin". &nte"ration testin" is completed first/ not the
system testin". &n other words/ upon completion of inte"ration testin"/ system testin" is started/ and not vice versa.
0or inte"ration testin"/ test cases are developed with the express purpose of exercisin" the interfaces between the components. 0or
system testin"/ the complete system is confi"ured in a controlled environment/ and test cases are developed to simulate real life
scenarios that occur in a simulated real life test environment.
he purpose of inte"ration testin" is to ensure distinct components of the application still wor, in accordance to customer
requirements. he purpose of system testin" is to validate an application7s accuracy and completeness in performin" the functions as
desi"ned/ and to test all functions of the system that are required in real life.
"ow to trace fixed bug in test case?
Answer':
he fixed defects can be trac,ed in the defect trac,in" tool. & thin, it is out of scope of a test case to maintain this.
he defect trac,in" tool should indicate that the problem has been fixed/ and the associated test case now has a passin" result.
&f and when you report test results for this test cycle/ you should provide this sort of informationO i.e./ test failed/ problem report
written/ problem fixed/ test passed/ etc...
Answer(:
As usin" Sira -li,e Hu"*illa. to mana"e your testcases as well as your bu"s. 6hen a test discovers a bu"/ you will lin, the two/
mar,in" the test as 8in wor,8 and 8waitin" for bu" T8. +ow/ when the developer resolves the bu" and you retest it/ you see the lin, to
the tescase and retest#close it.
What is the difference between performance testing and load testing?
=oad testin" is a blan,et term that is used in many different ways across the professional software testin" community. he term/ load
testin"/ is often used synonymously with stress testin"/ performance testin"/ reliability testin"/ and volume testin". =oad testin"
"enerally stops short of stress testin". Durin" stress testin"/ the load is so "reat that errors are the expected results/ thou"h there is "ray
area in between stress testin" and load testin".
$fter the migration done how to test the application %&rontend hasn't changed 'ust the database changed(
Answer':
Gou can concentrate only on those testcases which involve DH transactions li,e insert/update/delete etc.
Answer(:
0ocus on the database tests/ but it7s important to analy*e the differences between the two schemas. Gou can7t Kust focus on the front
end. Also/ be careful to loo, for shortcuts that the DHAs may be ta,in" with the schema.
6hat is the difference between reliability testin" and load testin"9
he term/ reliability testin"/ is often used synonymously with load testin". =oad testin" is a blan,et term that is used in many different
ways across the professional software testin" community. =oad testin" "enerally stops short of stress testin". Durin" stress testin"/ the
load is so "reat that errors are the expected results/ thou"h there is "ray area in between stress testin" and load testin".
)ome general guidelines on what to test for web based applications*
'. +avi"ation: Users move to and from pa"es/ clic, on lin,s/ clic, on ima"es -thumbnails./ etc. +avi"ation in a 6ebSite shoud be
quic, and error free.
(. Server >esponse. Row fast the 6ebSite host responds influences whether a user -i.e. someone on the browser. moves on or "ives
up.
). &nteraction I 0eedbac,. 0or passive/ content<only sites the only real quality issue is availability. 0or a 6ebSite that interacts with
the user/ the bi" factor is how fast and how reliable that interaction is.
$. Concurrent Users. Do multiple users interact on a 6ebSite9 Can they "et in each others7 way9 6hile 6ebSites often resemble
client#server structures/ with multiple users at multiple locations a 6ebSite can be much different/ and much more complex/ than
complex applications
3. Hrowser &ndependent. ests should be realistic/ but not be dependent on a particular browser
L. +o Hufferin"/ Cachin". =ocal cachin" and bufferin" << often a way to improve apparent performance << should be disabled so that
timed experiments are a true measure of the Hrowser response time.
M. 0onts and !references. @ost browsers support a wide ran"e of fonts and presentation preferences
N. 5bKect @ode. Edit fields/ push buttons/ radio buttons/ chec, boxes/ etc. All should be treatable in obKect mode/ i.e. independent of
the fonts and preferences.
1. !a"e Consistency. &s the entire pa"e identical with a prior version9 Are ,ey parts of the text the same or different9
'2. able/ 0orm Consistency. Are all of the parts of a table or form present9 Correctly laid out9 Can you confirm that selected texts are
in the 8ri"ht place8.
''. !a"e >elationships. Are all of the lin,s on a pa"e the same as they were before9 Are there new or missin" lin,s9 Are there any
bro,en lin,s9
'(. !erformance Consistency/ >esponse imes. &s the response time for a user action the same as it was -within a ran"e.9
'). &ma"e 0ile Si*e. 0ile si*e should be closely examined when selectin" or creatin" ima"es for your site. his is particularly
important when your site is directed to an audience that may not enKoy the hi"h<bandwidth and fast connection speeds available
'$. Avoid the use of R@= 8frames8. he problems with frames<based site desi"ns are well documented/ includin"O the inability to
boo,mar, subcate"ories of the site/ difficulty in printin" frame cell content/ disablin" the 6eb browser7s 8bac,8 button as a navi"ation
aid.
'3. Security. Ensure data is encrypted before transferrin" sensitive information/ wherever required. est user authentication
thorou"hly. Ensure all bac,doors and test lo"ins are disabled before "oin" live with the web application.
'L. Sessions. Ensure session validity is maintained throu"hout a web transasction/ for e.". fillin" a webform that spans over several
webpa"es. 0orms should retain information when usin" the 7bac,7 button wherever required for user convenience. At the same time/
forms need to be reset wherever security is an issue/ li,e the password fields/ etc.
'M. Error handilin". 6eb navi"ation should be quic, and error free. Rowever/ sometimes errors cannot be avoided. &t would be a "ood
idea to have a standard error pa"e that handles all errors. his is cleaner than displayin" the $2$ pa"e. After displayin" the error pa"e/
users can then be automatically redirected to the home pa"e or any other relevant pa"e. At this same time/ this error can also be lo""ed
and a messa"e can be sent to notify the admin.
What is the difference between volume testing and load testing?
he term/ volume testin"/ is often used synonymously with load testin". =oad testin" is a blan,et term that is used in many different
ways across the professional software testin" community.
What types of testing can you tell me about?
Each of the followin"s represents a different type of testin": blac, box testin"/ white box testin"/ unit testin"/ incremental testin"/
inte"ration testin"/ functional testin"/ system testin"/ end<to<end testin"/ sanity testin"/ re"ression testin"/ acceptance testin"/ load
testin"/ performance testin"/ usability testin"/ install#uninstall testin"/ recovery testin"/ security testin"/ compatibility testin"/
exploratory testin"/ ad<hoc testin"/ user acceptance testin"/ comparison testin"/ alpha testin"/ beta testin"/ and mutation testin".
+, which test cannot be automated?
a. !erformance testin"
b. >e"resssssion
c. user interface
d.none
-, acceptence test plan is prepared from?
a. S>S
b. R=D
c. DDDDdd
d.U=D#U>D
., which is the test case design methodology?
a. 6H
b: >e"ression
c: none
/, when will u start testing
a: After codin"
b: >equirements "atherin"
0,does test plan contains bug tracing procedure and
reportin" procedure9
1, compatability testing uses
aO All S#6 components
b: all R#w components
cO all networ,in" components
dO A I H
e: A/ H/ C
2, which software model is easy and most efffffective
when compared to others9
a. 6aterfall
b.interactive waterfall
c. Spiral
d. !rototypin"
3, whioch is not system level testing
a. system testin"
b. performance testin"
c. instalable testin"
d. none
4, why do u need testers?
a: they thin, in clients view
b: bettttter than developers
c. they thin, in processss view
d. none
+5* what is 6uality $ssssurance?
a. process
b. system
c. business
d. all
Ans : '. !erformance estin"
(. S>S
). dont ,now
$. b. after requirement "atherin"
3. Ges est !lan will definitely define the procedure for reportin" of bu"s.
L. e: A/ H/ C
M. b.interactive waterfall
N. d. none
1. the options "iven are not appropriate.
'2. a. process
What testing roles are standard on most testing pro'ects?
A: Dependin" on the or"ani*ation/ the followin" roles are more or less standard on most testin" proKects: esters/ est En"ineers/
est#%A eam =ead/ est#%A @ana"er/ System Administrator/ Database Administrator/ echnical Analyst/ est Huild @ana"er and
est Confi"uration @ana"er.
Dependin" on the proKect/ one person may wear more than one hat. 0or instance/ est En"ineers may also wear the hat of echnical
Analyst/ est Huild @ana"er and est Confi"uration @ana"er.
What is $C" and N$C"$?
ACR< Automatic clearin" house
ACR. A nationwide electronic funds transfer networ, which enables participatin" financial institutions to distribute electronic credit
and debit entries to ban, accounts and to settle such entries.
+ACRA:
A membership or"ani*ation that provides mar,etin" and education assistance and establishes the rules/ standards and procedures that
enable 0inancial &nstitutions to exchan"e ACR payments on a national basis.
What is the role of documentation in 6$?
Documentation plays a critical role in %A. %A practices should be documented/ so that they are repeatable. Specifications/ desi"ns/
business rules/ inspection reports/ confi"urations/ code chan"es/ test plans/ test cases/ bu" reports/ user manuals should all be
documented. &deally/ there should be a system for easily findin" and obtainin" of documents and determinin" what document will
have a particular piece of information. Use documentation chan"e mana"ement/ if possible.
Is there a way to automate 789 file comparison?
Use diff called from a scriptin" lan"ua"e and output the results to a file.
or
Usin" PDiff)
or
Usin" HHEdit in @AC
"ow do you introduce a new software 6$ process?
&t depends on the si*e of the or"ani*ation and the ris,s involved. 0or lar"e or"ani*ations with hi"h<ris, proKects/ a serious mana"ement
buy<in is required and a formali*ed %A process is necessary. 0or medium si*e or"ani*ations with lower ris, proKects/ mana"ement and
or"ani*ational buy<in and a slower/ step<by<step process is required. ?enerally spea,in"/ %A processes should be balanced with
productivity/ in order to ,eep any bureaucracy from "ettin" out of hand. 0or smaller "roups or proKects/ an ad<hoc process is more
appropriate. A lot depends on team leads and mana"ers/ feedbac, to developers and "ood communication is essential amon"
customers/ mana"ers/ developers/ test en"ineers and testers. >e"ardless the si*e of the company/ the "reatest value for effort is in
mana"in" requirement processes/ where the "oal is requirements that are clear/ complete and testable.
What's re!uitrement of :ug tracking tool?
'. Should maintain version history
(. 0ile attachement
). Controlled access -user7s =evel.
$. Hu" Ristory
3. >eports and @etrics
L.rac, bu"s and code chan"es
M.Communicate with teammates
N.Submit and review patches
1. @ana"e quality assurance -%A.
'2.lexible wor,flow mana"ement/ defect and chan"e trac,in" across the application life cycle
Hu" trac,in" tool:
>ational Clear%uest << expensive
Hu"*illa is 0ree and betterJJ
@antis < opensource
When do you choose automated testing?
0or lar"er proKects/ or on"oin" lon"<term proKects/ automated testin" can be valuable. Hut for small proKects/ the time needed to learn
and implement the automated testin" tools is usually not worthwhile. Automated testin" tools sometimes do not ma,e testin" easier.
5ne problem with automated testin" tools is that if there are continual chan"es to the product bein" tested/ the recordin"s have to be
chan"ed so often/ that it becomes a very time<consumin" tas, to continuously update the scripts. Another problem with such tools is
that the interpretation of the results -screens/ data/ lo"s/ etc.. can be a time<consumin" tas,.
What a Coverage 8atrix is? or What is a traceability matrix?
Answer':
&t is a mappin" of one baselined obKect to another. 0or testers/ the most common documents to be lin,ed in the manner are a
requirements document and the written test cases for that document.
&n order to facilitate this/ testers can add an extra column to their test cases listin" the requirement bein" tested.
he requirements matrix is usually stored in a spreadsheet. &t contains the test ids down the left side and the requirements ids across
the top. 0or each test/ you place a mar, in the cell under the headin" for that requirement it is desi"ned to test. he "oal is to find out
which requirements are under<tested and which are either over tested or which are so lar"e that too many tests have to be written to
adequately test it.
Answer(:
'he traceability matri$ means mapping of all the wor products (various design docs% testing docs) to
requirements.
Is white box testing different from unit testing?
Unit testin" is one element of white box testin".
;o automated testing tools make testing easier?
Ges and no.
0or lar"er proKects/ or on"oin" lon"<term proKects/ they can be valuable. Hut for small proKects/ the time needed to learn and
implement them is usually not worthwhile.
A common type of automated tool is the record#playbac, type. 0or example/ a test en"ineer clic,s throu"h all combinations of menu
choices/ dialo" box choices/ buttons/ etc. in a ?U& and has an automated testin" tool record and lo" the results. he recordin" is
typically in the form of text/ based on a scriptin" lan"ua"e that the testin" tool can interpret.
&f a chan"e is made -e.". new buttons are added/ or some underlyin" code in the application is chan"ed./ the application is then re<
tested by Kust playin" bac, the recorded actions and compared to the lo""ed results in order to chec, effects of the chan"e.
5ne problem with such tools is that if there are continual chan"es to the product bein" tested/ the recordin"s have to be chan"ed so
often that it becomes a very time<consumin" tas, to continuously update the scripts.
Another problem with such tools is the interpretation of the results -screens/ data/ lo"s/ etc.. that can be a time<consumin" tas,.
"o to write )oftware #e!uirement )epcification %)#)( document for <rade Card )ystem?
S>S document is very important to "ive information what the proKect is "oin" to do and what it is assumin" in advance.
below is some idea about it.
in S>S document followin" points should be included.
'. !roKect aim.
(. !roKect obKectives.
). !roKect scope
$. !rocess to be followed.
3. !roKect Deliverables< it includes documents to be submitted and other plans or proKect prototypes.
L. >equirements in short.
$ small !uery, a numbe of %*t( script files which contains a number of test cases* Need to call a user defined method in all the
%*t( script files*
=roblem, "ow to do that*
)econd is, if this is possible that when one test case is run successfully can I put in the condition that if it is successfull go to
testcase - else go to test case .*
Third is, "ow can I schedule the different testcases in a %*t( test script so that all the test cases it contains run one after another*
Answer for !roblem: Row to do that:
T Sust ta,e instance for your class and call the method thru that instance.
Answer for (nd and )rd queries:
.t file
DDDDDDD
:<; testcase tc'-. appstate none
: ; !rint-8his is tc'8.
:<; testcase tc(-. appstate none
: ; !rint-8his is tc(8.
:<; testcase tc)-. appstate none
: ; !rint-8his is tc)8.
call your test cases under main function as below.
:<; main-.
: ;
:<; tc'-.
:<; if ?etests!assedCount - .JD2 ## Executin" testcases tc( and tc) when testcase tc' is passed only.
: ; tc(-.
: ; tc)-.
Why are there so many software bugs?
?enerally spea,in"/ there are bu"s in software because of unclear requirements/ software complexity/ pro"rammin" errors/ chan"es in
requirements/ errors made in bu" trac,in"/ time pressure/ poorly documented code and#or bu"s in tools used in software development.
A here are unclear software requirements because there is miscommunication as to what the software should or shouldn7t do.
A Software complexity. All of the followin"s contribute to the exponential "rowth in software and system complexity: 6indows
interfaces/ client<server and distributed applications/ data communications/ enormous relational databases and the sheer si*e of
applications.
A !ro"rammin" errors occur because pro"rammers and software en"ineers/ li,e everyone else/ can ma,e mista,es.
A As to chan"in" requirements/ in some fast<chan"in" business environments/ continuously modified requirements are a fact of life.
Sometimes customers do not understand the effects of chan"es/ or understand them but request them anyway. And the chan"es require
redesi"n of the software/ reschedulin" of resources and some of the wor, already completed have to be redone or discarded and
hardware requirements can be effected/ too.
A Hu" trac,in" can result in errors because the complexity of ,eepin" trac, of chan"es can result in errors/ too.
A ime pressures can cause problems/ because schedulin" of software proKects is not easy and it often requires a lot of "uesswor, and
when deadlines loom and the crunch comes/ mista,es will be made.
A Code documentation is tou"h to maintain and it is also tou"h to modify code that is poorly documented. he result is bu"s.
Sometimes there is no incentive for pro"rammers and software en"ineers to document their code and write clearly documented/
understandable code. Sometimes developers "et ,udos for quic,ly turnin" out code/ or pro"rammers and software en"ineers feel they
cannot have Kob security if everyone can understand the code they write/ or they believe if the code was hard to write/ it should be hard
to read.
A Software development tools / includin" visual tools/ class libraries/ compilers/ scriptin" tools/ can introduce their own bu"s. 5ther
times the tools are poorly documented/ which can create additional bu"s.
What are Test Cases Test )uites Test )cripts and Test )cenarios %or )cenaria(?
A test case is usually a sin"le step/ and its expected result/ alon" with various additional pieces of information. &t can occasionally be a
series of steps but with one expected result or expected outcome. he optional fields are a test case &D/ test step or order of execution
number/ related requirement-s./ depth/ test cate"ory/ author/ and chec, boxes for whether the test is automatable and has been
automated. =ar"er test cases may also contain prerequisite states or steps/ and descriptions. A test case should also contain a place for
the actual result. hese steps can be stored in a word processor document/ spreadsheet/ database or other common repository. &n a
database system/ you may also be able to see past test results and who "enerated the results and the system confi"uration used to
"enerate those results. hese past results would usually be stored in a separate table.
he most common term for a collection of test cases is a test suite. he test suite often also contains more detailed instructions or "oals
for each collection of test cases. &t definitely contains a section where the tester identifies the system confi"uration used durin" testin".
A "roup of test cases may also contain prerequisite states or steps/ and descriptions of the followin" tests.
Collections of test cases are sometimes incorrectly termed a test plan. hey may also be called a test script/ or even a test scenario.
A test plan is the approach that will be used to test the system/ not the individual tests.
@ost companies that use automated testin" will call the code that is used their test scripts.
A scenario test is a test based on a hypothetical story used to help a person thin, throu"h a complex problem or system. hey can be as
simple as a dia"ram for a testin" environment or they could be a description written in prose. he ideal scenario test has five ,ey
characteristics. &t is -a. a story that is -b. motivatin"/ -c. credible/ -d. complex/ and -e. easy to evaluate. hey are usually different
from test cases in that test cases are sin"le steps and scenarios cover a number of steps. est suites and scenarios can be used in concert
for complete system tests. See
An &ntroduction to Scenario estin"
Scenario testin" is similar to/ but not the same as session<based testin"/ which is more closely related to exploratory testin"/ but the
two concepts can be used in conKunction.
Scenario testin" is similar to/ but not the same as session<based testin"/ which is more closely related to exploratory testin"/ but the
two concepts can be used in conKunction. See Session<Hased est @ana"ement
6hat7s Exploratory est
A est !lan "ives detailed testin" information/ includin"
Scope of testin"
Schedule
est Deliverables
>elease Criteria
>is,s and Contin"encies
<ive me five common problems that occur during software development*
!oorly written requirements/ unrealistic schedules/ inadequate testin"/ addin" new features after development is underway and poor
communication.
'. >equirements are poorly written when requirements are unclear/ incomplete/ too "eneral/ or not testableO therefore there will be
problems.
(. he schedule is unrealistic if too much wor, is crammed in too little time.
). Software testin" is inadequate if none ,nows whether or not the software is any "ood until customers complain or the system
crashes.
$. &t7s extremely common that new features are added after development is underway.
3. @iscommunication either means the developers don7t ,now what is needed/ or customers have unrealistic expectations and
therefore problems are "uaranteed.