Kas ir ielaušanās tests un kad uzņēmumam tas ir vajadzīgs

Skenēšana, audits un ielaušanās tests ir trīs dažādi darbi ar trim dažādām cenām. Kurš no tiem atbild uz Jūsu jautājumu, un ko Latvijas normatīvie akti patiesībā prasa.

Jūs prasāt piedāvājumu vietnes drošībai un saņemat trīs, kuri atšķiras desmitkārtīgi, un vienā stāv „drošības skenēšana“, otrā „drošības audits“, trešajā „ielaušanās tests“, bet visos trijos ir viens un tas pats vārds „drošība“, kurš neko no tā, kas atšķiras, nepasaka. Tie nav viens darbs trīs pakāpēs un nav trīs cenas par to pašu, bet trīs dažādi darbi, kuri atbild uz trim dažādiem jautājumiem, tāpēc pirmais solis nav cenu salīdzināšana, bet saprašana, uz kuru no tiem trim jautājumiem Jūs patiesībā gribat atbildi.

Šis raksts atbild uz diviem: kas ir ielaušanās tests un vai tas ir vajadzīgs tieši Jūsu uzņēmumam. Otrais jautājums ir svarīgākais, jo lielākajai daļai Latvijas mazo un vidējo uzņēmumu neviens normatīvais akts ielaušanās testu tieši neprasa, un piedāvājums, kurš to noklusē, pārdod Jums pareizo pakalpojumu nepareizajā brīdī.

Mēs to rakstām, pārdodot drošības auditu, un tajā nav pretrunas, jo audits, kurā ir vieta manuālai pārbaudei, un ielaušanās tests, kuru prasa regula, nav viens un tas pats darbs, bet uzņēmums, kurš nopērk otro tad, kad tam vajadzēja pirmo, samaksā vairāk un uzzina mazāk.

Trīs darbi, kurus pārdod ar līdzīgiem nosaukumiem

Nozares terminoloģija šeit ir netīra, bet zem tās ir skaidra robeža, kuru vislabāk nosauc standartu iestāde: NIST SP 800-115 definē ielaušanās testu kā drošības testēšanu, kurā vērtētāji atdarina reālus uzbrukumus, lai atrastu ceļus apkārt sistēmas aizsardzībai, un norāda, ka tas meklē ievainojamību kombinācijas, ne atsevišķus atradumus. Tā pati publikācija ievainojamību skenēšanu apraksta kā paņēmienu, ar kuru identificē resursus un tiem atbilstošās zināmās ievainojamības.

Praksē tas nozīmē četrus atšķirīgus darbus, kurus ir vērts nosaukt katru atsevišķi. Skenēšana ir automātiska, un tajā rīks salīdzina Jūsu sistēmu ar zināmo ievainojamību datubāzi un atgriež sarakstu. Ievainojamību novērtējums ir tas pats saraksts, kuru cilvēks ir pārbaudījis un sakārtojis, parasti neizmantojot nevienu no atrastajām ievainojamībām. Ielaušanās tests ir cilvēka vadīts darbs, kurā atrastās vājās vietas tiek izmantotas un savienotas ķēdē, lai noskaidrotu, cik tālu uzbrucējs tiešām tiek. Atbilstības audits atbild uz pavisam citu jautājumu: vai sistēma atbilst nosauktam standartam vai normai.

Robežu starp pirmajiem trim visskaidrāk noformulē maksājumu karšu standarts, kurš to dara nevis ar definīciju, bet ar mērķi: PCI drošības standartu padomes vadlīnijas atšķir ielaušanās testu no skenēšanas pēc mērķa: skenēšana identificē, sakārto un ziņo par ievainojamībām; tests meklē veidus, kā tās izmantot, lai apietu sistēmas aizsardzību. Tā pati padome savā standartā piebilst abas malas: skenēšana pati par sevi nav ielaušanās tests, un tests, kurš tikai mēģina izmantot skenera atradumus, arī nav pietiekams.

Tāpēc jautājums „vai Jums vajag ielaušanās testu“ nav jautājums par budžetu, bet par to, uz ko Jūs gribat atbildi: vai Jūsu sistēmā ir zināmas vājās vietas, vai arī kāds ar tām patiešām var kaut ko izdarīt.

