Програм хангамж боловсруулах үйл явц дахь туршилтууд. Үр дүнтэй, үр дүнтэй, эелдэг туршилт

Шаардлагатай үед: баг дахь харилцаа холбоо, ажилчдын үр дүнд хүрэх сонирхол, тэдний урам зоригийг үнэлэх.

Woodcock тест

Заавар

Танай багийг тодорхойлсон мэдэгдлүүдийг уншиж, санал нийлж буй хүмүүсийн тоог дугуйл. Хэрэв та энэ мэдэгдлийг бүхэлд нь үнэн биш гэж бодож байгаа бол хариултын талбарыг хоосон орхино уу.

Мэдэгдэл бүрийн талаар бодоход их цаг зарцуулж болохгүй: хэдхэн секунд л хангалттай.

Хэрэв та чин сэтгэлээсээ хандвал үр дүн нь ойлгомжтой болно гэдгийг санаарай.

Туршилт

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. Манай хамт олон болон биднийг дарамталж буй үйлдвэрчний эвлэлүүдийн хооронд үл ойлголцол их байна.

48. Энэ байгууллагад багаар ажиллахыг урамшуулдаг.

49. Бид харилцаанд хангалттай анхаарал хандуулдаггүй.

50. Биднээс юу хүлээж байгаа талаар тодорхой ойлголтгүй байна.

51. Шударга байдал нь манай багийн онцлог шинж биш юм.

52. Би хамт ажиллагсдынхаа дэмжлэгийг мэдэрдэггүй.

53. Ур чадвар, мэдээллийг сайн түгээдэггүй.

54. Өөрийнхөө замаар явдаг хүчирхэг зан чанарууд байдаг.

55. Өөрийгөө хүндлэх нь дургүйцдэг.

56. Ажлын арга барилын талаар ярилцахад илүү их цаг зарцуулах хэрэгтэй.

57. Менежерүүд хувь хүний ​​хөгжилд нухацтай ханддаггүй.

58. Байгууллагын бусад хэсэг биднийг ойлгохгүй байна.

59. Бид гадаад ертөнцөд мессежээ хүргэж чаддаггүй.

60. Багийн хүмүүс байгууллагын бусад гишүүдтэй сайн харилцаатай байдаг.

61. Ихэнхдээ бид хэтэрхий хурдан шийдвэр гаргадаг.

62. Хувь хүнийг үнэлдэг үйл ажиллагааны чиглэл нь хүрсэн зүйлтэй огт хамаагүй.

63. Хэтэрхий олон нууц.

64. Зөрчилдөөнөөс зайлсхийдэг.

65. Санал зөрөлдөөн нь авлигад хүргэдэг.

66. Шийдэлд тууштай байх нь бага.

67. Манай менежерүүд илүү их хяналт тавих нь үр дүнг сайжруулдаг гэж үздэг.

68. Манай багт хэтэрхий олон хориг тавьсан.

69. Өөр нэгжид илүү сайн боломж байгаа нь ойлгомжтой.

70. Бид хилээ хамгаалахад маш их энерги зарцуулдаг.

71. Багийн гишүүд тэднээс юу хүлээж байгааг ойлгодоггүй.

72. Байгууллагын соёл нь багаар ажиллахыг дэмждэг.

73. Бид шинэ санаануудад хангалттай анхаарал хандуулдаггүй.

74. Тэргүүлэх чиглэлүүд тодорхойгүй байна.

75. Шийдвэр гаргахад хүмүүс хангалтгүй оролцдог.

76. Хэтэрхий олон бие биенээ буруутгаж, зэмлэх.

77. Тэд үргэлж сонсдоггүй.

78. Бид өөрт байгаа ур чадвараа бүрэн ашигладаггүй.

79. Менежерүүд хүмүүсийг угаасаа залхуу гэж үздэг.

80. Бид хийхдээ маш их цаг зарцуулдаг ба бодоход хангалттай цаг зарцуулдаггүй.

81. Хувь хүний ​​өсөх хүслийг урамшуулдаггүй.

82. Бид бусад багуудын үзэл бодлыг ойлгохыг хичээдэггүй.

83. Бид үйлчлүүлэгчдийнхээ үгийг сонсдоггүй.

84. Баг нь байгууллагын зорилгод нийцүүлэн ажилладаг.

Хариулт өгсөнд баярлалаа!

Багийн гүйцэтгэлийг үнэлэх Вүүдкок тестийн түлхүүр

Тодорхойлолт

Woodcock тест нь багийн гүйцэтгэлийг хэмжих зорилготой юм. Багийн харилцаа, ажилчдын үр дүнд хүрэх сонирхол, тэдний урам зоригийг үнэлэх боломжийг танд олгоно. Компанийн үнэнч байдал, байгууллагын хэлтэс хоорондын харилцааны түвшинг харгалзан үздэг.

Туршилтын зарчим нь энгийн. Багийн гишүүн бүр албан тушаалаас үл хамааран 84 мэдэгдэл агуулсан асуулга бөглөнө. Дараа нь тусгай хүснэгтийн дагуу үр дүнг тооцож, дүн шинжилгээ хийдэг.

Хэрэв та багийн гишүүд асуултанд үнэнчээр хариулна гэдэгт эргэлзэж байвал туршилтын нэрээ нууцлахыг хичээ. Ерөнхийдөө энэ нь баг дахь харилцааны үзүүлэлт юм. Гэсэн хэдий ч туршилт нь ашигтай хэвээр байгаа тул үр дүн нь багийн ажлын дутагдлыг илүү нарийвчлалтай тодорхойлох боломжийг олгодог.

Үүнээс гадна менежерүүд болон тэдгээрийн харьяа албан тушаалтнуудын шалгалтын үр дүнг харьцуулах нь маш ашигтай байдаг. Энэ нь багийн уур амьсгалыг үнэлж, удирдлагад захирагдах хүмүүсийн итгэлийн түвшинг тодорхойлох боломжийг олгодог.

Туршилтын түлхүүр

Асуулгын хуудаснаас тодруулсан хариултуудыг үр дүнгийн хүснэгтэд шилжүүл. Багана тус бүрийн тэмдгийн тоог тоол. Тоо хэмжээг "Нийт" мөрөнд бичнэ үү.

Үр дүнгийн хүснэгт

	ГЭХДЭЭ	AT	-тай	Д	Э	Ф	Г	Х	I	Ж	руу	Л
	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	48
	49	50	51	52	53	54	55	56	57	58	59	60
	61	62	63	64	65	66	67	68	69	70	71	72
	73	74	75	76	77	78	79	70	81	82	83	84
Нийт

"Нийт" мөрөөс баганын тоог хүснэгт рүү шилжүүлнэ.

Биднийг өөр хувилбар бүтэлгүйтэх болгонд шуугиан тарьдаг. Гэм буруутай хүмүүс тэр даруй гарч ирдэг бөгөөд ихэнхдээ энэ нь бид, шалгагчид байдаг. Програм хангамжийн амьдралын мөчлөгийн сүүлчийн холбоос байх нь хувь тавилан байж магадгүй, тиймээс хөгжүүлэгч код бичихэд маш их цаг зарцуулдаг байсан ч тест нь тодорхой чадвартай хүмүүс гэж хэн ч боддоггүй.
Та толгойноосоо үсэрч чадахгүй ч өдөрт 10-12 цаг ажиллах боломжтой. Би ийм хэллэгийг маш олон удаа сонсдог)))

Туршилт нь бизнесийн хэрэгцээ шаардлагад нийцэхгүй байгаа тохиолдолд цагтаа ажиллах цаг байхгүй бол яагаад тест хийх ёстой вэ гэсэн асуулт гарч ирдэг. Өмнө нь юу болсон юм бэ, яагаад шаардлагаа олигтойхон бичээгүй юм бэ, яагаад архитектураа бодож амжаагүй юм бэ, яагаад код нь муруйсан юм бэ гэдгийг хэн ч бодохгүй байна. Гэхдээ танд эцсийн хугацаа байгаа бөгөөд шалгалтаа дуусгах цаг байхгүй бол тэд таныг шууд шийтгэж эхэлдэг ...

Гэхдээ энэ нь тестер хүний ​​хэцүү амьдралын тухай хэдэн үг байлаа. Одоо гол руугаа 🙂

Хэд хэдэн ийм хуурамч үйлдлүүдийн дараа хүн бүр бидний туршилтын явцад юу буруу байгааг гайхаж эхэлдэг. Магадгүй та удирдагчийн хувьд асуудлыг ойлгож байгаа байх, гэхдээ та тэдгээрийг удирдлагад хэрхэн хүргэх вэ? Асуулт уу?

