8 hng dn vit test case hon chnh

By Marcin Zrda How can you explain to a beginner tester the idea of writing, executing and reporting of test cases? Its a tough job, I found this quite recently by training a new person in the team. Everything I had in my head but there was not one clear and consistent explanation on the paper. Many years of experience, unfortunately, has not helped me to verbally justify and explain this issue. This post will be an attempt to complete my own thoughts and these coming from the environment. For begining, a few sentence to clarify what are the test cases and test scenarios and how they are different and in what order must exist. Starting from the end, let us answer the question why?. Test case is a description, a recipe for tester, dealing with how to test a given functionality and how to check whether this works correctly. Looking at the structure, we can identify types of relationship: Test scenario -> test case -> Test Step. Starting from the end again, because it will be easier, I can write: * Test Step specifies an action to perform, and the expected response of the test application. For example: Action : Type the password in the password box, Expected result: Your password should be dotted / hidden. * Test Case a list of test steps. Also defines the environmental situation and may link to related bugs, requirements etc. * Test Scenario usually comes directly from business requirements or userstory. Management tools often ignore test scenario for linkage with a list of the requirements. Scenario contains a list of test cases and often their sequence. As you can see, varies between a test case scenario is significant, and often the two concepts are confused. How to ensure the quality of the test cases are created? How to manage their life cycle? How to deliver them quickly and when developers need it ? 1. Template need one and complete template for creating test cases. We can create it in a text editor, spreadsheet or buy or customize the tool. I have written about this in the context of the JIRA.

2. Descriptive and specific you need a short, concise title and description. Should clearly define the purpose and scope of their operations. We are writing to all testers, not only for yourself, use simple language, complicated language figures are not popular here. Use rather imperative, therefore Write abc and press enter not I am writing abc, and pressing Enter. 3. Reusable one and the same test case can be used in many scenarios. Let us remember that! Creating a new item, we must imagine a different kind of use case of our work. I also imagine that test step could be reused, so pay your attention at this level too. 4. Atomic the greatest tester nightmare struggled with the manual testing is a test case, which is too long and doing too much dependency checks. Person carrying out a process must have a sense of progress, otherwise is bored, reducing its vigilance, and motivation. Tester may have to perform 100 test cases and do them in one day, but it can also have their 10 and do it for a week. Let us create test case, which can be performed up to several minutes, and gain the favor of the other fellow testers, among the satisfied, we can also include those who write automation scripts. 5. Positive and negative the next important thing is the order of creation. What to do when the project manager requests a set of test cases on the day following approval of an implementation plan? Usually we do not say that he wanted only the beginning of positive tests, those which check whether the functionality exists and acts in accordance with the requirement. Give him as such set as soon as possible, then we can deal with the preparation of a negative description situation and the relationship between other requirements. To sum up: Positive -> Negative -> Relationships 6. Refactor if you already done your job we have to remember that applications are changing and the changes in the test cases should follow this process. We can version it, using clone and change method for a given version number. Head of the tests should determine how many past versions we support and we should care enough about our current collection of test cases.

7. Test data there are moments in which along the correct execution of the test we have to provide some data, which usually (if they are too complex to be described in the text) are attached as binary files. We need to analyze whether it is easier to provide test data or may be easier to add the appropriate test steps. 8. Setup and tear down if the test case requires the initial configuration, call a particular component, we need to take this into account in the zero step. It is also important to cleanup in the last step like in unit testing or automation, but I believe that during the test manual is worth to preserve this good practice. Summary Take to heart my observations if you do not agree write a comment. Perhaps I skipped something, if I drop what I will do an update. At this moment it appears as a complete manual. I promise that soon we will put post in which I will describe exactly the structure of the template test case. Ngun: http://www.vietnamesetestingboard.org Would you Follow me on Twitter?
tvn Bi vit: 594 Ngy tham gia: T.Ba 10 Thng 8, 2010 10:11 am

Re: Hng dn vit test case hon chnh

gi bi tvn T.Hai 29 Thng 11, 2010 5:16 pm

8 hng dn vit test case hon chnh

By Marcin Zrda --- Bn dch sang Ting Vit --Lm th no bn gii thch cho mt tester mi vo ngh v cch vit, thc hin v bo co cc test case? l mt cng vic kh khn, ti nhn ra

