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
Software Testing Issues
A common way of testing 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 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 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 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.
What is the purpose of a test plan?
Reason number 1: We create a test plan because preparing it helps us to think through the efforts needed to validate the acceptability of a software product.
Reason number 2: We create a test plan because it can and will help people outside the test group to understand the why and how of product validation.
Reason number 3: We create a test plan because, in regulated environments, we have to have a written test plan.
Reason number 4: We create a test plan because the general testing process includes the creation of a test plan.
Reason number 5: We create a test plan because we want a document that describes the objectives, scope, approach and focus of the software testing effort.
Reason number 6: We create a test plan because it includes test cases, conditions, the test environment, a list of related tasks, pass/fail criteria, and risk assessment.
Reason number 7: We create test plan because one of the outputs for creating a test strategy is an approved and signed off test plan document.
Reason number 8: We create a test plan because the software testing methodology a three step process, and one of the steps is the creation of a test plan.
Reason number 9: We create a test plan because we want an opportunity to review the test plan with the project team.
Reason number 10: We create a test plan document because test plans should be documented, so that they are repeatable.
Can we prepare Test Plan without SRS?
It is not always mandatory that you should have SRS document to prepare a Test Plan. This kind of Documents Hierarchy is maintained to maintain Organizational standards and also to have clear understanding of the things.
Yes you can Prepare a Test plan directly without SRS, When the Requirements are clear with your clients,and when your URD(User Requirement Document ) is supportive enough to clarify the issues.
Though we don't have SRS clients will be giving some information SRS only contains mainly Product information
But we will not know the Testing effort if we don't have SRS.
SRS contains How many cycles we are testing, and on the platforms we are testing , etc.
Actually there won't be any harm in doing so, becoz, ultimately you will send your Test plan document to your client and after getting approval from him only you start Testing.
(Note:- SRS is the document which you get in the Analysis phase of your Software Development. Test plan is the document , which contains the details of Product interms of , Tset strategy , Scope of testing, Types of tests to be conducted,Risk Managemnet , Mention of Automation Tool ,About Bug tracking Tool, etc..,)
How do test plan templates look like?
The test plan document template helps to generate test plan documents that describe the objectives, scope, approach and focus of a software testing effort. Test document templates are often in the form of documents that are divided into sections and subsections. One example of a template is a 4-section document where section 1 is the description of the "Test Objective", section 2 is the the description of "Scope of Testing", section 3 is the the description of the "Test Approach", and section 4 is the "Focus of the Testing Effort".
All documents should be written to a certain standard and template. Standards and templates maintain document uniformity. They also help in learning where information is located, making it easier for a user to find what they want. With standards and templates, information will not be accidentally omitted from a document. Once Rob Davis has learned and reviewed your standards and templates, he will use them. He will also recommend improvements and/or additions.
A software project test plan is a document that describes the objectives, scope, approach and focus of a software testing effort. The process of preparing a test plan is a useful way to think through the efforts needed to validate the acceptability of a software product. The completed document will help people outside the test group understand the why and how of product validation.
How to Test a desktop systems ?
You will likely have to use a programming or scripting language to interact with the service directly. You will have more control over the raw information that way.
You will have to determine what the service is supposed to do and how it is supposed to interact with other applications and services. A data dictionary likely exists. It may not be called that however. What this document does is explain what commands the service will respond to and what sort of data should be sent. You will have to use this document to do your testing. Get close to the person or people who created the document or the service and expect them to keep you in the loop when changes take place (it doesn't help anyone if you report a defect and it's really only reflecting an expected change in the operation of the service).
Desktop applications are generally designed to run and quit. You have to be concerned with memory leaks and system usage.
How do you create a test strategy?
The test strategy is a formal description of how a software product will be tested. A test strategy is developed for all levels of testing, as required. The test team analyzes the requirements, writes the test strategy and reviews the plan with the project team. The test plan may include test cases, conditions, the test environment, a list of related tasks, pass/fail criteria and risk assessment.
Inputs for this process:
* A description of the required hardware and software components, including test tools. This information comes from the test environment, including test tool data.
* A description of roles and responsibilities of the resources required for the test and schedule constraints. This information comes from man-hours and schedules.
* Testing methodology. This is based on known standards.
* Functional and technical requirements of the application. This information comes from requirements, change request, technical and functional design documents.
* Requirements that the system can not provide, e.g. system limitations.
Outputs for this process:
* An approved and signed off test strategy document, test plan, including test cases.
* Testing issues requiring resolution. Usually this requires additional negotiation at the project management level.
0 comments:
Post a Comment