Ko katrs no tiem atbild un ko nepasaka

Skenēšana atbild ātri un lēti, un tās vājā vieta ir konteksts, jo rīks nezina, kura no simts atzīmētajām rindām ir Jūsu maksājumu formā un kura ir testa vidē, kuru neviens nesasniedz no interneta, un tas nezina arī to, ka divas atsevišķi nekaitīgas kļūdas kopā dod piekļuvi datubāzei — tāpēc saraksts ir sākums darbam, ne darba rezultāts.

Ielaušanās tests atbild lēnāk un dārgāk, un tā vērtība ir tieši ķēdē, jo testētājs meklē nevis „vai šeit ir ievainojamība“, bet „ko es ar to varu izdarīt“ — vai no publiskās formas var nokļūt līdz administratora tiesībām, vai no viena klienta konta var redzēt cita klienta datus, vai no testa vides var aizsniegt produkcijas datubāzi. Atbilde uz šo jautājumu ir tā, kuru direktors saprot bez tulkojuma.

Atbilstības audits nedara ne vienu, ne otru, jo tas pārbauda, vai sistēma atbilst normai, un tā rezultāts ir spriedums par atbilstību, nevis saraksts ar tehniskām vājībām; tieši tāpēc uzņēmums var izturēt atbilstības auditu un tajā pašā nedēļā tikt uzlauzts, un tajā nav nekādas pretrunas, jo divi dokumenti atbild uz diviem dažādiem jautājumiem.

Neviens no šiem darbiem neaizstāj pārējos un neviens no tiem nav „labāks“ par citiem, tāpēc vienīgais jēgpilnais jautājums ir tas, kurš no tiem šobrīd atbild uz to, kas Jums patiešām jāzina.

Vārdu neskaidrība nav tikai latviešu problēma, un to redz, salīdzinot tirgus: Somijā, Zviedrijā un Norvēģijā tirgus pārdod divus darbus — skenēšanu un ielaušanās testu — un vidējam variantam nosaukuma nav; tas tiek uzskatīts par skenēšanas rezultātu, ne par atsevišķu pakalpojumu. Vācijā ir pretēji, jo tur viens vārds mēdz apzīmēt visus trīs darbus, ieskaitot pašu testu, un tieši tāpēc piedāvājumu salīdzināšanā nosaukums ir vājākais iespējamais orientieris, bet vienīgais drošais jautājums paliek tas, vai atrastās ievainojamības tiks izmantotas.

Vai likums to prasa tieši Jums

Šeit ir vērts būt precīziem, jo šī ir vieta, kurā piedāvājumi visbiežāk pārspīlē: Latvijā ielaušanās testu pēc nosaukuma prasa viens vienīgs normatīvais akts, un tas neattiecas uz katru uzņēmumu, kuram ir mājaslapa.

Nacionālās kiberdrošības likums, kurš stājās spēkā 2024. gada 1. septembrī un pārņem Eiropas Savienības direktīvu 2022/2555, nosaka pienākumus subjektiem: pašnovērtējumu par savu statusu, atbildīgo personu, riska pārvaldību un incidentu ziņošanu. Ielaušanās tests pašā likumā pēc nosaukuma nav minēts nevienā pantā.

To nosauc Ministru kabineta noteikumi Nr. 397 „Minimālās kiberdrošības prasības“, kuri ir spēkā no 2025. gada 2. jūlija. To 131.1. punkts prasa ielaušanās testu pirms sistēmas nodošanas ekspluatācijā un pēc tam ne retāk kā reizi trijos gados, bet tikai tad, ja Jūs esat likuma subjekts un konkrētā sistēma ir A klases sistēma. Tie paši noteikumi paredz, ka uzraudzības iestāde var pieprasīt ielaušanās testu vai drošības skenēšanu arī citos gadījumos.

Tie ir divi nosacījumi kopā, ne viens: uzņēmums, kurš nav likuma subjekts, no šī punkta pienākumu neiegūst, un subjekts, kura sistēma nav A klases, arī ne, tāpēc pirmais solis nav piedāvājuma prasīšana, bet pašnovērtējums par to, vai Jūs vispār esat subjekts.

Kā saprast, vai esat subjekts

