|
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
How to write Nunit test cases
What Is NUnit?
NUnit is a unit-testing framework for all .Net languages. Initially ported from JUnit, the current production release, version 2.2, is the fourth major release of this xUnit based unit testing tool for Microsoft .NET. It is written entirely in C# and has been completely redesigned to take advantage of many .NET language features, for example custom attributes and other reflection related capabilities. NUnit brings xUnit to all .NET languages.
A: Read the following:
How to write Nunit test cases
What is documentation change management?
Documentation change management is part of configuration management (CM). CM covers the tools and processes used to control, coordinate and track code, requirements, documentation, problems, change requests, designs, tools, compilers, libraries, patches, changes made to them and who makes the changes.
How can I test without requirements?
By Anuj Magazine
Testing Without Requirements: A Practical Approach
What is the difference between user documentation and user manual?
When a distinction is made between those who operate and use a computer system for its intended purpose, a separate user documentation and user manual is created. Operators get user documentation, and users get user manuals.
Why was bug x or bug y caught NOT during
testing?"
Why the defect was allowed to be introduced into the code? Why don't they have better
code reviews? Why don't the developers understand the product better?
Why are the requirements not fully understood by these people?
The real issue here is that they are passing quality off to the
testing team and it's not our job to make the product a quality
one--it's the responsibility of everyone in the company including the
receptionist.
It is not the job of testing to be responsible for assuring quality
and it is not the purpose of testing to find bugs.
Classic Testing Mistakes
Do they rely on strange configurations: ones you could never hope to
reproduce? Is it reasonable that your testers should have "caught"
these defects? If it is, don't make any excuses.
Alternately, if it's really the requirements, how can the developers
make the right product and the testers don't understand what the
developers are making? There is communication about what needs to be
done, and the developers seem to be getting that communication, why
can't your testers? We know the reason: the developers didn't get the
communication right--that's why there was a defect. So you can point
out the communication as well.
when there is a requirements document, testers have a tendency to only test the
main path, or they'll only run one test case per requirement, when there
clearly should be many tests to catch all boundaries and failures. Testers
do need to be able to think about what they are doing, and it is very
possible that the testers themselves are at fault. Don't be afraid to hold
them accountable for being lazy.
The main cause of the problem is not enough
testing time allocated:
NO time for doc reviews;
Little time for test design and creation;
Little time for test execution.
How do you conduct peer reviews?
The peer review, sometimes called PDR, is a formal meeting, more formalized than a walk-through, and typically consists of 3-10 people including the test lead, task lead (the author of whatever is being reviewed) and a facilitator (to make notes). The subject of the PDR is typically a code block, release, or feature, or document. The purpose of the PDR is to find problems and see what is missing, not to fix anything. The result of the meeting is documented in a written report. Attendees should prepare for PDRs by reading through documents, before the meeting starts; most problems are found during this preparation.
Why is the PDR great? Because it is a cost-effective method of ensuring quality, because bug prevention is more cost effective than bug detection.
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
| 