Удирдлагад тоо, статистик хэрэгтэй. Энгийн үгс - тэд чамайг сонсож, толгойгоо дохиж, "Алив, үүнийг хий" гэж хэлсэн, тэгээд л болоо. Үүний дараа хүн бүр чамаас гайхамшгийг хүлээх болно, гэхдээ та ямар нэгэн зүйл хийсэн ч энэ нь танд бүтэхгүй байсан ч та эсвэл таны удирдагч дахин малгай авах болно.

Аливаа өөрчлөлтийг удирдлага дэмжих ёстой бөгөөд удирдлагад дэмжлэг үзүүлэхийн тулд тоо, хэмжилт, статистик мэдээлэл хэрэгтэй.
Тэд "Бид JIRA-аас хэмжигдэхүүнүүдийг устгадаг" гэж хэлснээр даалгаврын хянагчаас янз бүрийн статистик мэдээлэл оруулахыг оролдсоныг би олон удаа харсан. Гэхдээ хэмжүүр гэж юу болохыг ойлгоцгооё.

Хэмжигдэхүүн нь хяналтын объектын төлөв байдлыг тодорхойлдог техникийн эсвэл процедурын хувьд хэмжигдэхүйц утга юм.

Харцгаая - хүлээн авах туршилтын явцад манай баг 50 согогийг илрүүлсэн. Маш их юм уу? Эсвэл бага уу? Эдгээр 50 согог танд хяналтын объектын төлөв байдал, тухайлбал туршилтын үйл явцын талаар хэлж байна уу?
Тийм биш байх.

Хэрэв танд хүлээн авах туршилтын явцад илэрсэн согогийн тоо 80% байна гэж хэлсэн бол энэ нь ердөө 60% байх ёстой. Маш олон согог байгаа нь нэн даруй тодорхой болсон гэж бодож байна, үүнийг зөөлрүүлбэл хөгжүүлэгчдийн код бүрэн g ... .. чанарын хувьд хангалтгүй байна.

Хэн нэгэн ингэж хэлж чадна, яагаад туршилт хийж байна вэ? Гэхдээ би согог бол туршилтын хугацаа бөгөөд туршилтын хугацаа нь бидний эцсийн хугацаанд шууд нөлөөлдөг гэдгийг хэлье.

Тиймээс бидэнд зөвхөн хэмжүүр биш, KPI хэрэгтэй.

KPI нь хяналтын объектын төлөв байдлын үзүүлэлт болдог хэмжигдэхүүн юм. Урьдчилсан нөхцөл бол зорилтот үнэ цэнэ, тогтоосон хүлцэл байх явдал юм.

Өөрөөр хэлбэл, хэмжүүрийн системийг бий болгохдоо та зорилго, зөвшөөрөгдөх хазайлттай байх ёстой.

Жишээлбэл, та бүх согогийн 90% нь эхний давталтаас шийдэгдсэн байх ёстой (таны зорилго). Үүний зэрэгцээ, энэ нь үргэлж боломжгүй гэдгийг та ойлгож байна, гэхдээ анх удаа шийдэгдсэн согогийн тоо 70% байсан ч энэ нь бас сайн хэрэг юм.

Өөрөөр хэлбэл, та өөртөө зорилго тавьж, хүлээн зөвшөөрөгдөх хазайлтыг тавьдаг. Одоо, хэрэв та хувилбарын согогийг тоолж, 86% -ийн утгыг авах юм бол энэ нь мэдээж сайн биш, гэхдээ энэ нь бүтэлгүйтэхээ больсон.

Математикийн хувьд энэ нь дараах байдлаар харагдах болно.

Яагаад 2 томьёо гэж? Энэ нь өсөх ба буурах хэмжүүрийн тухай ойлголт байдагтай холбоотой юм, i.e. бидний зорилтот үнэ цэнэ 100% эсвэл 0% ойртох үед.

Тэдгээр. Жишээлбэл, хэрэв бид арилжааны үйл ажиллагаанд хэрэгжүүлсний дараа илэрсэн согогуудын тоог ярьж байгаа бол бага байх тусмаа сайн, хэрэв бид туршилтын тохиолдлуудад функцийг хамрах тухай ярьж байгаа бол бүх зүйл эсрэгээрээ байх болно.

Үүний зэрэгцээ, энэ эсвэл бусад хэмжигдэхүүнийг хэрхэн тооцоолох талаар бүү мартаарай.

Бидэнд хэрэгтэй хувь хэмжээ, хэсэг гэх мэтийг авахын тулд хэмжигдэхүүн бүрийг тооцоолох хэрэгтэй.

Тодорхой жишээний хувьд би "Туршилтаар согог боловсруулах цаг хугацаа" хэмжүүрийн талаар танд хэлэх болно.

Миний дээр дурдсан ижил төстэй аргыг ашиглан бид зорилтот утга, хазайлт дээр үндэслэн хэмжүүрийн KPI-ийг бүрдүүлдэг.

Санаа зоволтгүй, энэ нь бодит амьдрал дээр зураг дээр харагдаж байгаа шиг хэцүү биш юм!

Бидэнд юу байгаа вэ?

За тэгээд гарсан дугаар, үйл явдлын дугаар ... гэдэг нь ойлгомжтой.

Чухал - магадлал. 5,

Гол - магадлал. 3,

Бага - магадлал. 1.5.

Дараа нь та согогийг боловсруулах хугацааны SLA-г зааж өгөх хэрэгтэй. Үүнийг хийхийн тулд зорилтот утга ба зөвшөөрөгдөх дээд дахин туршилтын хугацааг хэмжүүрийг тооцоолохын тулд дээр тайлбарласантай адил тодорхойлно.

Эдгээр асуултад хариулахын тулд бид гүйцэтгэлийн хэмжигдэхүүн рүү шууд орж, асуултыг шууд асуух болно. Хэрэв нэг хүсэлтийн утга "тэг" -тэй тэнцүү байвал индикаторыг хэрхэн тооцоолох вэ. Хэрэв нэг буюу хэд хэдэн шалгуур үзүүлэлт тэгтэй тэнцүү байвал эцсийн үзүүлэлт маш их буурах тул "1" зэрэг ноцтой байдлын хүчин зүйлтэй хүсэлтийн тэг утгууд нь тийм ч их биш байхын тулд бидний тооцоог хэрхэн тэнцвэржүүлэх вэ гэсэн асуулт гарч ирнэ. бидний эцсийн үнэлгээнд нөлөөлнө.

Жиннь эцсийн оноонд хамгийн бага нөлөө үзүүлэхийн тулд бидэнд хэрэгтэй утга бөгөөд эсрэгээр, хэрэв бид энэ хүсэлтийг биелүүлэх хугацааг хэтрүүлсэн тохиолдолд хамгийн өндөр түвшний хүсэлт оноонд ноцтой нөлөөлнө.

Тооцоололд үл ойлголцол гарахгүйн тулд бид тооцооллын тодорхой хувьсагчдыг танилцуулах болно.

x нь согогийг дахин шалгахад зарцуулсан бодит хугацаа;

y - зөвшөөрөгдөх хамгийн их хазайлт;

z нь таталцлын хүчин зүйл юм.

Эсвэл нийтлэг хэлээр энэ нь:

W=ESLI(х<=y,1,(x/y)^z)

Тиймээс, бид тогтоосон SLA хязгаараас хэтэрсэн ч ноцтой байдлаас хамааран бидний хүсэлт эцсийн оноонд ноцтой нөлөөлөхгүй.

Дээр дурдсанчлан бүгд:

X– согогийг дахин шалгахад зарцуулсан бодит хугацаа;

y- зөвшөөрөгдөх хамгийн их хазайлт;

zхүндийн хүчний хүчин зүйл юм.

h- SLA-ийн дагуу төлөвлөсөн цаг
Би үүнийг математикийн томъёогоор хэрхэн илэрхийлэхээ мэдэхгүй байгаа тул оператортой програмчлалын хэлээр бичих болно. ХЭРВЭЭ.

R = IF(x<=h;1;ЕСЛИ(x<=y;(1/z)/(x/y);0))

Үүний үр дүнд бид зорилгодоо хүрсэн бол бидний хүсэлтийн утга 1-тэй тэнцүү байна, хэрэв бид зөвшөөрөгдөх хазайлтаас давсан бол үнэлгээ тэгтэй тэнцэж, жинг тооцоолно.

Хэрэв бидний үнэ цэнэ зорилтот болон зөвшөөрөгдөх хамгийн их хазайлтын хооронд байвал ноцтой байдлын хүчин зүйлээс хамааран бидний утга мужид өөр өөр байна.

Одоо би энэ нь манай хэмжүүрийн системд хэрхэн харагдах талаар хэдэн жишээ өгөх болно.

