Welcome to the testing world :-)
I hope u have clear idea about SDLC.Almost same life cycle should be follwed in testing life cycle also starting from requirement gatharing to bug fixing.
i am trying to give you some idea abt this cycle,some steps might be missed:
1.Testing requirement gathering
2.Testing requirement analysis
3.Sign Off requirement
4.Test strategy fixing
5.Preparing Test Cases
6.Review and freeze test cases
7.Execution of test cases
8.Report the bugs
9.Fixing the bugs
10.Retest and close the bugs
11.Prepare the defect summary report
hope i have covered almost all the steps.
Please reply back if you need more information.
manual test organization test team leader ----> sets test strategy---->mission/business analysts --->test objectives ----->test analysts/designers----------> manual test cases and scripts---->testers please reply back if you need more information. Thanks ram
After approal of the project BA will release the SRS. Testers and developers go through this document. Later they will conduct a meeting in this meeting if u have any doubts in SRS regarding terminalogy or confussion sentences they will clarify and some times they will send a template with SRS u have doubts u can write and send to BA.Mean time senior people will prepare like test leads,UCD usecase document.with this Business rules will be attached. Based on these two testers have to develop test cases in the given test case templete. while developing the test cases whenever required u have to apply business rules and while preparing test data BVA AND ECP have to apply. After the build is released tester has to execute the test cases. If they found the bug they send to the leads if it is rellay a bug it is open this bug when tester found its status is new. After bug is rectified againg we have to test the total functionality. Who have clear idea in the project they may involve insystem testing it will do after deployment . after total modules were developed all the modules are integrated. this done before system testing. At last database testing will be done.
Testing is method to verify and validate that the system or application under test performs as per the requirements.
Manual Testing is the means by which the System is tested manually without the use of any Automation Tools. The system can be tested for its Functionality and its Performance.
As per the SDLC the Testing starts after the Development. The simple Life cycle of a Software is
Requirement --> Design --> Coding / Development --> Testing --> Implementation --> Maintenance.
The Testing activity will begins once after the Requirement is done. The Testing starts of with the analysis of the Test requirement. Once the analysis is done, the estimation and schedule is done for the duration of testing activity. Then the Requirements are splitted into smaller parts as Test cases, which will reviewed by the senior members and business analysts. The Test case is a template having the Description, The testing action, Expected result and the Actual Result column. Once the application is ready for testing the test cases are executed against the application and the actual results are recorded. If the actual result varies from the expected one the test cases fail and the defects are logged. And after the defects are accepted it will fixed and then retested, if the defect is validated is closed. This activity is carried till the defects are closed.
This is the approach that are carried out in Manual testing. I hope you get some knowledge regarding manual testing.
Following is the procedure must followed in manual testing 1. Tester should go through requirement documents.(requirement analysis) 2. Go through the documents which are created by developers. 3. Create the test plan on the basis of both documents. Test plan includes: 1. Objective 2. Scope 3. Area of focus 4. Time estimation - how much time required to test 5. Resources: how many team members are included in testing. 4. Create the detail level test cases including all the testing scenario's (positive+negative) 5. After creation of test case, execute the test cases and verify the actual and expected result. 6. If find any defect then make the entry in the bug tracking tool (like:bugzila) and mentioned the defect number in the test case. 7. After the defect is fix by developer then re-verify the defect and then close the defect. I have mentioned the steps which we followed in our company. If i am wrong then please correct me and let me know
manual testing steps
-risk based testing
-test requirement management
-critical sucess factor or quality sucess factor
-issue escalation/problem reporting
-risk and action plan
-defect reporting process
-scope of testing
a.inscope of testing
b.out of scope of testing
-schedules and time lining
a.over all status
-risk and action plans
c.risk exposure value
-roles and resposibility
a.roles of test manager
b.roles of test lead
c.roles of test engineers
-test case preparation
manual testing procedure basically consist of a set of activities which include (i)the detailed analysis of the Software Requirement Specification of the software.
(ii)On the basis of SRS prepare the test Plan
(iii)Prepare the test cases.
(iii)Execute the test cases.
(iv)Analyze the result.
(v)Report the Bug If Found.
Here is the Article i found for the time schedule for testing ,this article is based on time schedule for web testing.
This question pops up in various forms all the time. It boils down to "We don't have enough time to test everything, so what do we test?" Not having enough time, of course, is not only the status quo for testing software, it is a universal truth for any software that will ever go into production.
Given that, here's my advice.
1.Start by forgetting that you have any test cases at all.
2.Make a list (quickly -- remember we don't have enough time to test, so let's not waste what little time we have making lists) of each of the following usage scenarios. I usually limit myself to five on the first pass, but no matter what, move on to the next category as soon as you find yourself thinking about the category you are on. If you have to stop and think, whatever you come up with isn't important enough.
a.What things will users do most often with this application?
b.What areas of this application are most likely to contain show-stopping defects?
c.What parts of this application are critical to the business?
d.Are any parts of this application governed by legal or regulatory agencies?
e.What parts of the application would be most embarrassing to the company if broken?
f.What parts of the application has my boss said must be tested?
3.Prioritize the list. If you've made the list in a word processor or using note cards, this will take under 60 seconds (if you have to write a new list by hand and you write as slowly as I do, it will probably take a little longer. Here are the rules for prioritizing.
a.Count the number of times a scenario appears in any of your categories. The more times the scenario appears, the higher the priority.
b.In case of a tie, 'a' comes before 'b' comes before 'c,' etc.
4.Now scan your test cases. Note which ones are covered and which ones aren't. On the ones that aren't covered, ask yourself, "Can I live with not testing this?" If the answer is no, add it to the bottom of the list.
6.If you complete these tests before time is up, do the same exercise again without repeating any usage scenarios. If not, at least you have a defensible list of what you did and did not test and lost all of about 15 minutes of testing time creating that list.
In case you're wondering, this approach is derived from my FIBLOTS heuristic for deciding what usage scenarios to include when developing performance tests. FIBLOTS is an acronym representing the words that complete the sentence "Ensure your performance tests include usage scenarios that are:
Applying for a job can be a stressful and frustrating experience, especially for someone who has never done it before. Considering that you are competing for the position with a at least a dozen other applicants, it is imperative that you thoroughly prepare for the job interview, in order to stand a good chance of getting hired. That's where GeekInterview can help.