Nacionālās kiberdrošības likums neuzskaita uzņēmumus pēc nosaukuma, bet apraksta nozares un lielumu, un pienākums novērtēt savu statusu ir uzlikts pašam uzņēmumam, kas praksē nozīmē divus jautājumus: vai Jūsu darbība ietilpst kādā no likumā nosauktajām jomām, un vai uzņēmuma lielums sasniedz noteikto slieksni. Uz abiem jāatbild pašiem, un atbilde ir jādokumentē — tieši tāpēc pirmais izdevums šajā jomā parasti ir juridiska konsultācija, ne tehnisks pakalpojums.

Ja atbilde ir „nē“, tālākie punkti par sistēmu klasēm uz Jums neattiecas vispār, un, ja atbilde ir „jā“, nāk otrais jautājums par to, kurai klasei pieder konkrētā sistēma. Prasība par ielaušanās testu ir piesaistīta augstākajai klasei, ne subjekta statusam kā tādam, un uzņēmums var būt subjekts, kura nevienai sistēmai šī prasība nepiemērojas.

Ir arī trešais ceļš, kurš neprasa konkrētu sistēmas klasi, lai gan subjekta statusu tas prasa tāpat kā pārējie: Nacionālais kiberdrošības centrs vai Satversmes aizsardzības birojs var pieprasīt ielaušanās testu jebkurai subjekta informācijas sistēmai atsevišķā gadījumā. Tas nav plānojams pienākums, bet tas ir iemesls zināt, kurš Jūsu pusē uz šādu pieprasījumu atbildētu.

Pārējie sliekšņi nosauc testēšanu, ne ielaušanās testu

Vispārīgās datu aizsardzības regulas 32. pants prasa regulāri testēt un izvērtēt drošības pasākumu efektivitāti, un prasības apjoms ir piesaistīts riskam. Tas nav tas pats, kas pienākums reizi gadā pasūtīt ielaušanās testu, un piedāvājums, kurš 32. pantu pasniedz kā tādu, pārstāsta regulu brīvāk, nekā tā ir uzrakstīta. Pienākums pierādīt, ka testēšana vispār notiek, ir īsts; pienākums izvēlēties tieši šo testēšanas veidu no 32. panta neizriet.

Maksājumu karšu standarts PCI DSS 11.4. prasībā ielaušanās testu nosauc tieši, reizi divpadsmit mēnešos un pēc būtiskām izmaiņām, bet tas ir līgumisks pienākums un attiecas uz to, kā Jūs pieņemat kartes. Interneta veikals, kurš maksājumus pilnībā novirza maksājumu pakalpojumu sniedzējam un pats kartes datus neapstrādā, un pārējie, kuru vidē kartes dati nonāk, atbild uz šo prasību atšķirīgi. Tas ir jautājums, uz kuru atbild Jūsu pieņēmējbanka, ne raksts.

Finanšu sektorā regula 2022/2554 prasa regulāru testēšanu, un draudu vadītu ielaušanās testēšanu (DVIT) tā paredz tikai tām iestādēm, kuras uzraugs īpaši norādījis. Standarts ISO/IEC 27001 prasa ievainojamību pārvaldību un drošības testēšanu, ielaušanās testu pēc nosaukuma neprasot; apgalvojums, ka bez tā sertifikāciju neizsniedz, ir izplatīts un standartā nav atrodams.

Ja neviens no šiem sliekšņiem uz Jums neattiecas, tad normatīvā pienākuma pasūtīt ielaušanās testu Jums nav, un tas nenozīmē, ka nav ko darīt, bet gan to, ka darāmais ir cits.

Ja neviens slieksnis nav pārkāpts

Uzņēmumam, kurš nav subjekts, kartes datus neapstrādā un finanšu sektorā nedarbojas, jēgpilnākais darbs parasti ir tas, kas notiek regulāri, nevis reizi trijos gados. Tie ir atjauninājumi, kuriem ir atbildīgais un termiņš; dublējumkopijas, kuras kāds reizi ir atjaunojis un pārliecinājies, ka tās tiešām atjaunojas; daudzfaktoru autentifikācija administratoru kontiem, kuru Ministru kabineta noteikumi Nr. 397 subjektiem nosauc atsevišķi un kura pārējiem ir tikpat lietderīga; un regulāra skenēšana, kuras rezultātus kāds patiešām izlasa.