Хүсэлт бүр ач холбогдлоосоо хамааран өөрийн SLA-тай байдаг (хүнд байдлын хүчин зүйл).

Бид энд юу харж байна.

Эхний хүсэлтэд бид зорилтот утгаасаа ердөө нэг цаг хазайсан бөгөөд аль хэдийн 30% гэсэн үнэлгээтэй байсан бол хоёр дахь хүсэлтэд бид зөвхөн нэг цаг хазайсан боловч үзүүлэлтүүдийн нийлбэр 30% байхаа больсон, гэхдээ 42.86%. Өөрөөр хэлбэл, ноцтой байдлын коэффициентүүд нь асуулгын эцсийн үзүүлэлтийг бүрдүүлэхэд чухал үүрэг гүйцэтгэдэг.

Үүний зэрэгцээ, гурав дахь хүсэлтэд бид хамгийн их зөвшөөрөгдөх хугацааг зөрчсөн бөгөөд үнэлгээ нь тэгтэй тэнцүү боловч хүсэлтийн жин өөрчлөгдсөн нь энэ хүсэлтийн эцсийн коэффициентэд үзүүлэх нөлөөг илүү зөв тооцоолох боломжийг бидэнд олгодог.

Үүнийг батлахын тулд та үзүүлэлтүүдийн арифметик дундаж нь 43.21% байх болно гэдгийг тооцоолж болно, бид 33.49% -ийг авсан нь өндөр ач холбогдол бүхий хүсэлт ноцтой нөлөө үзүүлж байгааг харуулж байна.

Систем дэх утгыг 1 цаг болгож өөрчилье.

Үүний зэрэгцээ 5-р тэргүүлэх чиглэлийн хувьд үнэ цэнэ 6%, гурав дахь нь 5.36% -иар өөрчлөгдсөн байна.

Дахин хэлэхэд асуулгын ач холбогдол нь түүний оноонд нөлөөлдөг.

Ингээд л бид хэмжүүрийн эцсийн үзүүлэлтийг авдаг.

Юу чухал вэ!

Би хэмжүүрийн системийг ашиглахдаа миний үнэт зүйлстэй адилтгаж байх ёстой гэж хэлээгүй, би зүгээр л тэдгээрийг хадгалах, цуглуулах хандлагыг санал болгож байна.

Нэг байгууллагад би тэд HP ALM болон JIRA-аас хэмжүүр цуглуулах өөрсдийн хүрээг боловсруулсан болохыг харсан. Энэ үнэхээр дажгүй юм. Гэхдээ хэмжигдэхүүнийг хадгалах ийм үйл явц нь зохицуулалтын үйл явцыг нухацтай дагаж мөрдөхийг шаарддаг гэдгийг санах нь чухал юм.

За, хамгийн чухал нь зөвхөн та хэрхэн, ямар хэмжүүр цуглуулахаа шийдэх боломжтой. Та цуглуулж чадахгүй байгаа хэмжигдэхүүнүүдийг хуулбарлах шаардлагагүй.

Арга нь нарийн төвөгтэй боловч үр дүнтэй байдаг.

Оролдоод үз, магадгүй та ч бас чадна!

Гүйцэтгэлийн лабораторийн үйл ажиллагаа хариуцсан ахлах захирал Александр Мешков нь програм хангамжийн туршилт, туршилтын удирдлага, чанарын хяналтын зөвлөх чиглэлээр 5 гаруй жил ажилласан туршлагатай. Мэргэжилтэн ISTQB, TPI, TMMI.

Орчуулга: Ольга Алифанова

Чанарын баталгаа нь баталгаажуулалт ба баталгаажуулалтыг ялгадаг. Баталгаажуулалт нь бид бүтээгдэхүүнийг зөв бүтээж байна уу гэсэн асуултад хариулдаг бол баталгаажуулалт нь бидэнд хэрэгтэй зүйлээ бүтээж байна уу гэсэн асуултад хариулдаг. Зарим хүмүүс эдгээр тодорхойлолт дээр үндэслэн чанарын баталгаа ба туршилтын хооронд зааг заадаг.

Миний бодлоор "баталгаажуулах", "баталгаажуулах" гэсэн нэр томъёог ашиглах нь худал хоёр хуваагдахад хүргэдэг. Миний хувьд туршилт бол дизайнтай холбоотой үйл ажиллагаа учраас нэлээд өргөн хүрээг хамардаг. Тест нь нэг төрлийн "нийтлэг хэл" болж чадна гэдэгт би итгэдэг. Туршилтууд нь техникийн үзүүлэлт, шаардлагыг шууд кодлох боломжтой гэдэгт би итгэдэг. Туршилтууд нь тухайн салбар эсвэл бүтээгдэхүүний талаархи мэдлэгийн эх сурвалж гэдэгт би итгэдэг. Баталгаажуулалт ба баталгаажуулалтын хоорондох ялгааг хэт их онцлон тэмдэглэх нь туршилт нь чанарын баталгааг хэрхэн нөхөж байгааг ойлгох үр ашиггүй бөгөөд үр ашиггүй арга юм.

Миний бодлоор туршилт, чанарын баталгаажуулалтыг хоёр өөр, бие биенээ нөхөх үйл явц гэж ойлгох чадваргүй байгаа нь тодорхой нарийн мэдрэмжгүй ойлголт юм.

Үнэн хэрэгтээ, баталгаажуулалт, баталгаажуулалтын хоорондох ялгаа нь нэлээд үндэслэлтэй гэдгийг би хүлээн зөвшөөрч байна. Эцсийн эцэст үр ашиг гэдэг нь аливаа зүйлийг зөв хийх чадвар юм. Нөгөө талаар үр ашиг гэдэг нь зөв үр дүнд хүрэх чадвар юм. Үр ашиг нь үйл явцад төвлөрч, түүнийг төгсгөлд нь хүргэхэд чиглэгддэг бөгөөд үр нөлөө нь бүтээгдэхүүн дээр (үнэндээ энэ үйл явцын үр дүнд) байдаг. Үр ашиг нь алдаанаас зайлсхийхэд голлон чиглэгддэг ба үр ашиг нь замдаа гарсан алдааны тооноос үл хамааран амжилтанд чиглэдэг гэж хэлж болно.

Гэсэн хэдий ч баталгаажуулах, баталгаажуулах хоёрын ялгааг ойлгохоос хамаагүй дээр үр ашиг, үр ашгийг ялгах арга байдаг гэж надад санагдаж байна. Эцсийн эцэст, тест нь уян хатан байдал, шинэлэг санааг шаарддаг.

Яг энэ үед нэгэн сонин парадокс үүсдэг. Тасралтгүй, тасралтгүй гүйцэтгэлийг хадгалахын тулд зохих түвшний сахилга бат, хатуужил хэрэгтэй. Гэсэн хэдий ч, сахилга бат, өөрчлөлтийг тэсвэрлэх чадвар нь үйл явцыг уян хатан бус болгодог! Хэрэв та ижил зүйлийг дахин дахин хийвэл шинэлэг зүйл танд хэзээ ч нөлөөлөхгүй.

Энэ нөхцөлд үр ашиг нь баталгаажуулалттай холбоотой байдаг тул баталгаажуулалт нь статик үйл ажиллагаа болж чадна гэсэн үг юм.

Харин гүйцэтгэл нь өөрчлөлтөд илүү дасан зохицож, илүү уян хатан байдлыг шаарддаг. Сайн үр дүнд хүрэхийн тулд та инновацийг дэмжих хэрэгтэй, учир нь тэр үед хүмүүс яг одоо юу хийж байгаа, тодорхой нөхцөл байдалд, тодорхой хүчин зүйлийн нөлөөн дор үүнийг хийх нь зүйтэй эсэх талаар бодох болно. Гэсэн хэдий ч энэхүү уян хатан байдал, дасан зохицох чадвар нь хэт олон сонголт, одоогийн нөхцөл байдлаас гадуур давтагдах ухамсартай байнгын хүчин чармайлт гаргах чадваргүй болоход хүргэдэг.

Бидний нөхцөл байдлын гүйцэтгэл нь баталгаажуулалттай холбоотой байдаг тул дээрх бүх зүйл нь баталгаажуулалт нь хэт динамик үйл ажиллагаа болж чадна гэсэн үг юм.

Эндээс ухаалаг шийдвэр гаргалт гарч, энэхүү харгис мөчлөгийг эвдэж, өөр нүдээр харж өөрийн үр ашиг, үр ашгийг үнэлэх боломжийг танд олгоно. Шийдлийн дэгжин байдал нь зөвхөн асуултуудад хариулдаггүй, бид илүү сайн зүйл хийсэн үү, эсвэл илүү сайн зүйлийг бодож үзсэн үү, харин хариулт өгдөг, бид юу болж байгааг илүү сайн мэддэг болсон уу, цаашдын үйл ажиллагааны үндэс суурийг бий болгосон уу?

