|
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
A small query: 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.
Problem: How to do that.
Second 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 2 else go to test case 3.
Third is: How 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 Problem: How to do that:
X Just take instance for your class and call the method thru that instance.
Answer for 2nd and 3rd queries:
.t file
=======
[-] testcase tc1() appstate none
[ ] Print("This is tc1")
[-] testcase tc2() appstate none
[ ] Print("This is tc2")
[-] testcase tc3() appstate none
[ ] Print("This is tc3")
call your test cases under main function as below.
[-] main()
[ ]
[-] tc1()
[-] if GetTestsPassedCount ( )!=0 // Executing testcases tc2 and tc3 when testcase tc1 is passed only.
[ ] tc2()
[ ] tc3()
Why are there so many software bugs?
Generally speaking, there are bugs in software because of unclear requirements, software complexity, programming errors, changes in requirements, errors made in bug tracking, time pressure, poorly documented code and/or bugs in tools used in software development.
* There are unclear software requirements because there is miscommunication as to what the software should or shouldn't do.
* Software complexity. All of the followings contribute to the exponential growth in software and system complexity: Windows interfaces, client-server and distributed applications, data communications, enormous relational databases and the sheer size of applications.
* Programming errors occur because programmers and software engineers, like everyone else, can make mistakes.
* As to changing requirements, in some fast-changing business environments, continuously modified requirements are a fact of life. Sometimes customers do not understand the effects of changes, or understand them but request them anyway. And the changes require redesign of the software, rescheduling of resources and some of the work already completed have to be redone or discarded and hardware requirements can be effected, too.
* Bug tracking can result in errors because the complexity of keeping track of changes can result in errors, too.
* Time pressures can cause problems, because scheduling of software projects is not easy and it often requires a lot of guesswork and when deadlines loom and the crunch comes, mistakes will be made.
* Code documentation is tough to maintain and it is also tough to modify code that is poorly documented. The result is bugs. Sometimes there is no incentive for programmers and software engineers to document their code and write clearly documented, understandable code. Sometimes developers get kudos for quickly turning out code, or programmers and software engineers feel they cannot have job 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.
* Software development tools , including visual tools, class libraries, compilers, scripting tools, can introduce their own bugs. Other times the tools are poorly documented, which can create additional bugs.
What are Test Cases, Test Suites, Test Scripts, and Test Scenarios
(or Scenaria)?
A test case is usually a single step, and its expected result,
along with various additional pieces of information. It can
occasionally be a series of steps but with one expected result or
expected outcome. The optional fields are a test case ID, test step or
order of execution number, related requirement(s), depth, test
category, author, and check boxes for whether the test is automatable
and has been automated. Larger test cases may also contain
prerequisite states or steps, and descriptions. A test case should
also contain a place for the actual result. These steps can be stored
in a word processor document, spreadsheet, database or other common
repository. In a database system, you may also be able to see past
test results and who generated the results and the system
configuration used to generate those results. These past results would
usually be stored in a separate table.
The most common term for a collection of test cases is a test suite.
The test suite often also contains more detailed instructions or goals
for each collection of test cases. It definitely contains a section
where the tester identifies the system configuration used during
testing. A group of test cases may also contain prerequisite states or
steps, and descriptions of the following tests.
Collections of test cases are sometimes incorrectly termed a test
plan. They 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.
Most companies that use automated testing 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 think through a complex problem or system. They can be as
simple as a diagram for a testing environment or they could be a
description written in prose. The ideal scenario test has five key
characteristics. It is (a) a story that is (b) motivating, (c)
credible, (d) complex, and (e) easy to evaluate. They are usually
different from test cases in that test cases are single steps and
scenarios cover a number of steps. Test suites and scenarios can be
used in concert for complete system tests. See
An Introduction to Scenario Testing
Scenario testing is similar to, but not the same as session-based
testing, which is more closely related to exploratory testing, but the
two concepts can be used in conjunction.
Scenario testing is similar to, but not the same as session-based
testing, which is more closely related to exploratory testing, but the
two concepts can be used in conjunction. See
Session-Based Test Management
What's Exploratory Test
A Test Plan gives detailed testing information, including
Scope of testing
Schedule
Test Deliverables
Release Criteria
Risks and Contingencies
Give me five common problems that occur during software development.
Poorly written requirements, unrealistic schedules, inadequate testing, adding new features after development is underway and poor communication.
1. Requirements are poorly written when requirements are unclear, incomplete, too general, or not testable; therefore there will be problems.
2. The schedule is unrealistic if too much work is crammed in too little time.
3. Software testing is inadequate if none knows whether or not the software is any good until customers complain or the system crashes.
4. It's extremely common that new features are added after development is underway.
5. Miscommunication either means the developers don't know what is needed, or customers have unrealistic expectations and therefore problems are guaranteed.
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
| 