Šis nav mazāks atbildes variants, bet cits darba veids. Lielākā daļa uzlaušanas gadījumu, ar kuriem mēs strādājam, sākas nevis ar izsmalcinātu uzbrukumu, bet ar neatjauninātu komponenti vai ar paroli, kura derēja arī citur, un ielaušanās tests, kurš notiek reizi trijos gados, no tā nepasargā. Ja Jūsu vietne jau ir cietusi, secība ir cita un to apraksta atsevišķs raksts par to, kā atkopt uzlauztu mājaslapu.

Ielaušanās tests kļūst pamatots tad, kad ir kaut kas, ko var zaudēt, un kad zaudējuma apjoms ir lielāks par testa cenu: sistēma, kurā ir citu cilvēku dati, integrācija, kura pieskaras naudai, vai pasūtītājs, kurš prasa pierādījumu. Līdz tam brīdim tas ir pareizs darbs nepareizā secībā.

Kas testa laikā notiek

Darbs sākas ar apjoma noteikšanu un beidzas ar atskaiti, un starp tiem ir trīs posmi, kurus ir vērts saprast pirms piedāvājumu salīdzināšanas, jo tieši tie izskaidro, kāpēc viens tests maksā tik, cik maksā, un kāpēc otrs par to pašu sistēmu maksā desmit reižu mazāk.

Pirmais posms ir izlūkošana, kurā testētājs savāc visu to, ko par sistēmu var uzzināt no ārpuses — kādas adreses ir publiskas, kādas tehnoloģijas un versijas ir redzamas, kur ir pieteikšanās formas, kādi faili ir pieejami bez autorizācijas. Šajā posmā vēl nekas netiek izmantots, bet tieši šeit visbiežāk atrodas atradumi, kurus neviens nav gaidījis: aizmirsta testa vide, atvērts direktoriju saraksts, dublējums, kurš guļ zem paredzamas adreses.

Otrais posms ir pati pārbaude, kurā automātiskie rīki tiek palaisti, lai neizlaistu zināmo, bet lēmumus pieņem cilvēks, kurš pārbauda, vai atradums ir īsts, mēģina to izmantot un skatās, ko ar to iegūst. Šeit rodas ķēde — piekļuve vienam kontam, no tā piekļuve funkcijai, kurai nevajadzēja būt sasniedzamai, no tās piekļuve datiem. Atsevišķi neviens no soļiem nav dramatisks; kopā tie ir stāsts.

Trešais posms ir pierādīšana un pierakstīšana, jo katram atradumam ir jāpaliek pierādījumam, kuru var atkārtot: kāds pieprasījums tika nosūtīts, kāda bija atbilde, kas mainījās. Bez tā atskaite ir viedoklis, un izstrādātājs, kurš to saņem, pavada dienu, mēģinot saprast, ko tieši testētājs redzēja.

Tāpēc arī termiņi ir tādi, kādi ir: vienas nelielas vietnes tests ir dažas dienas, bet sistēma ar vairākām lomām, integrācijām un maksājumiem ir nedēļas, un piedāvājums, kurš sola pilnu ielaušanās testu vienā dienā, apraksta nevis testu, bet skenēšanu.

Kāpēc piedāvājumi atšķiras desmitkārtīgi

Kad divi piedāvājumi par vienu un to pašu vietni atšķiras desmit reizes, atšķirība gandrīz nekad nav peļņas normā, un tā gandrīz vienmēr ir apjomā un metodē: viens piedāvā automātisku skenēšanu ar rīku, kuru palaiž stundā un kura atskaiti ģenerē tas pats rīks, bet otrs piedāvā nedēļu ilgu cilvēka darbu, kurā rīki ir tikai sākums, un tieši šī atšķirība ir tā, ko nosaukums „drošības pārbaude“ abos gadījumos noslēpj.

Otrs cenu veidojošais faktors ir sistēmas sarežģītība, un to var novērtēt, pirms saruna sākas: viena publiska mājaslapa bez lietotāju kontiem ir viens darbs, bet sistēma ar vairākām lomām, maksājumiem, ārēju integrāciju un datiem, kuri pieder klientiem, ir pavisam cits, jo katra loma ir atsevišķa pārbaudāma robeža un katra integrācija ir vieta, kurā divas sistēmas viena otrai uzticas vairāk, nekā vajadzētu.