Нарийн байдлыг мөн нарийн төвөгтэй байдлыг багасгах гэж үзэж болно. Хөгжлийн ертөнцөд хүмүүс шийдвэрийн нарийн төвөгтэй байдлыг заавал болон санамсаргүй гэж хуваадаг. Тиймээс туршилтын шийдлүүд нь гоёмсог байхын тулд тэдгээр нь зөвхөн "заавал нарийн төвөгтэй байдал" -аас бүрдэх ёстой бөгөөд бараг ямар ч санамсаргүй нарийн төвөгтэй байх ёстой. Нууцлаг сонсогдож байна, тийм үү? Тийм ээ, энэ нь боломжтой, учир нь "нарийн төвөгтэй байдал" хаанаас эхэлдэг талаар маш олон санал бодол байдаг. Миний хувьд тестийн шийдвэрийн нарийн төвөгтэй байдал нь системд ямар ч сонголт байхгүй, тодорхойгүй байдал өндөр байгаа үед үүсдэг.

Хэрэв та шалгалтыг шинэлэг, уян хатан (өөрөөр хэлбэл үр дүнтэй) байхын зэрэгцээ хатуу чанд сахилга бат (үр дүнтэй) байлгахыг зөвшөөрвөл сонголтоо хэрхэн удирдах талаар зарим дүрэм журамтай байх ёстой (энэ сонголтыг хэрхэн хангах гэдэг утгаараа) болон тодорхойгүй байдал (үүнийг хэрхэн устгах).

Би энэ сэдвээр уйдахгүй, харин зүгээр л миний ярьж буй зүйлийн жишээг хэлье. Миний жишээн дээр би туршилтын багийг "үр ашиг", "үр ашиг", "дэгжин" гэсэн үүднээс тестүүдийнхээ талаар бодохыг оролдохыг хүсч байна. Би зарим аксиомоор эхэлж (би өөр үг сонгохгүй) жишээнүүдээ аль болох товч бөгөөд ойлгомжтой болгохыг хичээх болно. Бүхэл бүтэн багийн итгэх ёстой зүйлүүд байдаг - эсвэл ядаж тэдэнд итгэж байгаа мэт ажиллах ёстой. Миний анхны аксиом дээр хэлсэн зүйлийг минь баталж байна!

• Туршилтыг үр дүнтэй, үр дүнтэй, дэгжин хийж болно.
• Туршилт нь идэвхтэй, мэргэжлийн, техникийн судалгаа шаарддаг.
• Туршилтын зорилго нь шаардлагатай мэдээллийг цаг тухайд нь тодорхой танилцуулах явдал юм.
• Тестчид бол нэг ёсондоо зохиолч, редактор юм. Тиймээс нигүүлслийн ёс зүй, мэргэжлийн бахархал нь зохих түвшний анхаарал, сайн, урам зоригтой ажлын зайлшгүй шинж чанар юм.

Эдгээр санааг харуулах хэдэн жишээ энд байна. Эхлээд эдгээр бүх ойлголтыг тесттэй холбон авч үзье.

• Үр дүнтэйтест нь оролт, процесс, гаралт дээр төвлөрөх ёстой.
• БүтээмжтэйТуршилт нь тодорхой байх ёстой бөгөөд шалгалтын зорилгыг харуулах ёстой.
• Үр дүнтэйТуршилт нь хэд хэдэн нэгэн зэрэг биш, харин тодорхой үйл ажиллагааны нэг уялдаатай үр дүнд анхаарлаа хандуулах ёстой.
• БүтээмжтэйТуршилт нь холбогдох ажиглалтуудыг бүлэглэдэг.
• Үр дүнтэйТуршилт нь хүссэн өгөгдлийн тодорхой жишээг өгдөг.
• Бүтээмжтэйтест нь туршсан өгөгдөл унах ерөнхий нөхцлийн талаар өгүүлдэг.
• Дэгжинтест нь системийн онцлог шинж чанар, түүний ажиллагааг тодорхойлдог.

Одоо тестийн багцад эдгээр ойлголтуудыг хэрэгжүүлье:

• Үр дүнтэйтестийн багц нь аль өгөгдөл хүчинтэй, аль нь буруу болохыг тодорхойлдог.
• Үр дүнтэйтуршилтын багц нь хүчинтэй болон хүчингүй өгөгдлийг хоёуланг нь шалгадаг.
• Бүтээмжтэйтестийн багц нь өгөгдлийн төрлүүдийг ангилдаг.
• ДэгжинБизнесийн зорилго, үйл явцыг судлахын тулд тестийн багцыг боловсруулж болно.

Эцэст нь, эдгээр тодорхойлолтыг үйл ажиллагаа болгон тест хийхэд хэрэглэцгээе:

• Үр дүнтэйТуршилт нь судалгааны үйл явцыг зохион бүтээсэн скриптүүдийг ашигладаг.
• Бүтээмжтэйтест нь скриптүүдэд хувьсах чадварыг бий болгодог хайгуулын туршлагыг ашигладаг.
• дэгжинТуршилт нь програмыг хэрхэн ашиглаж байгааг шалгаж хэрэглэгчдэд үнэ цэнийг харуулахын тулд скрипттэй хайгуулын туршлагыг ашигладаг.
• Үр дүнтэйТуршилт нь тухайн бүтээгдэхүүн зорилгоо хэрхэн биелүүлж байгааг харуулах хувилбаруудыг ашигладаг.
• БүтээмжтэйТуршилт нь хэрэглэгчийг сэтгэл хангалуун байлгахын тулд юу тохиолдох ёстойг харуулсан хувилбаруудыг ашигладаг.
• дэгжинТуршилт нь шаардлагыг тодорхойлж, хэрэглээний чадварыг харуулдаг.

Та юу хийж, яаж хийх нь ирээдүйд юу, хэрхэн хийх үндэс суурь болдог учраас энэ бүхнийг ухамсарлах нь чухал. Энэ нь мөн бүлгийн динамик болон дээрх үзэл баримтлалын талаархи эргэцүүлэлтийг дэмждэг. Энд би юу хэлэх гэсэн юм:

• Зарим шалгагчид туршилтын тохиолдлуудыг "туршилтын нөхцөл" гэж нэрлэхийг илүүд үздэг. Зарим нь эсрэгээрээ. Зарим хүмүүс хоёр нэр томъёог үл тоомсорлодог. Гүйцэтгэлийн сорилт нь нөхцөлийг туршиж, туршилтын тохиолдлуудад өөрчлөлт оруулдаг гэдэгт би итгэдэг. Гүйцэтгэлийн туршилт нь хүссэн өгөгдлийн тодорхой параметрээр тодорхойлсон туршилтын нөхцлийг ашигладаг.

• Туршлагатай тестерүүдэд "эерэг/сөрөг тест" гэсэн нэр томьёо аль эрт моодноос гарсан. Гайхамшигтай туршилт нь хүчинтэй болон хүчингүй нөхцлийг тодорхойлоход чиглэгддэг. Энэ нь тестерүүд өөрчлөгдөж болох туршилтын бүх нөхцөлийг тодорхойлох (энэ нь эргээд хүчинтэй болон хүчингүй нөхцлүүдийг бүлэглэхэд хүргэдэг) үр дүнтэй, үр дүнтэй тест хийх ёстой гэсэн үг бөгөөд мөн тодорхой өгөгдлийн багцыг сонгож, мэдээллийг үл тоомсорлон мэдээлэлтэй шийдвэр гаргах ёстой гэсэн үг юм. амрах.

