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 do I start with testing?

Think twice (or may be more) times before you choose a career. Are you interested in it or do u just want to jump on the bandwagon?
Prerequisite
You can join a software development company as a tester if you can convince the interviewer
1. You have a knack for breaking software
2. You are aware of basic Quality concepts and belive in them
3. You want to pursue Testing as a career and not just to try it

OO Software Testing Issues
A common way of testing OO software testing-by-poking-around (Binder, 1995). In this case the developer's goal is to show that the product can do something useful without crashing. Attempts are made to "break" the product. If and when it breaks, the errors are fixed and the product is then deemed "tested".
Testing-by-poking-around method of testing OO software is, in my opinion, as unsuccessful as random testing of procedural code or design. It leaves the finding of errors up to a chance.
Another common problem in OO testing is the idea that since a superclass has been tested, any subclasses inheriting from it don't need to be.
This is not true because by defining a subclass we define a new context for the inherited attributes. Because of interaction between objects, we have to design test cases to test each new context and re-test the superclass as well to ensure proper working order of those objects.
Yet another misconception in OO is that if you do proper analysis and design (using the class interface or specification), you don't need to test or you can just perform black-box testing only.
However, function tests only try the "normal" paths or states of the class. In order to test the other paths or states, we need code instrumentation. Also it is often difficult to exercise exception and error handling without examination of the source code.

What is the purpose of black box testing?

Answer1:
The main purpose of BB Testing is to validate that the application works as the user will be operating it and in the environments of their systems. How do you do system testing and integration testing?
You may lose time and money but you may also lose Quality and eventually Customers!

Answer2:
"What is the purpose of black box testing?"
Black-box testing checks that the user interface and user inputs and outputs all work correctly. Part of this is that error handling must work correctly. It's used in functional and system testing.
"We do everything in white box testing: - we check each module's function in the unit testing"
Who is "we"? Are you programmers or quality assurance testers? Usually, unit testing is done by programmers, and white-box testing would be how they'd do it.
"- once unit test result is ok, means that modules work correctly (according to the requirement documemts)"
Not quite. It means that on a stand-alone basis, each module is okay. White box testing only tests the internal structure of the program, the code paths. Functional testing is needed to test how the individual components work together, and this is best done from an external perspective, meaning by using the software the way an end user would, without reference to the code (which is what black-box testing is).
if we doing testing again in black box will we lose time and money?"
No, the opposite: You'll lose money from having to repair errors you didn't catch with the white-box testing if you don't do some black-box testing. It's far more expensive to fix errors after release than to test for them and fix them early on.
But again, who is "we"? The black box testers should not be the people who did the programming; they should be the QA team -- also some end users for the usability testing.
Now that I've said that, good programmers will run some basic black-box tests before handing the application to QA for testing. This isn't a substitute for having QA do the tests, but it's a lot quicker for the programmer to find and fix an error right away than to have to go through the whole process of reporting a bug, then fixing and releasing a new build, then retesting.

How do you create a test plan/design?
Test scenarios and/or cases are prepared by reviewing functional requirements of the release and preparing logical groups of functions that can be further broken into test procedures. Test procedures define test conditions, data to be used for testing and expected results, including database updates, file outputs, report results. Generally speaking...
* Test cases and scenarios are designed to represent both typical and unusual situations that may occur in the application.
* Test engineers define unit test requirements and unit test cases. Test engineers also execute unit test cases.
* It is the test team that, with assistance of developers and clients, develops test cases and scenarios for integration and system testing.
* Test scenarios are executed through the use of test procedures or scripts.
* Test procedures or scripts define a series of steps necessary to perform one or more test scenarios.
* Test procedures or scripts include the specific data that will be used for testing the process or transaction.
* Test procedures or scripts may cover multiple test scenarios.
* Test scripts are mapped back to the requirements and traceability matrices are used to ensure each test is within scope.
* Test data is captured and base lined, prior to testing. This data serves as the foundation for unit and system testing and used to exercise system functionality in a controlled environment.
* Some output data is also base-lined for future comparison. Base-lined data is used to support future application maintenance via regression testing.
* A pretest meeting is held to assess the readiness of the application and the environment and data to be tested. A test readiness document is created to indicate the status of the entrance criteria of the release.
Inputs for this process:
* Approved Test Strategy Document.
* Test tools, or automated test tools, if applicable.
* Previously developed scripts, if applicable.
* Test documentation problems uncovered as a result of testing.
* A good understanding of software complexity and module path coverage, derived from general and detailed design documents, e.g. software design document, source code, and software complexity data.
Outputs for this process:
* Approved documents of test scenarios, test cases, test conditions, and test data.
* Reports of software design issues, given to software developers for correction.

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