Trešais ir tas, ko pēc testa Jūs saņemat un cik ilgi izpildītājs paliek klāt: atskaite bez prioritātēm, bez pierādījumiem un bez atkārtotas pārbaudes maksā mazāk tāpēc, ka tā ir mazāks darbs, un uzņēmumam, kuram pēc tam jāizlabo atradumi, tieši šīs trīs lietas izšķir, vai dokuments kļūst par uzdevumu sarakstu vai par mapi, kuru neviens vairs neatver.

Tāpēc salīdzināt piedāvājumus pēc cenas ir iespējams tikai tad, kad apjoms ir uzrakstīts vienādi, un vienkāršākais veids to panākt ir uzrakstīt apjomu pašiem un lūgt visiem piedāvāt uz tā, nevis ļaut katram izpildītājam definēt savu.

Kad tests noveco

Ielaušanās testa rezultāts apraksta konkrētu sistēmu konkrētā datumā, kas ir acīmredzami, un tomēr tieši šeit rodas lielākā daļa nesaprašanās starp izpildītāju un pasūtītāju, jo atskaite, kura ir gadu veca, apraksta kodu, kurš kopš tā laika ir mainījies desmitiem reižu.

Normatīvie termiņi to atzīst paši: Ministru kabineta noteikumos līdzās trīs gadu intervālam stāv prasība testēt pirms sistēmas nodošanas ekspluatācijā, un maksājumu karšu standartā līdzās gada intervālam stāv „pēc būtiskām izmaiņām“, tā ka abos gadījumos kalendārs ir tikai minimums, bet īstais iemesls testēt ir izmaiņa.

Praksē tas nozīmē, ka jauns testa iemesls ir izmaiņa, kura maina uzbrukuma tvērumu: jauna publiska funkcija, jauna integrācija ar ārēju sistēmu, autentifikācijas maiņa, pāreja uz citu mitināšanu, jauna lietotāju loma ar plašākām tiesībām. Krāsu maiņa vai teksta labojums par tādu iemeslu nekļūst, lai cik redzams tas būtu.

Otrs iemesls ir tas, ka mainījusies apkārtne, nevis Jūsu kods: ievainojamība ietvarā, kuru Jūs izmantojat, atklājas pēc testa, un tests, kurš to nepieminēja, nav kļūdījies, jo tobrīd tās vēl nebija. Tāpēc regulāra skenēšana un atjauninājumu process ir tas, kas notiek starp testiem, un tests to neaizstāj.

Bez īpašnieka atļaujas tās pašas darbības ir prettiesiskas

Ielaušanās tests no uzbrukuma tehniski neatšķiras, un vienīgais, kas tos atšķir, ir dokuments: īpašnieka atļauja, kurā ir nosaukts apjoms, laiks un robežas, un kuru ir vērts noformēt rakstiski pat tad, kad likums to tieši neprasa. Bez tās tās pašas darbības ir tās pašas darbības, un tam ir juridiskas sekas.

Praktiski tas nozīmē, ka atļauju dod tas, kam sistēma pieder, ne tas, kas to uztur. Ja Jūsu vietne strādā uz mitināšanas pakalpojuma, arī pakalpojuma sniedzējam ir jāzina, ka tests notiks, jo pretējā gadījumā viņa aizsardzības sistēmas to apturēs vai Jūsu kontu bloķēs. Ja sistēmā ir trešās puses komponente, kuru Jūs nekontrolējat, tā apjomā neietilpst.

Apjoma robežas ir jāuzraksta pirms, ne pēc, un tajā sarakstā ietilpst tas, kuras adreses ir apjomā un kuras nav, vai testējam produkcijas vidi vai kopiju, kas notiek, ja tests pārtrauc pakalpojumu, un kurš no Jūsu puses ir sasniedzams naktī; šī saruna aizņem vienu stundu un atrisina lielāko daļu strīdu, kuri citādi rodas testa vidū.

Ko tests nav: sarkanā komanda, bug bounty un atbilstības pārbaude

Blakus ielaušanās testam pastāv vairāki darbi, kurus mēdz saukt par to pašu, un atšķirības starp tiem nav akadēmiskas, bet praktiskas — tās izšķir, ko Jūs pasūtāt un ko saņemat.