• Нарийн шалгалтууд бол таны шалгалтын аварга юм. Хэрэв танд ижил төстэй зүйлсийг шалгах бүлэг тест байгаа бөгөөд таны цаг хугацаа хязгаарлагдмал бол танд зөвхөн заримыг нь ажиллуулах цаг л байх болно. Ийм тохиолдолд бүх давхаргын алдааг илчлэх магадлал өндөр тестийг ашигла. Ийм туршилтууд нь маш гоёмсог байж болно.
• Үр дүнтэй тест нь хэтэрхий энгийн эсвэл хэтэрхий төвөгтэй биш байх ёстой. Мэдээжийн хэрэг, бүхэл бүтэн цуврал тестийг нэг тохиолдолд багтаах боломжтой боловч тест үүсгэхийн тулд гарч болох гаж нөлөө нь олон тооны алдаануудыг нууж болно. Тиймээс үр дүнгийн тохиолдлууд нь өөр өөр үзэл бодлыг (эсвэл ижил үзэл бодолд хүрэх өөр замыг) агуулсан байх ёстой бөгөөд тусад нь гүйцэтгэнэ.
• Туршилтын зарим аргууд нь тодорхой өгөгдлийг сонгох, эдгээр өгөгдлийг хослуулан эсвэл дарааллаар нь зохион байгуулахад маш үр дүнтэй байдаг. Гэхдээ шалгагчид янз бүрийн функц, өгөгдлийн урсгалын харилцан үйлчлэлд тулгуурлан энэ өгөгдлийг сонгож, амьд хүн энэ системийг хэрхэн ашиглах талаар ойлголттойгоор хэрэглэгчийн интерфэйсээр дамжих замыг судлах үед гоёмсог шийдэл гарч ирнэ.
• Амжилттай гарсан тохиолдол танд мэдээлэл өгөх чадвартай байх ёстой. Таны асуусан асуултанд хариулах тест хэрэгтэй. Туршилтын зорилго нь алдааг олох шаардлагагүй бөгөөд түүний зорилго нь мэдээлэл цуглуулах явдал юм. Сорилт нь алдаа олох үед үнэ цэнэтэй биш бөгөөд энэ нь танд мэдээлэл өгөх боломжтой байх ёстой (хэдийгээр энэ мэдээлэл нь програмд ​​ямар нэг зүйл буруу болвол алдаа байгаа байж болно). Гоёмсог шийдэл нь туршилтын явцад тодорхой мэдээллийг олж авахад чиглэгддэг.

• Үр дүнтэй туршилт хийх нь шаардлага, тэдгээр нь хэрэглэгчид манай бүтээгдэхүүний үнэ цэнийг хэрхэн хүлээн авч буйтай хэрхэн холбоотой болохыг ойлгохыг шаарддаг. Бид зөвхөн техникийн үзүүлэлт, шаардлагыг уншаад зогсохгүй хэрэглэгчдээ ойлгох хэрэгтэй! Гөлгөр тест нь энэхүү ойлголтыг зохион байгуулахын тулд эвристикийг ашигладаг. Энэ нь мөн туршилтыг бодит хүмүүсийн үйлдлүүдийн талаар сэтгэл хөдөлгөм түүхийг ярихыг шаарддаг.

Ямар сорилт нь үр дүнтэй, үр дүнтэй, чамин байх вэ гэсэн асуултад хариулах үүднээс өөрийгөө туйлын үнэн гэж харуулахыг зорьсонгүй гэдгийг би анхнаасаа хэлэх ёстой байсан болов уу. Би зүгээр л санаагаа илэрхийлэхийг хүссэн: эдгээр ойлголтуудын ялгааг ойлгодог туршилтын багууд үүнийг хийж чадна гэдэгт би итгэдэг

Зарим хүмүүсийн аль хэдийн "аз жаргалгүй байдлын томъёо" гэж нэрлээд байгаа гүйцэтгэлийн үнэлгээний зорилго нь зүгээр л шалгагчийг баярлуулах бөгөөд ингэснээр та нэг нь сайн ажилладаг бөгөөд үүний төлөө толгойг нь алгадаж, нөгөө нь муу гэдгийг тоогоор харуулах болно. мөн цохих шаардлагатай ... Зөвхөн энэ шалгуурын дагуу үнэлгээ хийх нь цорын ганц байж болохгүй, тиймээс үүнийг төлөвлөгөөний хэрэгжилт, туршилтын автоматжуулалт гэх мэт бусад үзүүлэлтүүдтэй хамтад нь авч үзэх хэрэгтэй.

Бусад ажилтны нэгэн адил шалгагчийн гүйцэтгэлийг тоон үзүүлэлтээр илэрхийлэх ёстой, өөрөөр хэлбэл. хэмжигдэхүйц үзүүлэлтээр. Гэхдээ ямар үзүүлэлтүүдийг сонгох вэ?

Хамгийн түрүүнд санаанд орж ирдэг зүйл бол олдсон согогуудын тоо юм. Энэ үзүүлэлт нь би шууд Inreco LAN-д нэвтрүүлэхийг оролдсон юм. Гэсэн хэдий ч тэр даруй ширүүн хэлэлцүүлэг өрнөж, энэ шалгуурыг шинжлэхэд хүргэв. Энэ сэдвээр би энэ нийтлэлд ярихыг хүсч байна.

Олдсон согогийн тоо нь туйлын гулгамтгай үзүүлэлт юм. Энэ асуудлыг хэлэлцэж буй сүлжээн дэх бүх эх сурвалжууд үүнийг давтаж байна (http://www.software-testing.ru/, blogs.msdn.com/imtesty, it4business.ru, sqadotby.blogspot.com, blogs.msdn.com / larryosterman , sql.ru , http://www.testingperspective.com/ болон бусад олон). Өөрийнхөө туршлага болон эдгээр нөөцийг задлан шинжилсний дараа би дараахь асуудлын модонд хүрсэн.

Нэгдүгээрт, согогоос согог - зөрчилдөөн. Нэг шалгагч програм дээрх товчлууруудын байршлын согогийг хайж олох боломжтой, нөгөө нь логикийг судалж, туршилтын нарийн төвөгтэй нөхцөл байдлыг гаргаж чадна. Ихэнх тохиолдолд эхний шалгагч нь илүү их согогийг олох болно, учир нь туршилтыг бэлтгэхэд ч хамаагүй бага хугацаа шаардагдах боловч ийм согогийн үнэ цэнэ хамаагүй бага байдаг. Согогийн эгзэгтэй байдлыг нэвтрүүлэх замаар энэ асуудлыг амархан шийддэг. Үүнийг ангилал тус бүрээс олдсон согогийн тоогоор үнэлж болно. Тухайлбал, манайд нэн чухал, чухал, дунд, ач холбогдолгүй гэсэн 4 байна. Гэхдээ шүүмжлэлтэй байдлыг тодорхойлох хил хязгаар нь бүрэн тодорхойгүй байгаа тул бид шүүмжлэлийн албан ёсны шинж тэмдгүүдтэй байгаа ч гэсэн бид илүү найдвартай хоёр замаар явж болно. Эхнийх нь сонгогдсон хугацаанд илэрсэн согогуудын тодорхой хэсэг нь чухал бус согогууд байх ёстой. Хоёр дахь нь үнэлгээнд бага зэргийн согогийг тооцохгүй байх явдал юм. Ийм байдлаар бид шалгагчийн бага зэргийн дутагдлыг дүрслэн, түүнийг (эсвэл илүү олон удаа) гүнзгий ухаж, ноцтой согогийг олохыг албадах замаар аль болох олон согогийг цуглуулах гэсэн хүсэл эрмэлзэлтэй тэмцдэг. Тэд үргэлж байдаг, миний туршлагад итгээрэй. Би хоёр дахь сонголтыг сонгосон - бага зэргийн согогийг хая.

Ийм шалгуурын "гулгамтгай" байдлын хоёр дахь шалтгаан нь системд хангалттай тооны согог байгаа тул шалгагч тэдгээрийг олох боломжтой болно. Энд гурван хүчин зүйл байна. Эхнийх нь системийн логик, технологийн нарийн төвөгтэй байдал юм. Хоёр дахь нь кодчилолын чанар юм. Гурав дахь нь төслийн үе шат юм. Эдгээр гурван хүчин зүйлийг дарааллаар нь авч үзье. Системийг бичсэн логик, технологийн нарийн төвөгтэй байдал нь гарч болох алдаа дутагдалд нөлөөлдөг. Түүгээр ч барахгүй эндхийн хараат байдал нь шууд биш юм. Хэрэв та нарийн төвөгтэй эсвэл танил бус платформ дээр энгийн логикийг хэрэгжүүлбэл алдаа нь голчлон хэрэгжүүлэх технологийг буруу ашигласантай холбоотой байх болно. Хэрэв та нарийн төвөгтэй логикийг анхдагч платформ дээр хэрэгжүүлбэл алдаа нь логик өөрөө болон анхдагч хэл дээр ийм логикийг хэрэгжүүлэх нарийн төвөгтэй байдалтай холбоотой байх магадлалтай. Өөрөөр хэлбэл, системийг хэрэгжүүлэх технологийг сонгохдоо тэнцвэртэй байх шаардлагатай. Гэхдээ ихэнхдээ технологи нь үйлчлүүлэгч эсвэл зах зээлээс хамаардаг тул бид бараг нөлөөлж чадахгүй. Тиймээс энэ хүчин зүйлийг согогуудын боломжит тооны тодорхой коэффициент болгон авч үзэхэд л үлддэг. Түүнээс гадна, энэ коэффициентийн утгыг шинжээч тодорхойлох шаардлагатай.

Кодлох чанар. Энд бид хөгжүүлэгчид ямар ч байдлаар нөлөөлж чадахгүй. Гэхдээ бид: a) дахин, хөгжүүлэгчийн түвшинг шинжээчээр үнэлж, өөр хүчин зүйл болгон оруулах, б) нэгжийн туршилтаар кодонд алдаа гарахаас урьдчилан сэргийлэхийг хичээж, нэгжийн тестийг 100% кодын хамрах ёстой. .

