|
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
What is software testing methodology?
One software testing methodology is the use a three step process of...
1. Creating a test strategy;
2. Creating a test plan/design; and
3. Executing tests.
This methodology can be used and molded to your organization's needs. Rob Davis believes that using this methodology is important in the development and ongoing maintenance of his clients' applications.
What’s the difference between QA and testing?
TESTING means “Quality Control”; and
QUALITY CONTROL measures the quality of a product; while
QUALITY ASSURANCE measures the quality of processes used to create a quality product.
Why Testing CANNOT Ensure Quality
Testing in itself cannot ensure the quality of software. All testing can do is give you a certain level of assurance (confidence) in the software. On its own, the only thing that testing proves is that under specific controlled conditions, the software functioned as expected by the test cases executed.
How to find all the Bugs during first round of Testing?
Answer1:
I understand the problems you are facing. I was involved with a web-based HR system that was encountering the same problems. What I ended up doing was going back over a few release cycles and analyzing the types of defects found and when (in the release cycle including the various testing cycles) they were found. I started to notice a distinct trend in certain areas.
For each defect type, I started looking into the possibility if it could have been caught in the prior phase (lots of things were being found in the Systems test phase that should have been caught earlier). If so, why wasn't it caught? Could it have been caught even earlier (say via a peer review)? If so, why not? This led me to start examining the various processes and found a definite problem with peer reviews (not very thorough IF they were even being done) and with the testing process (not rigorous enough). We worked with the customer and folks doing the testing to start educating them and improving the processes. The result was the number of defects found in the latter test stages (System test for example) were cut by over half! It was getting harder to find problems with the product as they were discovering them earlier in the process -- saving time & money!
Answer2:
There could be several reasons for not catching a showstopper in the
first or second build/rev. A found defect could either functionally
or physiologically mask a second or third defect. Functionally the
thread or path to the second defect could have been boken or rerouted
to another path or physiologically the tester who found the first
defect knows the app must go back and be rewritten so he/she procedes
halfheartedly on and misses the second one. I've seen both cases. It
is difficult to keep testing on a known defective app. The testers
seem to lose interest knowing that what effort they put in to test
it, will have to be redone on the next iteration. This will test your
metal as a lead to get them to follow through and maintain a
professional attitude.
Answer3:
The best way is to prevent bugs in the first
place. Also testing doesn't fix or prevent bugs.
It just provides information. Applying this information to your
situation is the important part.
The other thing that you may be encountering is that testing tends to
be exploratory in nature. You have stated that these are existing
bugs, but not stated whether tests already existed for these bugs.
Bugs in early cycles inhibit exploration. 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 expand their
exploration (ie. think of new tests).
No 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.
Exposure 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. Iterative development is a good way to
counter this, as testers get to see something physical earlier, but
this issue will always exist to some degree as the passing of time,
and exploration of the application allow new tests to be thought of
at inconvenient moments.
Is regression testing performed manually?
The answer to this question depends on the initial testing approach. If 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.
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
| 