How to find defects + how to write use cases _ casual look at the test new

Write to test newcomer

Summing up the test rookie, how to quickly find the system's deficiencies or defects 1, read the requirements of the document, in-depth understanding of the system, Maito, do not have to understand the need to open the test, (one weeks ago, the company just entered a new person, TD on the view of their hair bug, Several were found to be ambiguous in demand) thinking: The original is this system Ah, project training when done and this similar project, so the system needs of the training to move to the current system, the risk is too large, because each system needs are not the same, can not be mechanically, For example: Suppose you make a car, you made a poussin before, and you make the Poussin technology to make Lincoln, which is obviously inappropriate. Familiar with the system (general company will have system familiar with the assessment) so please be sure to read the requirements of the document (some companies are called product definition)
2, familiar with test cases, which is a guide to test execution, to fast and efficient execution of use cases, must be familiar with the system, familiar use cases, familiar with the needs of each use case coverage, so that the implementation can be more effective
3. Remember that the role you play in your work is testing, not development. Cherish the time and avoid unnecessary waste. As a new tester, first contact with the project, there are many times to find a bug, just know its appearance characteristics, but can not understand what this flaw is caused by, there is a misunderstanding, spend too much time to find reasons, because of the individual learning knowledge and experience limitations, Some defects are difficult to find the cause of the short time, rather than wasting time, it is better to reproduce the bug to the development look, let the development to find the reason, so that is not delayed the following test can also find the reason in a short time, fundamentally solve the bug.
4. Once the defect is found, it should be submitted immediately. There are several situations: testing is like a battle for the fittest, your movements are slow, and the results are others.
1 as a test newcomer, the first step in testing, it is possible to start with the execution use case, and the successful use case (at the beginning of the project) can find many problems in the system, different step in the same case may find multiple bugs, so for this situation, we have to do is: The discovery is submitted, Do not wait until all the step has been completed before submitting. That might have been submitted by someone else.
2 "Leave the" demand specification (that is, need not look at the requirements of the manual, the requirements are particularly familiar), to quickly win. Suppose you and your colleagues found a bug at the same time (neither side knew the other was submitting), and you are not familiar with the requirements, not too sure is a bug, and then go over the demand, turn back to submit, the results of this time colleagues have submitted, so sorry, your bug can only be treated as closed_nbug, If you must add an annotation, then it will be, repeated submissions (test new, comments not recommended to add test recommendations (that is, how to modify to avoid this defect), because it may be misleading to development) Special note: 1 speed and efficiency at the same time, try not to send wrong bug;2) fair competition, but also consider teamwork, In other people's Test module found a bug, suggest to tell the other side, and colleagues to communicate, colleagues speak of defects, and defect management tools did not mention, should let the other party submitted up
5. Release of new version:
1 to verify the fixed defect, if the validation passed, change the status to closed (when the closure must be added a note, such as: a certain day of the month a version of the validation pass. For development changes, but not with the requirements, and with the Test Manager to confirm that this can be modified, the note recommends this: a certain day of the month a version of the validation passed, modified to ... ), if not by changing to open (also add a note: A month a version of the validation failed), there is a misunderstanding, some people will change the state to reopen, if the company requirements, that is understandable, if there is no request, the proposed change to open, Changes to the reopen state are required because the reopen has been confirmed as modified and the bug has been changed to a closed state. (There are many companies that are not allowed to have reopen status (for development), and once they do, the programmer's performance for developing this module may be compromised, as I am now in the company.
2 The smoke to ensure the flow of the main process, then the functional testing, focusing on testing the modified or with the modified modules have a call relationship with the module and found that the number of bugs more modules (the company release will notify the modified module and fix the bug), unchanged module recommended to do a process test. Special note: The main process does not go through, should immediately MSN to the project leader (leader or manager, if there is this project MSN Group, directly in the group to speak on it)
6, if the version is not updated,
1) recommendations focused on business logic testing, on the computer in the form of documents to draw a simple business logic diagram, highlighting: Must try to consider all the circumstances, because such a bug or not, once there is high
2) Recommended environmental testing (of course, according to the requirements of the corresponding environment test)
3 Strictly check the requirements of the document to prevent the omission of demand
7, in strict accordance with the defects submitted instructions to submit a bug, because this may involve the statistical problems of bugs, (general company's defect Description: System name _ function module, defect description, to specific problems specific treatment)
Priority and severity do not exaggerate or degrade, seeking truth from facts, because it is linked to the development and testing of performance appraisal, if exaggerated defects, will affect the development of performance evaluation, reduce impact on their performance evaluation, recommendations: System-level (impact process) and jump Yellow Pages (Report server error, This type of defect is a result of server configuration errors, recommended to check the configuration after the submission of recommendations for the high, functional implementation of the recommendations for the use of the interface, or do not affect the system used by other issues recommended for the low, specific level of the company will have provisions, if there is no provision, can be

8, the test is not idle. Project at different stages, will have some time is ' idle '.

How to write a use case for the first time.
A lot of friends first write use cases, do not know where to begin, although some companies have given the relevant documentation, but writing is still not handy, there are many kinds of writing use case methods: function-oriented use cases (boundary value, equivalence class, etc.), user-oriented use cases (Scene method), user, functional combination of the guidance of use cases ... So for the first time to write a use case, how efficient to write use cases. You should pay attention to something.
First, function-oriented use cases are in accordance with the system needs to achieve every function, for writing use cases, such use cases focus on functional implementations without taking into account the correlation between each function, so this method is often used in conjunction with other methods, although the use case has reached functional coverage but does not necessarily reach the logical overlay. The function-oriented use case is the most commonly used method of each use case writer, the network can search a lot of related articles, here because the time relationship does not write. (There is another reason is that may be written very rotten, so do not take out a disgrace, hehe)
Second, user-oriented use cases are in accordance with the user's habit, the use of each goal of the system as a goal, the implementation of each target as the basis for the design of test cases, such a method in the B/s structure is widely used (I have been engaged in B/s test so suitable for C/s I do not know, but because I like to play online, so /s software is not unfamiliar, the individual feel can also be applied, now the network game (not competitive category) to multitask-oriented, such as World of Warcraft, Dream West Tour, Dahua West Tour, Perfect International, QQ, etc., you can complete each task as a goal design test cases) but the design of this kind of use case, the first writer, There may be a lot of confusion (write down what puzzles I had when I first wrote it, and what kind of solutions I had to take in response to these puzzles).
1. What should I do in the first step of writing a use case?
Understand the system, the first step in the test of the perspective of the system to understand each function and system business logic, draw a business logic diagram (that is, what the system can do).
Second, the user's point of view, listing the user's purpose of using the system (ie: users use this system, want to do. ）
2, how to determine the user goals.
Inability to determine user goals may be caused by 2 reasons: A> is not familiar with the system,b> not understand the user background. For the 1th reason, that's your own reason, just go back and look at the document, for the 2nd reason, you can figure out what ' the system can do ' and ' what the user can do ' and then sum up what ' the user may want to do ', but the premise is that you are already familiar with the system.

What will I do this month? Just enter the test industry how to sum up (using test management tools to summarize):
1 The test management tools in all the classification of defects, summed up which modules are prone to what defects, focus on their own did not find or do not take into account the deficiencies, pay attention to Closed_nbug, ByDesign, rejected, deferred state of the defect:
A the defect of the Closed_nbug state is generally the demand is ambiguous, the demand change produces, look at this kind of flaw, can summarize which demand is apt to produce misunderstanding, and what new demand appears.
B bydesign State defects are generally design problems, can be summed up in the design of what deficiencies, what good advice, but also to the project manager to mention (such a proposal once adopted, then your price will improve a lot)
C Rejected State defects in several cases: first, repeated submissions (some people will be changed to Closed_nbug) second, the developers do not think that need to modify, three, is not a problem (due to the lack of understanding of the requirements) for rejected state of the bug must see comments (note: usually explain rejected reason), if not add notes, then to confirm why to call back. (Our company if rejected without remark, want to open directly, then note write: Not explain rejected reason, reopen, personally feel so not good, should first and development confirm rejected reason, reasonable words to let him add remark, if unreasonable, Negotiate with him and confirm with the test leader or manager if you need to reopen it.
D Deferred State of the defect is generally the project time is relatively tight and the existence of such defects will not affect the normal use of the system, so the delay processing, for such a defect, you can temporarily do not pay attention, but to confirm about which phase of the revision, confirmed after the record, to the corresponding stage, Continue to focus on these flaws, which can be summed up by this type of bug which can be deferred (emphasis: low priority, but must be mentioned, just to make yourself aware of the shortcomings of the primary and secondary)
2 If the first step in the new test is to start with the execution use case, then the second level is to write the test case
The test management tool in the use case detailed review several times, learn other people's use case writing method and thought, free time can try to write, see oneself write and others write use case gap where, thus constantly improve. An important note; Focus on use case writing methods and ideas to learn, do not die to move hard sleeve
3 into a number of test forums, their own confusion and experience and everyone to share, in the study, continuous improvement.