Төслийн үе шат. Төгс төгөлдөрт хязгаар гэж байдаггүй, төгс төгөлдөрт үл нийцэх аливаа зүйлийг согог гэж үзэж болох тул өчүүхэн хөтөлбөр эсвэл тохиолдлоос бусад бүх согогийг олох боломжгүй гэдгийг эрт дээр үеэс мэддэг болсон. Гэхдээ төсөл идэвхтэй хөгжлийн шатанд байгаа бол энэ нь нэг хэрэг, дэмжлэг үзүүлэх үе шатанд байгаа бол огт өөр зүйл. Хэрэв бид системийн нарийн төвөгтэй байдал, технологи, кодчилолын чанарын хүчин зүйлсийг харгалзан үзвэл энэ бүхэн нь шалгагч олох боломжтой согогуудын тоонд эрс нөлөөлдөг нь тодорхой байна. Төсөл дуусах эсвэл дэмжих үе шатанд ойртох тусам (бид үүнийг нөхцөлт байдлаар дуудаж, одоо үүнийг зөн совингоор тодорхойлдог) систем дэх согогийн тоо буурч, улмаар олдсон согогуудын тоо ч бас буурдаг. Энд шалгагчаас тодорхой тооны согогийг олохыг шаардах нь үндэслэлгүй болох мөчийг тодорхойлох шаардлагатай. Ийм мөчийг тодорхойлохын тулд бид нийт согогуудын хэдэн хувийг олж, системд хэдэн согог үлдээж байгааг мэдэх нь сайхан байх болно. Энэ бол тусдаа хэлэлцэх сэдэв боловч нэлээд энгийн бөгөөд үр дүнтэй статистикийн аргыг хэрэглэж болно.

Өмнөх төслүүдийн статистик мэдээнд үндэслэн төслийн янз бүрийн хугацаанд системд хичнээн согог илэрсэн, хэд нь туршилтын баг илрүүлсэн болохыг тодорхой алдаатай ойлгох боломжтой. Тиймээс та туршилтын багийн үр дүнтэй байдлын тодорхой дундаж үзүүлэлтийг авах боломжтой. Үүнийг шалгагч бүрийн хувьд задалж, хувийн үнэлгээ авах боломжтой. Илүү их туршлага, статистик байх тусам алдаа бага байх болно. Системд яг хэдэн алдаа байгааг бид мэдэх үед та "алдаа суулгах" аргыг ашиглаж болно. Мэдээжийн хэрэг, системийн төрөл, логикийн нарийн төвөгтэй байдал, платформ гэх мэт нэмэлт хүчин зүйлсийг харгалзан үзэх шаардлагатай. Тиймээс бид төслийн үе шат ба илэрсэн согогийн хувь хоорондын хамаарлыг олж авдаг. Одоо бид энэ хамаарлыг эсрэг чиглэлд хэрэглэж болно: олдсон согогуудын тоо болон төслийн одоогийн үе шатыг мэдсэнээр бид системийнхээ нийт согогийн тоог тодорхойлж чадна (мэдээж алдаатай). Дараа нь хувийн болон ерөнхий үнэлгээний үзүүлэлтүүд дээр үндэслэн шалгагч эсвэл баг үлдсэн хугацаанд хичнээн согогийг олж болохыг тодорхойлох боломжтой. Энэхүү үнэлгээнд үндэслэн шалгагчийн үр дүнтэй байдлын шалгуурыг аль хэдийн тодорхойлох боломжтой болсон.

Шалгагчийн гүйцэтгэлийн үзүүлэлт дараах байдалтай байж болно.

Согог- илэрсэн согогийн тоо,

Хүнд байдал- илэрсэн согогийн шүүмжлэл,

Нарийн төвөгтэй байдал- системийн логикийн нарийн төвөгтэй байдал;

платформ- системийг хэрэгжүүлэх платформ,

Үе шат- төслийн үе шат,

хугацаань авч үзэж буй хугацаа юм.

Гэхдээ аль хэдийн шалгагчийг хангах ёстой тодорхой шалгуурыг эмпирик байдлаар, тухайн байгууллагын онцлогийг харгалзан сонгох ёстой.

Одоогийн байдлаар бүх хүчин зүйлийг харгалзан үзэх боломжгүй байгаа боловч манай тэргүүлэх хөгжүүлэгч Иван Астафьев, төслийн менежер Ирина Лагер нартай хамтран согогуудын тоо, тэдгээрийн ноцтой байдлыг харгалзан дараах томъёог гаргасан.

, хаана

Э- илэрсэн согогийн тоогоор тодорхойлогддог үр ашиг;

D Хэрэглэгч- үйлчлүүлэгчийн илрүүлсэн, гэхдээ үнэлэгдсэн шалгагч олох ёстой согогуудын тоо;

D шалгагч- шалгагч илрүүлсэн согогийн тоо,

кболон г– нийт согогийн тоог засах хүчин зүйлс.

Энэ томъёоны дагуу үнэлгээ хийхдээ зөвхөн үнэлэгдсэн шалгагчийн хариуцлагатай холбоотой согогийг анхаарч үзэх хэрэгтэй гэдгийг би нэн даруй тэмдэглэхийг хүсч байна. Хэрэв олон шалгагч алдагдсан согогийн хариуцлагыг хуваалцаж байгаа бол энэ согогийг шалгагч бүрийн үнэлгээнд оруулах ёстой. Мөн тооцоололд бага эгзэгтэй согогийг тооцдоггүй.

Тиймээс бид шалгагч биелүүлэх ёстой согогийг илрүүлэх эрчмийн шалгуурыг тусгасан гуравдугаар зэргийн параболатай болно. Ерөнхийдөө, хэрэв шалгагчийн оноо параболаас дээш байвал тэр хүлээгдэж байснаас илүү сайн ажилладаг, хэрэв бага бол илүү муу ажилладаг гэсэн үг юм.

Нийт дүн шинжилгээ хийсэн согогийн тоотой холбоотой нэг нюанс байдаг. Мэдээжийн хэрэг, илүү их статистик байх тусмаа сайн, гэхдээ заримдаа та төслийн янз бүрийн үе шатуудад дүн шинжилгээ хийх хэрэгтэй, заримдаа цаг хугацаа бүрийн тооцоолол хэрэгтэй болно. Мөн хугацаандаа 4 доголдол илэрсэнээс 2 нь захиалагчийнх, 100 доголдол илэрсэн бол 50 нь захиалагчийнх гэсэн нэг хэрэг. Аль ч тохиолдолд захиалагч болон шалгагчийн илрүүлсэн согогийн тооны харьцаа 0.5-тай тэнцүү байх боловч эхний тохиолдолд бүх зүйл тийм ч муу биш, хоёрдугаарт дохио өгөх цаг болсныг бид ойлгож байна.

Нийт согогуудын тоонд математикийн нягт уялдаатай байхыг хичээсэн ч амжилтанд хүрээгүй тул бид ижил Ирина Лагерын хэлснээр энэ томъёонд "таяг" -ыг интервал хэлбэрээр хавсаргасан бөгөөд тус бүрдээ бид өөрсдөө тодорхойлсон. коэффициентүүд. Статистикийн мэдээнд 1-20, 21-60, 60-аас дээш согог гэсэн гурван интервалтай байсан.

Согогуудын тоо	к	г	Олдсон нийт согогийн тооноос захиалагчийн илрүүлсэн согогийн зөвшөөрөгдөх тооцоолсон хэсэг

Хүснэгтийн сүүлчийн баганыг хэрэглэгч энэ дээжээс хичнээн согогийг олж болохыг тайлбарлахын тулд танилцуулсан. Үүний дагуу түүврийн хэмжээ бага байх тусам алдаа их байх бөгөөд үйлчлүүлэгч илүү их согогийг олж мэдэх боломжтой. Функцийн үүднээс авч үзвэл энэ нь хэрэглэгч ба шалгагчийн илрүүлсэн согогуудын тооны харьцааны хязгаарын хамгийн бага утга бөгөөд үүний дараа үр ашиг нь сөрөг болж, график X тэнхлэгийг огтолж буй цэгийг хэлнэ. дээж бага байх тусам тэнхлэгтэй огтлолцох хэсэг нь зөв байх ёстой. Удирдлагын үүднээс авч үзвэл энэ нь түүврийн хэмжээ бага байх тусам ийм үнэлгээ үнэн зөв бага байна гэсэн үг юм, тиймээс бид тестерүүдийг жижиг түүвэр дээр бага хатуу үнэлдэг байх зарчмыг баримталдаг.