Sarkanās komandas uzdevums pārbauda nevis sistēmu, bet aizsardzību: vai Jūsu cilvēki un procesi uzbrukumu pamana un ko dara. Apjoms ir plašāks, ilgums garāks, un daļa vērtības ir tieši tajā, ka aizsargu puse nezina, ka notiek mācības. Uzņēmumam, kuram nav ko pamanīt, jo neviens žurnālus nelasa, šis darbs ir priekšlaicīgs.

Bug bounty ir modelis, ne tests: Jūs publiskojat noteikumus un maksājat par atradumiem tiem, kas tos atsūta. Tas var atrast to, ko viens testētājs nepamanīja, bet tas nedod ne apjoma garantiju, ne termiņu, ne atskaiti, kuru var pievienot iepirkuma dokumentiem.

Draudu vadīta ielaušanās testēšana (DVIT) ir atsevišķs, regulēts darbs finanšu sektorā, un tā ir definēta Eiropas Savienības regulā. Ja Jūsu uzņēmums nav uzrauga norādīta finanšu iestāde, šis termins Jūsu piedāvājumā nav vietā.

Vēl viena robeža, kuru mēdz nojaukt, ir starp „melno“, „balto“ un „pelēko kasti“ — cik daudz testētājs par sistēmu zina jau sākumā. Tā ir nozares vienošanās, ne normatīva prasība, un tai ir tieša ietekme uz cenu un uz to, ko tests atradīs. Testētājs bez piekļuves atdarina svešinieku; testētājs ar kontu un dokumentāciju vienā laikā aizsniedz vairāk. Neviens no variantiem nav pareizākais; jautājums ir, no kā Jūs baidāties.

Ko Jūs saņemat un kā to lasīt

Testa rezultāts ir atskaite, un tās vērtība ir prioritātēs, ne atradumu skaitā, jo atskaite ar simts rindām, kurās nav pateikts, ar kuru sākt, ir tieši tikpat neizmantojama kā skenera izdruka. Laba atskaite katram atradumam pasaka, ko uzbrucējs ar to var izdarīt, cik viegli, un ko konkrēti mainīt.

Otrs, kas jāprasa, ir pārbaude pēc labojumiem, jo atradums, kurš ir izlabots, un atradums, par kuru kāds domā, ka tas ir izlabots, atšķiras viens no otra, un vienīgais veids, kā to noskaidrot, ir pārbaudīt vēlreiz. Mēs to darām trīsdesmit dienu laikā pēc labojumiem, un šo termiņu ir vērts prasīt no ikviena izpildītāja.

Trešais ir tas, ko ar atskaiti darīs Jūsu izstrādātājs. Atradums, kurš ir aprakstīts ar CVE numuru un bez konteksta, izstrādātājam nozīmē meklēšanu; atradums, kuram ir pievienots konkrētais pieprasījums un vieta kodā, nozīmē labojumu. Ja izstrādi veic viens uzņēmums un testu cits, šī atšķirība ir tā, kura izšķir, vai labojumi tiks izdarīti nedēļā vai ceturksnī.

Ceturtais ir tas, kas atskaitē nedrīkst būt: apgalvojums, ka sistēma tagad ir droša. Tests parāda, ko konkrētajā apjomā konkrētajā datumā izdevās izdarīt. Tas nepierāda, ka nav nekā cita, un izpildītājs, kurš to sola, pārdod Jums mierinājumu.

Ir vēl viens iemesls, kāpēc šo sarunu ir vērts sākt agrāk, nekā šķiet nepieciešams: tests, kurš notiek nedēļu pirms sistēmas nodošanas, atrod to pašu, ko būtu atradis trīs mēnešus iepriekš, bet atradumu izlabošanai vairs nav ne laika, ne budžeta, un praksē tas beidzas ar sarakstu, kuru pieņem kā risku, nevis ar labojumiem, tāpēc Ministru kabineta noteikumu prasība testēt pirms nodošanas ekspluatācijā ir uzrakstīta tieši tā, kā tā ir, un tā pati loģika der arī tiem, kuriem šī prasība nav saistoša.

