Як наладзіць функцыю кантролю якасці з нуля

Гэта звычайны сцэнар: стартап-кампанія мае новую ідэю і наймае шэраг распрацоўшчыкаў для стварэння рабочай мадэлі ідэі.

З-за характару стартапаў, гэта значыць недаступнага фінансавання на кароткі прамежак часу для распрацоўкі ідэі, асноўныя намаганні сканцэнтраваны на стварэнні новага прадукту, каб яго можна было прачытаць у вольным доступе, і, натуральна, тэставанне і кантроль якасці не з'яўляецца галоўным прыярытэтам для каманды распрацоўшчыкаў.

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


Нейкі час тэставанне праводзіць той, хто даступны ў кампаніі, і гэта ў асноўным спецыяльна, без належных працэсаў.

Затым надыходзіць момант, калі стартап-кампанія вырашае наняць першага старшага спецыяліста па кантролі якасці, каб пачаць укараняць новы працэс кантролю якасці для каманды распрацоўшчыкаў.


У гэтым артыкуле я мяркую, што стартап - гэта вэб-кампанія, напрыклад вэб-сайт электроннай камерцыі.





Укараненне працэсу забеспячэння якасці

Асноўная мэта правядзення працэсу забеспячэння якасці - гарантаваць, што правільны прадукт пабудаваны правільна ў першы раз. Гэта азначае, што мы павінны пераканацца, што патрабаванні правільна вызначаны, і каманда распрацоўшчыкаў дакладна разумее функцыянальнасць новых функцый, перш чым пачаць праграмаваць.

Важна адзначыць, што тэставанне - гэта не фаза, гэта дзейнасць, і тэставанне пачынаецца з самага пачатку працэсу распрацоўкі, адразу з моманту напісання гісторый карыстальнікаў.

Тэставанне павінна падтрымліваць распрацоўку, таму дзейнасць па тэставанні ідзе паралельна распрацоўцы, і на кожным этапе працэсу распрацоўкі нам неабходна забяспечыць дбайнае тэсціраванне кода.


Перш чым укараняць працэс тэставання, нам неабходна ведаць сучасную методыку і працэс распрацоўкі і пры неабходнасці ўнесці карэктывы для паляпшэння працэсу.

Рэгрэсійнае тэсціраванне / тэсціраванне спрынтам

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

Паралельна ёсць як мінімум дзве задачы: тэставанне новых гісторый у спрынце і правядзенне пэўнай ступені рэгрэсійнага тэсціравання.

Тэставанне новых функцый мае прыярытэтнае значэнне, бо ёсць большая верагоднасць знайсці памылкі ў новым кодзе, чым парушэнне бягучага працоўнага сайта. Але ў той жа час неабходна правесці тэставанне рэгрэсіі, каб гарантаваць, што існуючае прыкладанне будзе працягваць функцыянаваць па меры стварэння новых функцый.


Пакет рэгрэсійнага тэсціравання неабходна выканаць, як толькі будзе абноўлена праграма, каб каманда распрацоўшчыкаў магла атрымаць яе хуткая зваротная сувязь па стане здароўя прыкладання.

Не хапае часу, каб пісаць рэгрэсійныя тэсты, а таксама ісці ў нагу з тэставаннем новых функцый. Як мы можам разарваць гэты цыкл?

Звычайна ў першыя некалькі дзён спрынту распрацоўшчыкі занятыя кадзіраваннем, таму новыя функцыі некаторы час не будуць гатовыя да тэставання. Вось добры шанец пачаць працаваць над рэгрэсійнымі тэстамі.

Існуе лепшая практыка рэгрэсійнага тэсціравання, але ў цэлым падыход заключаецца ў вызначэнні асноўных паездак асноўных карыстальнікаў па ўсім вэб-сайце, каб у кожным новым выпуску вэб-сайта мы маглі быць упэўнены, што прыкладанне па-ранейшаму выкарыстоўваецца большасцю яго карыстальнікі.


Не трэба мець вычарпальнага спісу гэтых сцэнарыяў, дастаткова будзе толькі асноўнага і найбольш важнага, каб пачаць невялікі пакет рэгрэсіі, які можна выканаць пры кожнай зборцы. Пазней, па меры сталення пакета рэгрэсіі, мы можам пачаць дадаваць новыя сцэнарыі.

Самае галоўнае, што гэтыя сцэнарыі рэгрэсу павінны быць аўтаматызаваны.

Аўтаматызаванае тэсціраванне

У гнуткім праекце, дзе спрынт звычайна доўжыцца каля двух тыдняў, не хапае часу, каб правесці ўсе выпрабаванні ўручную. Існуе тэставанне новых гісторый, а таксама рэгрэсійнае тэсціраванне. Хоць мае сэнс правесці даследчае тэсціраванне для праверкі новых функцый, рэгрэсійныя тэсты павінны быць аўтаматызаваны, каб паменшыць банальную задачу паўторнага выканання адных і тых жа тэстаў уручную.

Развядзенне / зборка трубаправода