Бидэнд дараах хэлбэрийн графикууд байна.

Хар графикт 60-аас дээш согогтой бол шар, 21-60 согогтой бол шар, 20-иос доош согогтой бол ногоон гэсэн шалгуурыг тусгасан байна. Түүврийн хэмжээ их байх тусам график нь зүүн тийшээ х тэнхлэгийг хөндлөн огтолж байгааг харж болно.Урьд дурьдсанчлан үнэлгээний ажилтны хувьд энэ нь түүврийн хэмжээ их байх тусам та энэ тоонд илүү их итгэж болно гэсэн үг юм.

Үнэлгээний арга нь (2) томъёоны дагуу шалгагчийн ажлын үр нөлөөг тооцоолох, залруулах хүчин зүйлийг харгалзан үзэх, энэ тооцоог график дээрх шаардлагатай утгатай харьцуулах явдал юм. Хэрэв оноо графикаас өндөр байвал шалгагч хүлээлтийг хангана, бага бол шалгагч шаардлагатай "бар"-аас доогуур ажиллана. Эдгээр бүх тоо баримтыг эмпирик байдлаар сонгосон бөгөөд байгууллага бүрийн хувьд тэдгээрийг цаг хугацааны явцад өөрчилж, илүү нарийвчлалтай сонгох боломжтой гэдгийг тэмдэглэхийг хүсч байна. Тиймээс, аливаа сэтгэгдэл (энд эсвэл миний хувийн блог дээр) болон сайжруулалтыг би зөвхөн хүлээн авна.

Туршилтын баг болон үйлчлүүлэгч / хэрэглэгч / үйлчлүүлэгчийн олж илрүүлсэн согогийн тооны харьцаагаар үнэлэх энэхүү арга нь надад үндэслэлтэй бөгөөд илүү их эсвэл бага бодитой юм шиг санагдаж байна. Үнэн бол ийм үнэлгээг зөвхөн төсөл дууссаны дараа, эсвэл ядаж системийн идэвхтэй гадны хэрэглэгчид байгаа тохиолдолд л хийж болно. Гэхдээ бүтээгдэхүүн хараахан ашиглагдаагүй бол яах вэ? Энэ тохиолдолд шалгагчийн ажлыг хэрхэн үнэлэх вэ?

Нэмж дурдахад тестерийн үр нөлөөг үнэлэх энэхүү техник нь хэд хэдэн нэмэлт бэрхшээлийг үүсгэдэг.

1. Нэг согог нь хэд хэдэн жижиг хэсгүүдэд хуваагдаж эхэлдэг.

· Ийм байдлыг анзаарсан шалгалтын менежер албан бус аргаар таслан зогсоох хэрэгтэй.

2. Давхардсан бичилтийн тоо нэмэгдэж байгаа тул согогийн менежмент илүү төвөгтэй болдог.

· Алдаа хянах системд согог бүртгэх дүрэм, тэр дундаа ижил төстэй согогийг заавал хянаж үзэх нь энэ асуудлыг шийдвэрлэхэд тусална.

3. Илэрсэн согогийн чанарын үнэлгээ дутмаг, учир нь шалгагчийн цорын ганц зорилго нь согогийн тоо бөгөөд үүний үр дүнд шалгагчийн "чанартай" согогийг хайх хүсэл эрмэлзэл байхгүй болно. Гэсэн хэдий ч согогийн эгзэгтэй байдал, "чанар" -ыг тэнцүүлэх боломжгүй, хоёр дахь нь арай бага албан ёсны ойлголт юм.

· Энд шалгагч, удирдагч хоёрын аль алиных нь “хандлага” шийдвэрлэх үүрэг гүйцэтгэх ёстой. Ийм тоон үнэлгээний утгыг ерөнхийд нь зөв (!) ойлгож байж л энэ асуудлыг шийдэж чадна.

Дээр дурдсан бүх зүйлийг нэгтгэн дүгнэхэд бид шалгагчийн ажлыг зөвхөн илэрсэн согогийн тоогоор үнэлэх нь хэцүү төдийгүй бүрэн зөв биш гэсэн дүгнэлтэд хүрч байна. Тиймээс илэрсэн согогийн тоо нь шалгагчийн ажлын нэгдсэн үнэлгээний зөвхөн нэг үзүүлэлт байх ёстой бөгөөд цэвэр хэлбэрээр биш, харин миний жагсаасан хүчин зүйлсийг харгалзан үзэх ёстой.

Програм хангамжийн туршилт гэдэг нь хөгжүүлж буй програм хангамж/бүтээгдэхүүний чадавхи, чадавхи, хүлээгдэж буй үр дүнд нийцэж байгаа эсэхийг шалгах үнэлгээ юм. Туршилт, чанарын баталгаажуулалтын салбарт янз бүрийн төрлийн аргуудыг ашигладаг бөгөөд энэ нийтлэлд авч үзэх болно.

Програм хангамжийн туршилт нь програм хангамж хөгжүүлэх мөчлөгийн салшгүй хэсэг юм.

Програм хангамжийн туршилт гэж юу вэ?

Програм хангамжийн тест нь хяналттай, хяналтгүй үйлдлийн нөхцөлд кодын хэсгийг турших, гаралтыг ажиглах, дараа нь энэ нь урьдчилан тодорхойлсон нөхцөлийг хангаж байгаа эсэхийг шалгахаас өөр зүйл биш юм.

Төрөл бүрийн багц тестүүд болон тестийн стратегиуд нь нэг нийтлэг зорилгод хүрэхэд чиглэгддэг - кодын алдаа, алдааг арилгах, програм хангамжийн үнэн зөв, оновчтой гүйцэтгэлийг хангах.

Туршилтын арга зүй

Түгээмэл хэрэглэгддэг туршилтын аргууд нь нэгжийн туршилт, нэгтгэх туршилт, хүлээн авах туршилт, системийн туршилт юм. Програм хангамж нь эдгээр туршилтыг тодорхой дарааллаар гүйцэтгэдэг.

3) Системийн туршилт

4) Хүлээн авах туршилтууд

Эхний алхам бол нэгжийн шалгалт юм. Нэрнээс нь харахад энэ нь объектын түвшний туршилтын арга юм. Тусдаа програм хангамжийн бүрэлдэхүүн хэсгүүдийг алдааг шалгадаг. Энэ тест нь програм болон суулгасан модуль бүрийн талаар нарийн мэдлэг шаарддаг. Тиймээс энэ баталгаажуулалтыг тестер биш харин програмистууд хийдэг. Үүнийг хийхийн тулд програм хангамж нь зориулалтын дагуу ажиллаж байгаа эсэхийг шалгадаг тест кодуудыг бий болгодог.

Нэгжээр туршиж үзсэн бие даасан модулиудыг бие биетэйгээ нэгтгэж, алдаа дутагдлыг шалгадаг. Энэ төрлийн шалгалт нь үндсэндээ интерфейсийн алдааг тодорхойлдог. Интеграцийн туршилтыг системийн архитектурын дизайны дагуу дээрээс доош чиглэсэн аргыг ашиглан хийж болно. Өөр нэг арга бол доороос дээш чиглэсэн арга бөгөөд энэ нь хяналтын урсгалын доороос хийгддэг.

Системийн туршилт

Энэ туршилтаар бүхэл системийг алдаа, алдаа байгаа эсэхийг шалгадаг. Энэхүү туршилтыг бүхэл системийн техник хангамж, програм хангамжийн бүрэлдэхүүн хэсгүүдийг хооронд нь холбож, дараа нь шалгана. Энэхүү туршилтыг "хар хайрцаг" тестийн аргын дагуу жагсаасан бөгөөд програм хангамжийн хэрэглэгчийн хүлээгдэж буй үйл ажиллагааны нөхцөлийг шалгадаг.

Хүлээн авах туршилтууд

Энэ бол программ хангамжийг үйлчлүүлэгчид хүлээлгэн өгөхөөс өмнө хийдэг сүүлчийн туршилт юм. Энэ нь бүтээгдсэн программ хангамж нь хэрэглэгчийн бүх шаардлагыг хангаж байгаа эсэхийг баталгаажуулахын тулд хийгддэг. Хүлээн авах туршилтын хоёр төрөл байдаг - нэг нь хөгжүүлэлтийн багийн гишүүдийн гүйцэтгэдэг дотоод хүлээн авах туршилт (Альфа тест), нөгөөг нь үйлчлүүлэгчийн хийдэг гадаад хүлээн авах туршилт гэж нэрлэгддэг.