iu ny kh gn y trong lc o to mt tester mi trong nhm. Ti c mi th trong u nhng khng c mt li gii thch r rng v nht qun trn giy t. Ti c nhiu nm kinh nghim, khng may, cng khng gip ti bin minh v gii thch vn ny. Bi vit ny l mt c gng hon thnh nhng suy ngh ca ti n t mi trng sn xut phn mm. bt u, s c mt vi cu lm r v cc test case v test scenario v chng khc nhau nh th no v theo th t no. Bt u t cui cng, chng ta hy tr li cu hi "th t no?" Test case l s m t, cng thc cho tester, lin h gia vic lm th no test chc nng v lm th no kim tra h thng hot ng ng hay khng. Nhn vo cu trc, chng ta c th nh ngha c cc loi quan h: Test scenario -> test case -> Test Step. Li bt u t cui cng, bi v nh vy s d dng hn, Ti c th vit nh sau: * Test Step quy nh c th mt hnh ng thc hin, v p ng mong i ca ng dng test. V d: Hnh ng: Nhp password vo password, Kt qu mong i: password ca bn s hin th l *** hoc n. * Test Case l mt danh sch cc test step. Cng nh ngha trng thi mi trng v c th lin kit n cc bug, spec (c t yu cu) lin quan, * Test Scenario thng c c trc tip t cc c t yu cu ca khch hng hoc user-story. Cc cng c qun l thng b qua test scenario kt ni vi mt danh sch cc c t yu cu. Scenario cha mt danh sch cc test case v nhiu phi hp ca chng. Nh cc bn c th thy, s khc nhau gia test scenario v test case l ng k, v thng thng hai khi nim ny th m h. Lm th no m bo cht lng cho test case to c? Lm th no qun l life cycle ca n? Lm th no hon thnh n sm v khi no th Dev cn n? 1. Template cn mt hoc nhiu mu hon thnh vit test case. Chng ta c th to test case trong MS Word, MS excel hoc mua hoc chnh sa li cc tool khc. Ti vit bi ny bng chng trnh son tho JIRA.

2. Descriptive v specific cc bn cn miu t tiu ngn gn, xc tch. Nn nh ngha cc mc ch v phm vi ca cc hot ng test mt cch r rng. Chng ta ang vit cho tt c cc tester, ch khng ch vit ring cho chnh mnh, s dng ngn ng n gin, miu t bng ngn ng phc tp trong test case th khng ph bin. Nn dng theo kiu cu mnh lnh, v d, nn ghi l Nhp abc v nhn enter ch khng nn ghi Ti ang nhp abc, v sau nhn Enter. 3. Reusable mt v nhiu test case ging nhau c th c s dng trong nhiu scenario. Hy nh rng! Khi to mt hng mc mi, chng ta phi tng tng ra mt loi use case khc vi loi m chng ta ang lm. Ti cng tng tng rng bc test cng c th c ti s dng, v vy bn cng phi nn ch n mc ny. 4. Atomic c mng ln nht ca tester vt ln vi test th cng (bng tay) l test case, v n c qu di v lm qu nhiu kim tra ph thuc nhau. Ngi tin hnh mt tin trnh phi c thch v tin trnh , ngc li th tht chn, gim cnh gic vi n, v nhit huyt. Tester c th phi thc hin 100 test case v thc hin n trong mt ngy, nhng n cng c th c 10 test case v thc hin n trong 1 tun. Chng ta hy to test case, iu ny c th lm trong vi pht v n gip ta ginh c nhiu thin ch ca cc tester ng nghip khc hn, trong s cc s hi lng, chng ta cng c th l ngi vit script test t ng. 5. Positive and negative (test trng hp ng v trng hp sai) iu quan trng tip theo l th t ca vic to test case. Lm g khi project manager yu cu mt tp test case vo mt ngy duyt trong k hoch tin hnh? Thng th chng ta khng ni rng anh y ch mun bt u bng cc trng hp test tch cc (ch test trng hp ng), cc trng hp ny l dng kim tra chc nng tn ti v cc hnh ng theo ng vi spec (c t yu cu ca khch hng). a cho anh ta mt tp test case cng sm cng tt, th chng ta c th thng lng anh ta ph chun cc trng hp test sai v cc quan h gia cc yu cu khc. Tm li: Positive -> Negative -> Relationships 6. Refactor nu bn sn sng kt thc cng vic th chng ta phi nh rng cc ng dng th thay i v cc thay i trong test case s lm theo

trnh t ny (theo 8 bc ny). Chng ta nn to version cho n, bt chc cch thay i version number (1.0 -> 1.1 ->). Qun l test (v d QC leader) s c lng chng ta s lm c bao nhiu version v chng ta nn quan tm v tp hp cc test case hin ti ca chng ta. 7. Test data (d liu dng test) y l nhng iu quan trng song song vi vic thc hin test ng th chng ta phi cung cp mt s data, thng th (nu n qu phc tp m t trong ti liu ny) c nh km bng mt file khc. Chng ta cn phi phn tch cho d n d cung cp test data hay d thm vo cc bc test thch hp. 8. Setup and tear down (sp xp v ta tt li test case) nu test case yu cu phi c cu hnh ban u, gi mt component ring bit, chng ta cn phi m t n v bc u tin (zero step). iu ny cng quan trng dn dp trong bc bc cui cng ging nh trong test unit (whitebox) hoc test t ng, nhng ti tin rng test th cng th ng s dng tt cc bc thc hnh ny. Cui cng Phi s dng ht kh nng quan st nu bn khng ng vi vic ghi li ghi ch. C l ti gi li mt s iu, nu ti c b st iu g ti s cp nht li sau. Lc ny ti ch c th ngh ra by nhiu y thi. Ti ha l s post bi gii thch cu trc ca mt mu test case.