Тэставанне без рэсурсу якасці

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

Тут ёсць дзве школы думак:

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


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

Абодва гэтыя перакананні крайнія.


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



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

Ці дастаткова тэставання распрацоўшчыкам?

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

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


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

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

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

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


Чаму нам усё яшчэ патрэбны кантроль якасці?

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

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

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

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


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

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