|
Software QA/Testing Technical FAQs
Part:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
Why back-end testing is required, if we are going to
check the front-end. What errros/bugs we are missing
out by not doing back-end testing.
Why we need to do unit testing, if all the features
are being tested in System testing. What extra things
are tested in unit testing, which can not be tested in
System testing.
Answer1:
Assume that you're thinking client-server or web. If you test the
application on the front end only you can see if the data was stored and
retrievd correctly. You can't see if the servers are in an error state or
not. many server processes are monitored by another process. If they crash,
they are restarted. You can't see that without looking at it.
The data may not be stored correctly either but the front end may have
cached data lying around and it will use that instead. The least you should
be doing is verifying the data as stored in the database.
It 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:
Back-End testing : Basically the requirement of this testing depends on ur
project. like Say if ur project is .Ticket booking system,Front end u will provided with
an Interface , where u can book the ticket by giving the appropriate details
( Like Place to go, and Time when u wanna go etc..). It will have a Data
storage system (Database or XL sheet etc) which is a Back end for storing
details entered by the user.
After submitting the details ,U might have provided with a correct
acknowledgement.But in back end , the details might not updated correctly
in Database becoz of wrong logic development. Then that will cause a major
problem.
and regarding Unit level testing and System testing
Unit level testing is for testing the basic checks whether the application
is working fyn with the basic requirements.This will be done by developers
before delivering to the QA.In System testing , In addition to the unit
checks ,u will be performing all the checks ( all possible integrated checks
which required) .Basically this will be carried out by tester
Answer3:
Ever heard about divide and conquer tactic ?
It is a same method applied in backend and frontend
testing.
A good back end test will help minimize the burden of
frontend test.
Another point is you can test the backend while
develope the frontend. A true pararelism could be
achived.
Backend testing has another problem which must
addressed before front end could use it. The problem
is concurency. Building a scenario to test concurency
is formidable task.
A complex thing is hard to test. To create such
scenarios will make you unsure which test you already
done and which you haven't.
What we need is an effective methods to test our
application. The simplest method i know is using
divide and conquer.
Answer4:
A wide range of errors are hard to see if you don't see the code. For
example, there are many optimizations in programs that treat special
cases. If you don't see the special case, you don't test the
optimization. Also, a substantial portion of most programs is error
handling. Most programmers anticipate more errors than most testers.
Programmers find and fix the vast majority of their own bugs. This is
cheaper, because there is no communication overhead, faster because
there is no delay from tester-reporter to programmer, and more
effective because the programmer is likely to fix what she finds, and
she is likely to know the cause of the problems she sees. Also, the
rapid feedback gives the programmer information about the weaknesses in
her programming that can help her write better code.
Many tests -- most boundary tests -- are done at the system level
primarily because we don't trust that they were done at the unit level.
They are wasteful and tedious at the system level. I'd rather see them
properly done and properly automated in a suite of programmer tests.
What is Software “Quality”?
Quality software is reasonably bug-free, delivered on time and within budget, meets requirements and/or expectations, and is maintainable.
However, quality is a subjective term. It will depend on who the ‘customer’ is and their overall influence in the scheme of things. A wide-angle view of the ‘customers’ of a software development project might include end-users, customer acceptance testers, customer contract officers, customer management, the development organisation’s management/accountants/testers/salespeople, future software maintenance engineers, stockholders, magazine reviewers, etc. Each type of ‘customer’ will have their own view on ‘quality’ - the accounting department might define quality in terms of profits while an end-user might define quality as user-friendly and bug-free.
What is retesting?
Answer1:
Retesting is usually equated with regression testing (see above)
but it is different in that is follows a specific fix--such as a bug
fix--and 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 fix, and without a regression test.
Answer2:
1. Re-testing is the testing for a specific bug after it has been
fixed.(one given by your definition).
2. Re-testing can be one which is done for a bug
which was raised by QA but could not be found or confirmed by
Development and has been rejected. So QA does a re-test to make sure
the bug still exists and again assigns it back to them.
when entire project
is tested & client have some doubts about the quality of testing,
Re-Testing can be called. It can also be testing the same application
again for better Quality.
Answer3:
Regression Testing is, the selective retesting of a
system that has been modified to ensure that any bugs have been fixed and that
no other previously working 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
It is important to determine whether in a given set of circumstances a
particular series of tests has been failed. The supplier may want to submit the
software for re-testing. The 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 entirety? (2) when can, or
must, the supplier submit his software for retesting?, and (3) how many times
can the supplier fail tests and submit software for retesting ń is this based on
time spent, or the number of attempts? 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.
So the conclusion is retesting is more or less regression testing. More
appropriately retesting is a part of regression testing.
Answer4:
Re-testing is simply executing the test plan another time. The client
may request a re-test for any reason - most likely is that the
testers did not properly execute the scripts, poor documentation of
test results, or the client may not be comfortable with the results.
I've performed re-tests when the developer inserted unauthorized code
changes, or did not document changes.
Regression testing is the execution of test cases "not impacted" by
the specific project. I am currently working on testing of a system
with poor system documentation (and no user documentation) so our
regression testing must be extensive.
Answer5:
* QA gets a bug fix, and has to verify that the bug is fixed. You might want to check 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.
* Development Refuses a bug on the basis of it being “Non Reproducible”, then retesting, preferably in the presence of the Developer, is needed.
Part:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
| 