Разгортванне альбо пабудова канвеера ў гнуткім праекце вызначае, як гісторыя трапляе з адставання прадукцыі на рэальную вытворчую пляцоўку. Ён вызначае працэс і дзейнасць, якія адбываюцца на кожным этапе.


Для таго, каб рэалізаваць паспяховы працэс кантролю якасці, які гарантуе, што мы часта выпускаем якасны код, канвеер разгортвання павінен быць вызначаны і прытрымлівацца ўсіх зацікаўленых бакоў. Канвеер разгортвання - гэта аснова пастаўкі праграмнага забеспячэння.

Канвеер павінен грунтавацца на перадавой практыцы і ўключаць дзейнасць, якая адбываецца на кожным этапе.

Сюжэтныя майстэрні

Адно з самых важных мерапрыемстваў у гнуткім праекце - частае правядзенне семінараў-сюжэтаў. Гэта калі ўладальнік прадукту, распрацоўшчыкі і тэсціроўшчыкі збіраюцца ў пакоі і пачынаюць распрацоўваць і ўдакладняць дэталі гісторый. Гэта важна, таму што перад пачаткам распрацоўкі ўсе павінны разумець гісторыю аднолькава.

Забеспячэнне якасці заключаецца ў папярэджанні дэфектаў, а не ў выяўленні, і таму на семінарах-сюжэтах каманда атрымлівае магчымасць задаць пытанні пра падрабязнасці гісторыі, любыя тэхнічныя і дызайнерскія абмежаванні і любыя перашкоды для развіцця гісторый.

Тут ёсць выдатная магчымасць пачаць выпісваць крытэрыі прыняцця гісторый. Кожны павінен унесці свой уклад і пачаць думаць пра магчымыя сцэнарыі для кожнай гісторыі, бо ў кожнага з іх будзе свая ідэя, таму, чым больш удзелу ў гісторыі, тым больш сцэнарыяў можна прадумваць і тым больш шанцаў прадухіліць дэфекты.

Пасля таго, як усе вызначаюцца ў дэталях і аб'ёмах кожнай гісторыі, пачынаецца распрацоўка.

Тэставанне распрацоўшчыка / тэсціраванне падчас распрацоўкі

Кожны чалавек павінен несці адказнасць за якасць прадукцыі, а не толькі тэстары. Такім чынам, павінна быць дастатковая колькасць 'тэставання распрацоўшчыкам', каб гарантаваць высокую якасць напісанага кода перад тым, як яго разгортваць у тэставае асяроддзе для далейшага тэсціравання.

Безумоўна, кожная новая функцыянальная частка павінна быць добра пратэставана. Акрамя гэтага, павінны быць інтэграцыйныя тэсты, тэсты API, а таксама тэсты карыстацкага інтэрфейсу.

Ацэнкі кадоў і 'тэсціраванне прыяцеляў' могуць паставіць другое вока на працу распрацоўшчыка. Тэстар можа дапамагчы ў аглядзе модульных тэстаў, а таксама тэстаў API, каб пераканацца, што былі напісаны правільныя тэсты, а таксама дапамагчы напісаць аўтаматызаваныя тэсты карыстацкага інтэрфейсу высокага ўзроўню.

Бесперапынная інтэграцыя / тэставае асяроддзе

Для эфектыўнага тэставання новых функцый нам неабходна забяспечыць, каб код працаваў не толькі на машыне распрацоўшчыка, але і ў іншых асяроддзях, і быў інтэграваны з кодам іншага распрацоўніка.

Бесперапынная інтэграцыя дапамагае выяўляць любыя праблемы зборкі на самым пачатку працэсу, так што, калі разгортванне не ўдаецца, мы можам пачаць шукаць, адкуль узнікае праблема.

Тэставае асяроддзе дае тэсцерам і іншым членам каманды магчымасць праверыць новыя функцыі перад выхадам у эксплуатацыю.

Нефункцыянальнае тэсціраванне

Пры неабходнасці мы павінны таксама правесці нефункцыянальнае тэсціраванне, такое як тэставанне прадукцыйнасці, нагрузкі і бяспекі. Даволі часта асноўная ўвага надаецца забеспячэнню добрай функцыянальнасці, аднак нефункцыянальнаму тэсціраванню трэба аддаваць той самы прыярытэт, асабліва для вэб-прыкладанняў, бо яны могуць падвяргацца вялікай нагрузцы і / або атакам.

Праводзячы нефункцыянальнае тэсціраванне, мы можам быць упэўнены, што наша прыкладанне можа апрацоўваць нагрузку ў пікавыя перыяды і не падвяргаецца пагрозам бяспецы.

Іншыя моманты для разгляду

  • Крос-браўзэр, Крос-тэставанне прылад
  • Тэставанне мабільных і планшэтных кампутараў
  • Паралельнае выкананне аўтаматызаваных тэстаў
  • Даследчае тэсціраванне
  • Такія інструменты, як Джыра, Джэнкінс, Селен і г.д. ...
  • Пастаяннае ўдасканаленне
  • Набор выпрабавальнікаў