Туршилтыг ирээдүйн үйлчлүүлэгчдийн тусламжтайгаар хийх тохиолдолд үүнийг хэрэглэгчийн хүлээн авах тест гэж нэрлэдэг. Туршилтыг програм хангамжийн эцсийн хэрэглэгч хийх үед үүнийг хүлээн авах тест (бета тест) гэж нэрлэдэг.

Програм хангамжийн туршилтын горимын нэг хэсэг болох хэд хэдэн үндсэн туршилтын аргууд байдаг. Эдгээр тестүүд нь ихэвчлэн систем дэх алдаа, алдааг илрүүлэхэд бие даан хангалттай гэж үздэг.

Хар хайрцагны туршилт

Хар хайрцагны туршилтыг системийн дотоод ажиллагааны талаар ямар ч мэдлэггүйгээр хийдэг. Тестер нь янз бүрийн оролтоор хангаж, үүсгэсэн гаралтыг турших замаар хэрэглэгчийн орчны програм хангамжийг урамшуулах болно. Энэ туршилтыг хар хайрцаг, хаалттай хайрцаг тест эсвэл функциональ тест гэж нэрлэдэг.

Цагаан хайрцагны туршилт

Цагаан хайрцагны тест нь хар хайрцагны тестээс ялгаатай нь кодын дотоод ажиллагаа, логикийг харгалзан үздэг. Энэ тестийг гүйцэтгэхийн тулд шалгагч нь кодын алдаатай хэсгийг яг таг мэдэхийн тулд кодын мэдлэгтэй байх ёстой. Энэ туршилтыг Цагаан хайрцаг, Нээлттэй хайрцаг эсвэл Шилэн хайрцаг гэж нэрлэдэг.

Саарал хайрцагны туршилт

Саарал хайрцгийн тест буюу саарал хайрцгийн тест нь Цагаан хайрцаг болон хар хайрцагны тестийг хооронд нь холбодог бөгөөд шалгагч нь зөвхөн туршилтыг дуусгахад шаардлагатай бүтээгдэхүүний талаар ерөнхий мэдлэгтэй байдаг. Энэхүү баталгаажуулалтыг баримтжуулалт, мэдээллийн урсгалын диаграмаар хийдэг. Туршилтыг эцсийн хэрэглэгч эсвэл эцсийн хэрэглэгч мэт харагдах хэрэглэгчид хийдэг.

Функциональ бус туршилтууд

Програмын аюулгүй байдал нь хөгжүүлэгчийн үндсэн ажлуудын нэг юм. Аюулгүй байдлын тест нь програм хангамжийн нууцлал, бүрэн бүтэн байдал, баталгаажуулалт, хүртээмжтэй байдал, үгүйсгэхгүй эсэхийг шалгадаг. Програмын код руу зөвшөөрөлгүй нэвтрэхээс урьдчилан сэргийлэхийн тулд бие даасан туршилтуудыг явуулдаг.

Стресс тест гэдэг нь програм хангамжийн хэвийн үйл ажиллагааны нөхцлөөс гадуурх нөхцөл байдалд програм хангамжид өртөх арга техник юм. Чухал цэгт хүрсний дараа үр дүнг тэмдэглэнэ. Энэ туршилт нь бүхэл системийн тогтвортой байдлыг тодорхойлдог.

Програм хангамж нь үйлдлийн систем, техник хангамжийн платформ, вэб хөтөч гэх мэт гадаад интерфейстэй нийцэж байгаа эсэхийг шалгадаг. Тохиромжтой байдлын тест нь бүтээгдэхүүн нь ямар ч програм хангамжийн платформтой нийцэж байгаа эсэхийг шалгадаг.

Нэрнээс нь харахад энэхүү туршилтын арга нь програмын нэг үйлдлийг гүйцэтгэхэд ашигласан код эсвэл нөөцийн хэмжээг шалгадаг.

Энэхүү туршилт нь програм хангамжийн хэрэглэгчдэд ээлтэй байдал, ашиглахад хялбар байдлыг шалгадаг. Хэрэглэгчийн төхөөрөмжид хандах хялбар байдал нь туршилтын гол цэгийг бүрдүүлдэг. Ашиглах чадварын тест нь туршилтын таван талыг хамардаг - суралцах чадвар, гүйцэтгэл, сэтгэл ханамж, санах ой, алдаа.

Програм хангамж боловсруулах үйл явц дахь туршилтууд

Усны хүрхрээ загвар нь програм хангамж боловсруулах эсвэл туршилт хийхэд ашигласан эсэхээс үл хамааран дээрээс доош чиглэсэн аргыг ашигладаг.

Энэхүү програм хангамжийн туршилтын арга зүйд хамаарах үндсэн алхамууд нь:

• Хэрэгцээний шинжилгээ
• Дизайн туршилт
• Хэрэгжүүлэх туршилт
• Код эсвэл бүтээгдэхүүнийг турших, дибаг хийх, баталгаажуулах
• Хэрэгжилт ба засвар үйлчилгээ

Энэ техникээр та өмнөх алхамаа дуусгасны дараа л дараагийн алхам руу шилжинэ. Загвар нь давталтгүй аргыг ашигладаг. Энэхүү аргын гол давуу тал нь хялбаршуулсан, системтэй, ортодокс хандлага юм. Гэхдээ туршилтын үе хүртэл кодын алдаа, алдаа илрэхгүй тул олон сул талтай. Энэ нь ихэвчлэн цаг хугацаа, мөнгө болон бусад үнэт нөөцийг дэмий үрэхэд хүргэдэг.

Agile Model

Энэхүү аргачлал нь нэлээд олон төрлийн шинэ хөгжүүлэлтийн аргуудаас гадна дэс дараалсан болон давтагдах аргыг сонгон хослуулан хэрэглэхэд суурилдаг. Хурдан, дэвшилтэт хөгжил нь энэ арга зүйн гол зарчмуудын нэг юм. Хурдан, практик, харагдахуйц үр дүнд хүрэхийг чухалчилдаг. Хэрэглэгчийн тасралтгүй харилцан үйлчлэл, оролцоо нь хөгжлийн бүх үйл явцын салшгүй хэсэг юм.

Шуурхай програм хөгжүүлэлт (RAD). Шуурхай програм боловсруулах арга зүй

Нэр нь өөрөө ярьдаг. Энэ тохиолдолд аргачлал нь бүрэлдэхүүн хэсгийн барилгын зарчмыг ашиглан хурдацтай хувьслын хандлагыг авч үздэг. Тухайн төслийн янз бүрийн шаардлагуудыг ойлгосны дараа хурдан прототипийг бэлтгэж, хүлээгдэж буй гаралтын нөхцөл, стандарттай харьцуулна. Шаардлагатай өөрчлөлт, өөрчлөлтийг хэрэглэгч эсвэл хөгжүүлэлтийн багтай хамтарсан хэлэлцүүлгийн дараа (програм хангамжийн туршилтын хүрээнд) хийдэг.

Хэдийгээр энэ аргын давуу талтай ч шаардлага байнга өөрчлөгддөг төсөл нь том, нарийн төвөгтэй эсвэл хэт динамик шинж чанартай бол тохиромжгүй байж болно.

спираль загвар

Нэрнээс нь харахад спираль загвар нь хүрхрээ загварын дараалсан бүх үе шатуудаас хэд хэдэн мөчлөг (эсвэл спираль) байх хандлага дээр суурилдаг. Эхний мөчлөг дууссаны дараа хүрсэн бүтээгдэхүүн, гарцын талаар нарийвчилсан дүн шинжилгээ хийж, хянан шалгана. Хэрэв гаралт нь тогтоосон шаардлага эсвэл хүлээгдэж буй стандартыг хангаагүй бол хоёр дахь мөчлөгийг гүйцэтгэдэг гэх мэт.

Рационал нэгдсэн процесс (RUP). Рациональ нэгдсэн үйл явц

RUP аргачлал нь мөн л спираль загвартай төстэй бөгөөд энэ нь туршилтыг бүхэлд нь хэд хэдэн мөчлөгт хуваадаг. Цикл бүр нь бүтээх, хөгжүүлэх, барих, шилжих гэсэн дөрвөн үе шатаас бүрдэнэ. Цикл бүрийн төгсгөлд бүтээгдэхүүн/гарцыг хянаж, шаардлагатай бол дараагийн мөчлөг (ижил дөрвөн үе шатаас бүрдэх) хийгдэнэ.

Мэдээллийн технологийн хэрэглээ өдөр бүр өсөн нэмэгдэж байгаа бөгөөд програм хангамжийн зөв туршилтын ач холбогдол ихээхэн нэмэгдсэн. Олон пүүсүүд үүнд зориулж тусгай баг ажиллуулдаг бөгөөд тэдний чадвар нь хөгжүүлэгчдийн түвшинд байдаг.