|
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
Which things to consider to test a mobile application through black box technique?
Answer1:
Not sure how your device/server is to operate, so mold
these ideas to fit your app. Some highlights are:
Range testing: Ensure that you can reconnect when
leaving and returning back into range.
Port/IP/firewall testing - change ports and ips to ensure
that you can connect and disconnect. modify the firewall
to shutoff the connection.
Multiple devices - make sure that a user receives his
messages with other devices connected to the same ip/port.
Your app should have a method to determine which
device/user sent the message and only return to it. Should
be in the message string sent and received. Unless you
have conferencing capabilities within the application.
Cycle the power of the server and watch the mobile unit
reconnect automatically.
Mobile unit sends a message and then power off the unit,
when powering back on and reconnecting, ensure that the
message is returned to the mobile unit.
Answer2:
Not clearly mentioned which area of the mobile application you are testing with. Whether is it simple SMS application or WAP application, you need to specify more details.If you are working with WAP then you can download simulators from net and start testing over it.
What is the general testing process?
The 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 execution of tests.
Test data are inputs that have been devised to test the system
Test Cases are inputs and outputs specification plus a statement of the function under the test.
Test data can be generated automatically (simulated) or real (live).
The stages in the testing process are as follows:
1. Unit testing: (Code Oriented)
Individual components are tested to ensure that they operate correctly. Each component is tested independently, without other system components.
2. Module testing:
A module is a collection of dependent components such as an object 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.
3. Sub-system testing: (Integration Testing) (Design Oriented)
This phase involves testing collections of modules, which have been integrated into sub-systems. Sub-systems may be independently designed and implemented. The most common problems, which arise in large software systems, are sub-systems interface mismatches. The sub-system test process should therefore concentrate on the detection of interface errors by rigorously exercising these interfaces.
4. System testing:
The sub-systems are integrated to make up the entire system. The testing process is concerned with finding errors that result from unanticipated interactions between sub-systems and system components. It is also concerned with validating that the system meets its functional and non-functional requirements.
5. Acceptance testing:
This is the final stage in the testing process before the system is accepted for operational use. The 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 - oriented) because real data exercises 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 (non-functional) is unacceptable.
Acceptance testing is sometimes called alpha testing. Bespoke systems are developed for a single client. The alpha testing process continues until the system developer and the client agrees that the delivered system is an acceptable implementation of the system requirements.
When a system is to be marketed as a software product, a testing process called beta testing is often used.
Beta testing involves delivering a system to a number of potential customers who agree to use that system. They report problems to the system developers. This exposes the product to real use and detects errors that may not have been anticipated by the system builders. After this feedback, the system is modified and either released fur further beta testing or for general sale.
What's normal practices of the QA specialists
with perspective of software?
These are the normal practices of the QA specialists
with perspective of software
[note: these are all QC activities, not QA activities.]
1-Desgin Review Meetings with the System Analyst and If possible
should be the part in Requirement gathering
2-Analysing the requirements and the desing and to trace the desing
with respect to the requirements
3-Test Planning
4-Test Case Identification using different techniques (With respect
to the Web Based Applciation and Desktoip Applications)
5-Test Case Writing (This part is to be assigned to the testing
engineers)
6-Test Case Execution (This part is to be assigned to the testing
engineers)
7-Bug Reporting (This part is to be assigned to the testing engineers)
8-Bug Review and thier Analysis so that future bus can be removed by
desgining some standards
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
| 