Un pēdējais, ko ir vērts pateikt tieši: ielaušanās tests nav apliecinājums, ka sistēma ir droša, bet apliecinājums, ka konkrētā datumā konkrētā apjomā zināma prasme neatrada ceļu tālāk par kaut ko konkrētu, un tāpēc vērtīgākā atskaites daļa bieži ir nevis atradumu saraksts, bet apraksts par to, kas tika mēģināts un neizdevās, jo tieši šī daļa nākamajam testētājam pēc trim gadiem pasaka, kur nav vērts sākt no nulles.

Ko sagatavot pirms sarunas

Lai piedāvājums vispār būtu salīdzināms, izpildītājam ir jāzina apjoms, tāpēc sagatavojiet sarakstu ar adresēm un sistēmām, kuras tajā ietilpst, norādiet, vai testējam produkcijas vidi vai kopiju, pasakiet, kas sistēmā ir tāds, kam nedrīkst pieskarties, un nosauciet cilvēku, kurš var atļaut testu apturēt.

Produkcijas vide vai kopija

Šis ir jautājums, kurš izšķir gan cenu, gan risku, jo tests produkcijas vidē parāda to, kas patiešām ir pieejams, un tieši tāpēc tas var kaut ko salauzt: pārslogot, aizpildīt datubāzi ar testa ierakstiem, izsūtīt klientiem īstus e-pastus vai iestrēgt aizsardzības sistēmā, kura testētāju bloķē un pēc tam bloķē arī daļu Jūsu lietotāju.

Tests kopijā ir drošāks un vienlaikus nepilnīgāks, jo kopija reti ir identiska: tajā mēdz nebūt reālo integrāciju, reālo datu apjoma un reālās konfigurācijas, un tieši konfigurācijā bieži atrodas problēma. Ja izvēlaties kopiju, pierakstiet, ar ko tā atšķiras no produkcijas vides, jo šis saraksts ir arī saraksts ar to, ko tests nepārbaudīja.

Vidusceļš, kuru izmantojam visbiežāk: lasīšanas darbības produkcijas vidē, rakstīšanas un potenciāli postošās — kopijā, ar iepriekš saskaņotu logu un cilvēku, kurš var apturēt. Tas nav kompromiss cenas dēļ, bet veids, kā iegūt abu variantu atbildes, nepārtraucot darbu.

Der arī pretējais saraksts, proti, tas, kas nav apjomā, jo klusējot pieņemtas robežas ir tās, par kurām vēlāk strīdas. Trešo pušu pakalpojumi, kurus Jūs neuzturat, tajā neietilpst, un to testēšana bez šo pušu atļaujas ir tā pati problēma, par kuru ir iepriekšējā sadaļa. Ja Jūsu vietne izmanto ārēju maksājumu logu, ārēju sarunu logu vai ārēju analītiku, tie ir citu īpašumi, un piedāvājums, kurš solās tos „arī pārbaudīt“, sola to, ko nedrīkst.

Visbeidzot pasakiet, kas notiks ar atradumiem pēc tam: kurš tos labos, kādā termiņā, un vai izpildītājs pēc labojumiem pārbaudīs vēlreiz. Tests bez šīs vienošanās bieži beidzas ar dokumentu, kuru neviens neatver, un tā ir visdārgākā iespējamā versija: samaksāts par zināšanu, kuru neizmanto.

Pasakiet arī, uz ko Jūs meklējat atbildi, jo „mums jāizpilda prasība“ un „mēs gribam zināt, vai kāds var tikt pie klientu datiem“ ir divi dažādi darbi ar divām dažādām cenām, un izpildītājs, kurš nejautā, kurš no tiem ir Jūsu, piedāvās to, kurš viņam ir ērtāks.

Ja neesat pārliecināts, kurā pusē sliekšņa Jūs atrodaties, ar to ir vērts sākt. Automātiskais audits parasti atbild uz jautājumu par zināmajām vājajām vietām lētāk un ātrāk nekā manuāls eksperta darbs, un tā rezultāts pasaka arī to, vai ielaušanās tests ir nākamais solis. Sarunu par apjomu ir vērts sākt ar procesa aprakstu, ne ar tehnoloģiju sarakstu, jo apjomu nosaka tas, ko Jūs zaudējat, ja sistēma pieviļ.