Сакрэт нашых аўтарытэтных вынікаў тэсціравання

Калі я чытаю пратакол выпрабаванняў, я не давяраю яму, таму што ён выглядае фармальна. Я давяраю гэтаму, калі бачу, як апрацоўваўся ўзор, які метад выкарыстоўваўся, хто правяраў даныя і што насамрэч азначаюць вынікі. Вынік тэсту можа паўплываць на рашэнне прадукту, план вытворчасці або давер кліента. Лічбы без відавочных доказаў недастаткова. Давер расце, калі працэсу лёгка прытрымлівацца, а справаздача пакідае мала месца для здагадак. Наш працэс тэсціравання сканцэнтраваны на некалькіх дэталях, якія дапамагаюць людзям з упэўненасцю ацэньваць вынік. 1. Выразная ідэнтыфікацыя ўзору Кожны ўзор патрабуе выразнага запісу ад прыбыцця да справаздачнасці. Мы запісваем такую ​​інфармацыю, як назва ўзору, код, дата атрымання, запыт на тэст і ўмовы захоўвання. Гэты запіс дапамагае злучыць канчатковы вынік з правільным узорам. Гэта таксама зніжае рызыку блытаніны, калі некалькі ўзораў прыходзяць ад аднаго кліента. Напрыклад, вытворца можа адправіць узоры з трох вытворчых ліній. Калі цэтлікі няпоўныя, у справаздачы можа быць не паказана, які радок даў пэўны вынік. Зразумелы ўзор кода дае кожнаму элементу свой шлях, які можна прасачыць. 2. Прыдатныя метады выпрабаванняў Розныя матэрыялы патрабуюць розных метадаў. Проба вады, прадукт харчавання, металічная частка і касметычны інгрэдыент не могуць быць правераны аднолькава. Мы выбіраем метад, які адпавядае тыпу ўзору і мэтам тэставання кліента. У справаздачы таксама могуць быць паказаны спасылка на метад, дыяпазон тэсціравання, адзінка вымярэння і любыя этапы падрыхтоўкі, якія ўплываюць на вынік. Гэтая інфармацыя дапамагае мне зразумець, што азначае лічба. Гэта таксама дазваляе іншаму кваліфікаванаму спецыялісту перагледзець метад, а не прымаць вынік без кантэксту. 3. Кантраляваныя ўмовы тэсціравання Тэмпература, вільготнасць, налады абсталявання, якасць рэагентаў і захоўванне ўзораў могуць паўплываць на дадзеныя тэсту. Кантраляваны працэс дапамагае абмежаваць гэтыя эфекты. Наша каманда прытрымліваецца пісьмовых працэдур і вядзе запісы падчас тэсту. Тэхніка правяраецца згодна з планавым графікам. Калі вынік выглядае незвычайным, каманда разглядае стан узору, этапы тэставання і запісы прыбораў перад выдачай справаздачы. Справаздача не павінна хаваць нявызначанасці. Калі метад мае мяжу выяўлення або дыяпазон вымярэння, гэтая інфармацыя павінна быць даступна чытачу. 4. Праверце перад паведамленнем Вынік тэсту праходзіць этап праверкі, перш чым ён даходзіць да кліента. Рэцэнзент правярае дэталі выбаркі, разлікі, адзінкі, інфармацыю аб метадах і запісаныя назіранні. Гэты крок можа выявіць простыя праблемы, такія як няправільная адзінка вымярэння або адсутнасць знака пасля коскі. Невялікія памылкі могуць змяніць разуменне выніку, таму ўважлівы агляд мае практычнае значэнне. Я таксама чакаю, што справаздача будзе аддзяляць вымераныя дадзеныя ад інтэрпрэтацыі. Вынік павінен быць паказаны ў выглядзе даных. Любы каментарый аб адпаведнасці або прыдатнасці прадукту павінен быць звязаны з правільным стандартам, спецыфікацыяй або патрабаваннем кліента. 5. Справаздачы, якія людзі могуць прачытаць Карысная справаздача не прымушае чытача шукаць шчыльныя старонкі. Ён прадстаўляе ўзорную інфармацыю, тэставыя заданні, вынікі, адзінкі, спасылкі на метады і нататкі ў выразным макеце. Калі вынік выходзіць за межы запытанага дыяпазону, у справаздачы павінна быць растлумачана абмежаванне, а не расплывістае сцвярджэнне. Калі ўмовы ўзору могуць паўплываць на вынік, гэта таксама трэба пазначыць. Выразная справаздачнасць дапамагае камандам па якасці, пастаўшчыкам, інжынерам і пакупнікам прымаць рашэнні на аснове адной і той жа інфармацыі. 6. Запісы, якія падтрымліваюць адсочванне Давер не спыняецца пасля адпраўкі справаздачы. Запісы выпрабаванняў павінны заставацца звязанымі з узорам, метадам, абсталяваннем, аналітыкам і працэсам агляду. Калі пазней з'явіцца пытанне, прасочваемыя запісы палягчаюць праверку таго, што адбылося. Гэта можа падтрымаць унутраны агляд якасці, абмеркаванне пастаўшчыкоў або наступнае выпрабаванне. Моцная служба тэсціравання не пабудавана на ўражлівых фармулёўках. Ён пабудаваны на працэсе, які людзі могуць праверыць, зразумець і паўтарыць. Я шукаю вынікі тэстаў, якія паказваюць шлях за нумарам. Выразныя запісы ўзораў, прыдатныя метады, кантраляваныя ўмовы, уважлівы агляд і чытэльныя справаздачы даюць даныя трывалую аснову. Вось чаму нашы вынікі тэстаў распрацаваны, каб заслужыць давер доказамі, а не абяцаннямі.

Тэст можа даць дакладную справаздачу і пры гэтым прывесці да няправільнага рашэння. Я бачыў, як каманды давяраюць аднаму паспяховаму выніку, а на наступны дзень выяўляюць, што той жа працэс дае іншы вынік. Часта праблема заключаецца не ў недахопе намаганняў. Яно адбываецца з-за слабасці тэставання, незразумелых вымярэнняў, зменлівых умоў або даных, якія не былі старанна правераны. Надзейнае тэсціраванне пачынаецца з простага пытання: Ці можа іншы чалавек паўтарыць тэст пры падобных умовах і дасягнуць аналагічнага выніку? Гэта пытанне вызначае кожную частку працэсу. ### Пачніце з дакладнага тэставага пытання. Карысны тэст не спрабуе адказаць на ўсё адразу. Ён сканцэнтраваны на адным вымерным пытанні. Напрыклад, «Ці добрая гэтая плацежная старонка?» занадта шырокі. Больш зразумелым было б пытанне: «Ці могуць карыстальнікі завяршыць аплату карткай на працягу трох хвілін пры доступе да старонкі праз мабільнае злучэнне?» Гэтая версія дае камандзе мэта. Гэта таксама дапамагае вызначыць тэставую групу, прыладу, стан сеткі, ліміт часу і вынік, які лічыцца поспехам. Я аддаю перавагу пісаць тэставае пытанне перад выбарам інструментаў. Многія слабыя тэсты пачынаюцца з праграмнага забеспячэння, абсталявання або пераважнага метаду. Затым інструмент фармуе пытанне, нават калі ён не падыходзіць. ### Вызначце вынік перад зборам даных Для надзейнага тэсту патрэбна выразная ўмова праходжання. Выкажам здагадку, што каманда правярае працэс афармлення заказу на сайце. Ён можа адсочваць: - Час загрузкі старонкі - Каэфіцыент завяршэння плацяжу - Паведамленні пра памылкі - Няўдалыя транзакцыі - Дзеянні карыстальніка перад завяршэннем - Аднаўленне пасля няўдалага плацяжу Каманда павінна вырашыць, як будзе вымярацца кожны вынік. Калі адзін тэсціроўшчык пазначае павольную старонку як памылковую, а другі прымае яе, канчатковая справаздача будзе ўтрымліваць змешаныя стандарты. Пісьмовае тэставае правіла памяншае гэтую праблему. Напрыклад: «Спроба аплаты праходзіць, калі на працягу трох хвілін з'яўляецца старонка пацверджання і статус замовы змяняецца на аплачаны». Правіла можа быць скарэкціравана пасля пілотнага тэсту, але яно не павінна змяняцца ціха пасля збору асноўных даных. ### Кантралюйце ўмовы. Умовы тэставання ўплываюць на вынік. Тэмпературны датчык можа паказваць розныя паказанні, калі яго размясціць каля акна, трымаць у руцэ або выкарыстоўваць у пакоі са зменлівым патокам паветра. У хуткай офіснай сетцы вэб-сайт можа працаваць інакш, чым у мабільным злучэнні. Узор прадукту можа паводзіць сябе па-рознаму пасля захоўвання ў цяпле або вільгаці. Я запісваю ўмовы, якія могуць паўплываць на вынік: - Дата і час - Абсталяванне або версія праграмнага забеспячэння - Месца тэсціравання - Тэмпература і вільготнасць, калі гэта неабходна - Тып сеткі - Крыніца ўзору - Аператар - Працягласць тэсту - Змены, унесеныя падчас тэсціравання. Гэты запіс палягчае разуменне выніку. Гэта таксама дапамагае камандзе вызначыць прычыну, калі два выпрабаванні не супадаюць. ### Выкарыстанне элементаў кіравання і кропак параўнання Элемент кіравання дае тэсту кропку адліку. У лабараторных умовах кантрольны ўзор можа быць правераны разам з узорам, які разглядаецца. У тэставанні праграмнага забеспячэння папярэдняя стабільная версія можа выступаць у якасці кропкі параўнання. У вытворчасці вядомая партыя прадукту можа дапамагчы паказаць, ці працуе тэставая ўстаноўка належным чынам. Уявіце, што каманда тэстуе новы пошукавы фільтр. Новы фільтр вяртае вынікі за 1,2 секунды, а старая версія вяртае вынікі за 1,1 секунды. Без старой версіі ў якасці эталона каманда не можа меркаваць, ці прымальны новы вынік. Параўнанне не даказвае, што адзін варыянт лепш у кожнай сітуацыі. Гэта дае даным карысную структуру. ### Паўтарыце тэст Аднаго паспяховага выніку недастаткова для многіх рашэнняў. Паўторныя тэсты дапамагаюць паказаць, ці з'яўляецца вынік стабільным або выкліканы выпадковасцю. Колькасць паўтораў залежыць ад рызыкі, кошту, варыяцый і мэты тэсту. Для хуткай унутранай праверкі можа спатрэбіцца толькі невялікая пілотная група. Рашэнне, звязанае з бяспекай або вытворчасцю, можа запатрабаваць больш шырокага і больш кантраляванага даследавання. Разгледзім тэст на ўваход. Адзін паспяховы ўваход сведчыць толькі аб тым, што адна спроба спрацавала. Паўтарэнне тэсту для некалькіх уліковых запісаў, браўзераў, прылад і сеткавых умоў можа выявіць праблемы, якія застаюцца схаванымі ў адным запуску. Я таксама пазбягаю паўтарэння сапраўды таго ж дзеяння ў дакладна такім жа парадку кожны раз. Паслядоўныя ўмовы маюць значэнне, але фіксаваныя шаблоны могуць схаваць праблемы. Невялікія запланаваныя змены могуць паказаць, як сістэма рэагуе на розныя ўводы. ### Аддзяленне паўтаральнасці ад узнаўляльнасці Гэтыя дзве ідэі звязаны, але не ідэнтычныя. Паўтараемасць пытаецца, ці можа той жа чалавек, абсталяванне і метад зноў даць падобныя вынікі. Узнаўляльнасць запытвае, ці могуць розныя людзі, абсталяванне або месцы выкарыстоўваць адзін і той жа метад і дасягнуць падобных вынікаў. Лабарант можа вымераць узор тры разы і атрымаць амаль аднолькавыя паказанні. Гэта паказвае паўтаральнасць. Калі іншая лабараторыя выкарыстоўвае той жа метад і атрымлівае блізкі вынік, тэст таксама паказвае ўзнаўляльнасць. Каманды праграмнага забеспячэння сутыкаюцца з тым жа адрозненнем. Тэст можа быць пройдзены на кампутары аднаго распрацоўшчыка, але не ў тэставым асяроддзі. Код не быў пратэставаны ў дастатковай колькасці ўмоў. Надзейны працэс запісвае метад, каб вынік не залежаў ад памяці або асабістых звычак аднаго чалавека. ### Праверце сістэму вымярэння Тэст карысны настолькі, наколькі спосаб вымярэння яго выніку. Шкала, якая не была праверана, можа паведаміць лік з ілжывай упэўненасцю. Інструмент маніторынгу можа лічыць запыт паспяховым, нават калі карыстальнік бачыць памылку. Апытанне можа задаць расплывістае пытанне, якое розныя людзі інтэрпрэтуюць па-рознаму. Я правяраю тры вобласці: - Дакладнасць: Ці адлюстроўвае вымярэнне значэнне, якое яно, як сцвярджаецца, вымярае? - Узгодненасць: ці дае інструмент падобныя паказанні ў аднолькавых умовах? - Адчувальнасць: Ці можа інструмент вызначыць розніцу, якая мае значэнне для прыняцця рашэння? Запісы каліброўкі, тэставыя сцэнарыі, праверачныя ўзоры і ручныя агляды могуць падтрымліваць гэтую праверку. Правільны метад залежыць ад тыпу тэставання. ### Улік нявызначанасці Кожнае вымярэнне мае пэўную нявызначанасць. Гэта не робіць тэст бескарысным. Гэта дапамагае чытачу зразумець, наколькі давяраць выніку. Прылада можа паведамляць пра тэмпературу 22,0°C, у той час як яе дыяпазон вымярэнняў дазваляе невялікія змены. Тэст прадукцыйнасці можа паказаць сярэдні час адказу 400 мілісекунд, у той час як асобныя запыты вар'іруюцца ад 250 да 900 мілісекунд. Паведамленне толькі сярэдняга можа схаваць спрэд. Я гляджу на: - Сярэдняе значэнне - Мінімум і максімум - Медыяна - Дыяпазон або варыяцыя - Колькасць назіранняў - Выкіды - Адсутныя вынікі Тэст аплаты з 98% поспехам гучыць пазітыўна, але сэнс мяняецца, калі ўсе няўдалыя плацяжы адбыліся ў адным мабільным браўзеры. Сярэдні паказчык не расказвае ўсёй гісторыі. ### Сачыце за прадузятасцю Bias можа ўвайсці ў тэст перад пачаткам збору даных. Каманда можа выбраць толькі простыя выпадкі, таму што яны чакаюць, што прадукт будзе працаваць добра. Апытанне можа ахапіць існуючых кліентаў, але прапусціць людзей, якія перасталі карыстацца паслугай. Тэстар можа праігнараваць памылку, таму што яна не адпавядае чаканаму выніку. Я зніжаю гэтую рызыку шляхам: - Вызначэння правілаў адбору перад тэсціраваннем - Уключэння нармальных і цяжкіх выпадкаў - Захоўвання няўдалых вынікаў у дадзеных - Аддзялення назірання ад інтэрпрэтацыі - Папрасілі іншага чалавека азнаёміцца ​​з планам тэсціравання - Запісвання змяненняў замест выдалення нязручных вынікаў Сляпое тэставанне можа дапамагчы, калі асабістыя чаканні могуць паўплываць на меркаванне. Чалавеку, які запісвае вынік, не заўсёды трэба ведаць, які ўзор з'яўляецца новай версіяй. ### Выкарыстоўвайце пілотны тэст Пілотны тэст - гэта невялікая спроба поўнага метаду. Гэта можа выявіць незразумелыя інструкцыі, адсутныя палі даных, зламанае абсталяванне або ўмовы выпрабаванняў, якія занадта складана кантраляваць. Пілот таксама паказвае, ці займае запланаваны тэст дзесяць хвілін або дзве гадзіны. Напрыклад, каманда, якая плануе тэсціраванне карыстальнікаў, можа запрасіць трох удзельнікаў перад пачаткам асноўнага даследавання. Падчас пілота каманда можа выявіць, што карыстальнікі не разумеюць тэрміна «праверка ўліковага запісу». Гэтую праблему можна выправіць, перш чым больш людзей прымуць удзел. Пілот - гэта не замена асноўнага выпрабавання. Гэта спосаб праверыць, ці гатовы асноўны тэст. ### Захоўвайце зыходныя даныя і тлумачце рашэнні Справаздача не павінна паказваць толькі вынік, які падтрымлівае пераважнае рашэнне. Я захоўваю арыгінальныя паказанні, пазнакі часу, журналы памылак, нататкі аб тэстах і адхіленыя назіранні. Калі вынік выдалены, у справаздачы павінна быць растлумачана, чаму. Пашкоджаны ўзор, дубліраваны запіс або перапынены тэст могуць апраўдаць выдаленне. Вынік, які проста выглядае незвычайна, не выглядае. Выразныя запісы дазваляюць іншаму чалавеку праглядаць працу, не здагадваючыся, што адбылося. Яны таксама палягчаюць наступнае тэставанне, таму што каманда можа параўнаць метады і вынікі. ### Злучыце вынік з рашэннем Тэставанне не завершана, калі дыяграма створана. Вынік павінен адказаць на практычнае пытанне. Каманда прадукту можа спытаць, ці гатовая функцыя да абмежаванага выпуску. Група па якасці можа спытаць, ці патрэбна партыя дадатковай праверкі. Каманда вэб-сайта можа спытаць, ці варта захаваць змяненне прадукцыйнасці. Рашэнне павінна адпавядаць сіле доказаў. Невялікі тэст можа падтрымаць невялікі наступны крок. Ён можа не падтрымліваць шырокае сцвярджэнне аб кожным карыстальніку, прыладзе або стане. Я аддаю перавагу дакладным фармулёўкам, такім як: «Паток афармлення замовы адпавядаў правілу тэставання ў 47 з 50 спроб на выбраных прыладах». Гэтая заява распавядае чытачу, што было праверана і што назіралася. Гэта не сцвярджае, што кожны кліент атрымае аднолькавы вопыт. Надзейнае тэсціраванне будуецца праз дакладныя пытанні, кантраляваныя ўмовы, адпаведныя вымярэнні, паўторныя праверкі і сумленныя справаздачы. Працэс не павінен быць складаным, але кожная частка павінна мець дакладнае прызначэнне. Калі я праглядаю тэст, я пытаюся: - Якое пытанне правяралася? — Што лічылася поспехам? — Умовы запісваліся? — Ці быў пункт параўнання? — Ці можа іншы чалавек паўтарыць метад? - Не атрымалася ці захаваліся незвычайныя вынікі? — Ці пацвярджаюць доказы прынятае рашэнне? Гэтыя пытанні ператвараюць тэставанне з аднаразовай дзейнасці ў надзейны спосаб навучання.

Надзейныя вынікі пачынаюцца з дакладнага пытання. Калі я атрымліваю запыт, я не спяшаюся даваць нумар або справаздачу. Спачатку я правяраю, што трэба даведацца кліенту, якія дадзеныя могуць падтрымаць адказ і дзе ў працэсе могуць узнікнуць памылкі. Вынік можа выглядаць дакладным, але грунтавацца на няпоўнай інфармацыі. Мая праца сканцэнтравана на скарачэнні гэтага разрыву. Я выкарыстоўваю практычны працэс, які робіць бачным кожны этап. Я пачынаю з пацверджання мэты і чаканага выніку. Каманда продажаў можа захацець ведаць, які канал прыносіць кваліфікаваных патэнцыйных кліентаў. Менеджару крамы можа спатрэбіцца параўнаць запісы запасаў з фізічнымі падлікамі. Каманда маркетынгу, магчыма, захоча зразумець, чаму трафік павялічыўся, а колькасць запытаў засталася на ранейшым узроўні. Кожнае пытанне патрабуе розных даных і рознага спосабу іх праверкі. Затым я вызначаю крыніцу інфармацыі. Я запісваю, адкуль паходзяць дадзеныя, калі яны былі сабраны і ці выкарыстоўваліся аднолькавыя правілы ва ўсіх запісах. Гэта дапамагае прадухіліць агульную праблему: параўнанне фігур, створаных у розных умовах. Напрыклад, справаздача вэб-сайта можа паказваць 10 000 наведванняў у адной сістэме і 8 700 у іншай. Гэта не заўсёды азначае, што адна справаздача памылковая. Сістэмы могуць выкарыстоўваць розныя фільтры, гадзінныя паясы, налады файлаў cookie або азначэнні наведвання. Я параўноўваю гэтыя параметры, перш чым зрабіць выснову. Праверкі даных перад інтэрпрэтацыяй. Я шукаю адсутныя запісы, паўторныя запісы, незвычайныя змены і значэнні, якія не адпавядаюць заяўленым правілам. Я таксама разглядаю ўзор уручную, калі гэта дазваляе праект. Невялікая ручная праверка можа выявіць памылку наймення, непрацуючую спасылку для адсочвання або формулу, якая была скапіравана ў няправільны слупок. Каманда рознічнага гандлю аднойчы выявіла вялікую розніцу паміж табліцай запасаў і таварамі на паліцах. Першая здагадка заключалася ў тым, што прадукты былі страчаны. Пасля праверкі запісаў прычына была прасцейшай: вернутыя тавары дадаваліся ў электронную табліцу, але не вярталіся ў лік даступных запасаў. Вынік стаў больш карысным пасля карэкцыі правіла падліку. Я трымаю разлікі асобна ад меркаванняў. Дадзеныя паказваюць, што адбылося. Маё тлумачэнне паказвае, што магло гэта выклікаць. Калі доказы абмежаваныя, я выразна заяўляю гэта замест таго, каб прадстаўляць здагадку як факт. Кожны вынік праходзіць этап праверкі. Я звяраю лічбы з крыніцай, правяраю ключавыя формулы, праглядаю фармулёўкі і пытаюся, ці можа іншы чалавек выканаць тыя ж дзеянні. Выразныя нататкі дапамагаюць кліенту зразумець, як быў атрыманы вынік і што трэба праверыць пазней. Я таксама тлумачу абмежаванні простай мовай. Справаздача, заснаваная на дадзеных за адзін тыдзень, не можа з упэўненасцю апісаць увесь сезон. Апытанне з невялікай групай можа паказаць карысную зваротную сувязь, але можа не прадстаўляць кожнага кліента. Дакладнасць уключае ў сябе веданне таго, што могуць пацвердзіць наяўныя доказы. Выніковая справаздача створана для выкарыстання, а не толькі для паказу. Я прадстаўляю асноўную выснову, пацвярджаючыя лічбы, выкарыстаны метад і наступныя дзеянні, якія кліент можа разумна распачаць. Табліцы і дыяграмы застаюцца простымі, каб чытач мог засяродзіцца на паведамленні. Я лічу, што дакладная праца не ствараецца шляхам дадання новых лічбаў. Гэта вынікае з правільнага пытання, выкарыстання прыдатных крыніц, праверкі працэсу і асцярожнага паведамлення аб абмежаваннях. Калі кожны крок можна праглядзець, выніку становіцца лягчэй давяраць і лягчэй прымяняць.

Калі прадукт праходзіць тэсціраванне, галоўнае не ў тым, ці працуе ён адзін раз. Мне трэба ведаць, як ён паводзіць сябе пры звычайным выкарыстанні, незвычайных дзеяннях, розных прыладах і зменлівых умовах. Прапушчаны дэфект можа прывесці да скаргаў карыстальнікаў, паўторных запытаў у падтрымку або затрымак пасля выпуску. Наша тэсціраванне будуецца вакол гэтай практычнай патрэбы. Мы не разлічваем на адзін тэставы шлях або хуткі праход праз асноўныя функцыі. Мы вывучаем, як людзі могуць выкарыстоўваць прадукт, дзе яны могуць рабіць памылкі і якія ўмовы могуць выявіць слабыя месцы. Я пачынаю з вывучэння таго, як чакаецца, што прадукт будзе працаваць. Гэта ўключае ў сябе: - Асноўны шлях карыстальніка - Мэтавыя прылады і аперацыйныя сістэмы - Ключавыя бізнес-функцыі - Вядомыя абмежаванні прадукту - Вобласці, якія змяніліся падчас распрацоўкі - Праблемы, выяўленыя ў папярэдніх раўндах тэсціравання. Гэты крок дапамагае мне засяродзіць тэставанне на найбольш важных частках. Старонка аплаты, уваход у ўліковы запіс, інструмент пошуку або функцыя экспарту даных могуць запатрабаваць больш увагі, чым старонка, якая адлюстроўвае толькі статычную інфармацыю. Нашы тэставыя прыклады ахопліваюць як чаканыя, так і нечаканыя дзеянні. Я правяраю, ці можа карыстальнік выканаць заданне, як планавалася, потым гляджу, што адбываецца, калі карыстальнік уводзіць няпоўныя даныя, пакідае поле пустым, губляе доступ да сеткі, абнаўляе старонку або вяртаецца пасля доўгага перапынку. Тыповы тэст можа ўключаць у сябе: 1. Адкрыйце прадукт на абранай прыладзе 2. Выканайце звычайны шлях карыстальніка 3. Паўтарыце задачу з іншымі дадзенымі 4. Паспрабуйце несапраўдны або няпоўны ўвод 5. Праверце паведамленні, паводзіны старонкі і захаваныя даныя 6. Запішыце вынік з дакладнымі крокамі і доказамі 7. Паўторна праверце праблему пасля ўнясення змяненняў Гэты працэс дае групе распрацоўшчыкаў інфармацыю, якую яны могуць выкарыстоўваць. Справаздача павінна быць не толькі тое, што нешта не атрымалася. Ён павінен паказаць, дзе з'явілася праблема, як яе прайграць, які вынік чакаўся і які вынік адбыўся. Напрыклад, уявіце сабе платформу браніравання, дзе кліент выбірае дату, дадае плацежныя дадзеныя і пацвярджае браніраванне. Асноўны шлях можа працаваць добра. Больш глыбокая праверка можа выявіць, што кнопка браніравання застаецца актыўнай пасля таго, як выбраная дата становіцца недаступнай. Кліент можа атрымаць экран пацверджання, пакуль браніраванне не запісана належным чынам. Карысная справаздача будзе ўключаць выбраную дату, зробленыя крокі, выкарыстаную прыладу, паказанае паведамленне і запіс экрана, калі праблему цяжка паўтарыць. Гэта дае камандзе прадукту дакладны шлях для праверкі праблемы. Я таксама звяртаю ўвагу на праблемы, якія могуць не спыніць задачу, але ўсё роўна паўплываць на давер. Яны могуць уключаць незразумелыя цэтлікі, незразумелыя паведамленні пра памылкі, павольныя адказы старонак, тэкст, які абразаецца на маленькім экране, або форму, якая выдаляе ўведзеную інфармацыю пасля памылкі. Тэставанне на розных прыладах можа выявіць праблемы, якія лёгка прапусціць на адным экране. Макет можа выглядаць правільна на працоўным стале, але становіцца складаным для выкарыстання на тэлефоне. Сэнсарнае кіраванне можа добра рэагаваць на адну аперацыйную сістэму і па-рознаму на іншую. Я запісваю гэтыя адрозненні замест таго, каб меркаваць, што адзін паспяховы тэст прадстаўляе кожнага карыстальніка. Камунікацыя з'яўляецца часткай тэсціравання. Я групую праблемы па наступствах і даю абнаўленні, за якімі лёгка сачыць. Калі дэфект блакуе ключавую задачу, я тлумачу гэта непасрэдна. Калі невялікая праблема дысплея можа пачакаць, я апісваю яе, не перабольшваючы рызыкі. Я арганізую запіс тэсціравання, каб каманда магла бачыць: - Што было праверана - Што яшчэ патрабуе ўвагі - Якія праблемы з'яўляюцца новымі - Якія выпраўленні былі правераны зноў - Якія ўмовы не былі ахоплены. Гэты запіс дапамагае паменшыць колькасць паўторных пытанняў і прадухіляе праверку адной і той жа праблемы без дакладнага выніку. Наш падыход таксама пакідае месца для канкрэтных патрэб прадукту. Інтэрнэт-краме можа спатрэбіцца дбайная праверка калясак, скідак, паведамленняў аб наяўнасці і запісаў заказаў. Мабільнай праграме могуць спатрэбіцца тэсты для ўстаноўкі, дазволаў, перапынкаў і розных памераў экрана. Для бізнес-панэлі можа спатрэбіцца праверка роляў карыстальнікаў, фільтраў, справаздач і экспартаваных файлаў. Я не стаўлюся да кожнага прадукту так, быццам ён адпавядае аднаму кантрольнаму спісу. Фіксаваны спіс можа прапусціць праблемы, якія зыходзяць ад уласных карыстальнікаў і працоўных працэсаў прадукту. Я выкарыстоўваю агульную структуру тэсціравання, а затым карэктую дэталі вакол прадукту. Моцны працэс тэсціравання не азначае, што ўсе магчымыя дзеянні былі правераны. Гэта было б непрактычна для большасці прадуктаў. Гэта азначае, што важныя шляхі зразумелыя, зоны высокай рызыкі атрымліваюць адпаведную ўвагу, і кожная праблема, пра якую паведамляецца, змяшчае дастаткова дэталяў, каб каманда прыняла меры. Калі я правяраю, я гляджу не толькі на тое, што проста прайшоў або не прайшоў. Я пытаюся, ці падтрымлівае прадукт задачы карыстальніка, ці дае карысную зваротную сувязь, ці абараняе ўведзеную інфармацыю і ці паводзіць сябе паслядоўна ва ўзгодненых умовах. Вось чым вылучаецца наша тэсціраванне: дбайнае асвятленне, дакладныя доказы, мысленне, арыентаванае на прадукт, і камунікацыя, якая дапамагае камандам прымаць абгрунтаваныя рашэнні аб выпуску.

Калі прадукт працуе не так, як чакалася, праблему часта цяжка выявіць. Слабы вынік можа быць звязаны з дызайнам, матэрыяламі, устаноўкай або спосабам выкарыстання прадукта. Здагадкі могуць страціць час і стварыць блытаніну. Я выкарыстоўваю дакладны працэс тэсціравання, каб падзяліць гэтыя фактары. Кожны тэст мае пэўную мэту, запісаныя ўстаноўкі і вынік, які можа быць правераны іншым чалавекам. Я пачынаю з разумення пытання, якое стаіць за тэстам. Карыснае тэставае пытанне: - Ці абараняе ўпакоўка тавар падчас транспарціроўкі? - Ці можа праграмнае забеспячэнне абслугоўваць 500 актыўных карыстальнікаў? — Ці захоўвае матэрыял форму пасля шматразовага выкарыстання? - Ці можа новы карыстальнік выканаць задачу без дапамогі? Шырокае пытанне, напрыклад "Ці добра гэта працуе?" не дае дастатковага кірунку. Я ператвараю гэта ў вымерную мішэнь перад пачаткам любога тэсту. Наступны крок - заданне ўмоў тэсту. Я запісваю ўзор, інструменты, асяроддзе, працягласць і чаканы вынік. Калі тэмпература, нагрузка, памер экрана або вопыт карыстальніка могуць паўплываць на вынік, я ўключаю гэтыя дэталі ў план тэставання. Гэты запіс дапамагае мне справядліва параўноўваць вынікі. Гэта таксама зніжае верагоднасць таго, што невялікае змяненне налад будзе прынята за паляпшэнне прадукту. Затым я ўсталёўваю базавую лінію. Базавая лінія паказвае, як працуе прадукт да ўнясення змяненняў. Для вэб-сайта гэта можа ўключаць час загрузкі старонкі, хуткасць запаўнення формы або частату памылак. Для фізічнага прадукту гэта можа ўключаць вагу, трываласць, памер або прадукцыйнасць пасля шматразовага выкарыстання. Без базавай лініі больш позні вынік мае мала кантэксту. Тэст можа паказаць лічбу, але лічба не кажа мне, палепшыўся прадукт ці знізіўся. Пасля гэтага я правяраю адзін асноўны фактар ​​за раз. Калі я змяняю матэрыял, умовы тэсту застаюцца ранейшымі. Калі я змяню налады праграмнага забеспячэння, прылада і тэставыя дадзеныя застаюцца нязменнымі. Такі падыход дазваляе прасцей звязаць вынік са змяненнем, якое правяраецца. Просты прыклад - старонка афармлення замовы. Я магу параўнаць два макеты старонак з аднолькавым спісам прадуктаў, цаной, крыніцай трафіку і наборам прылад. Планіроўка - галоўнае адрозненне. Затым я магу праглядаць частату завяршэння, справаздачы аб памылках і водгукі кліентаў, не разглядаючы кожную змену як адзін сумарны вынік. Я паўтараю тэсты, калі вынік можа паўплываць выпадкова. Адзін тэст можа выявіць сігнал, але ён не можа растлумачыць поўную схему. Паўторныя тэсты дапамагаюць паказаць, ці стабільна з'яўляецца вынік. Я запісваю кожны заезд замест таго, каб захоўваць толькі найбольш спрыяльны вынік. Нечаканыя вынікі не выдаляюцца толькі таму, што яны не адпавядаюць чаканаму кірунку. Яны могуць паказваць на праблему наладкі, схаваную патрэбу карыстальніка або слабасць, якая патрабуе ўвагі. Я таксама ўключаю ўмовы практычнага выкарыстання. Прадукт можа добра працаваць у кантраляваных умовах і паводзіць сябе па-іншаму пры звычайным выкарыстанні. Мабільная старонка можа правільна загружацца на адной прыладзе, але стварае праблемы на старым тэлефоне. Пасылка можа прайсці асноўны тэст на падзенне, але пасля некалькіх даставак паказаць пашкоджанні. Па гэтай прычыне я выкарыстоўваю некалькі тэставых асяроддзяў, калі гэтага патрабуе прадукт. Я магу разглядаць розныя прылады, узровень навыкаў карыстальнікаў, умовы захоўвання або схемы выкарыстання. Дакладны тэст залежыць ад прадукту і зададзенага пытання. Падчас працэсу я захоўваю запісы, якія лёгка праглядаць. Кожная справаздача ўключае ў сябе: - Мэту тэсту - Выпрабаваны ўзор або версію - Умовы тэсту - Выкананыя крокі - Вымераны вынік - Любую незвычайную падзею - Межы выніку - Наступнае дзеянне. Гэты фармат дапамагае камандам прымаць рашэнні на аснове доказаў, а не памяці або асабістых пераваг. Я аддзяляю вымераныя вынікі ад асабістых меркаванняў. Тэстар можа паведаміць, што кнопку цяжка знайсці, а аналітыка паказвае, дзе карыстальнікі пакідаюць старонку. Абедзве дэталі могуць быць карыснымі, але яны адказваюць на розныя пытанні і не павінны разглядацца як аднолькавы тып доказаў. У канцы кожнага цыкла тэсціравання я вырашаю, карэктаваць, паўтарыць ці рухацца наперад. Вынік можа падтрымаць бягучы дызайн. Гэта можа сведчыць аб неабходнасці невялікай змены. Гэта таксама можа выявіць, што першапачатковае тэставае пытанне было занадта шырокім. Я не разглядаю кожны вынік як задаволены або недастатковы, не правяраючы прычыну гэтага. Маё меркаванне простае: добры працэс тэсціравання робіць больш, чым пошук памылак. Гэта дапамагае камандзе зразумець, што здарылася, чаму гэта адбылося і што можна праверыць далей. Выразныя запісы, паўтаральныя ўмовы і сумленныя ліміты робяць вынікі больш карыснымі. Калі я дзялюся вынікамі, я тлумачу як высновы, так і часткі, якія застаюцца нявызначанымі. Гэта дае камандзе практычную аснову для наступнага рашэння і дапамагае прадухіліць упэўненыя сцвярджэнні, якія тэст не можа пацвердзіць.

Калі я выбіраю паслугу, я хачу больш, чым адшліфаваныя абяцанні. Я хачу ведаць, што было вымерана, як былі атрыманы вынікі і ці адпавядаюць дадзеныя патрэбам майго бізнесу. Таму перад прыняццем рашэння я арыентуюся на факты. Надзейны працэс павінен паказваць: - адпраўную кропку - выкананую працу - лічбы, якія адсочваюцца - межы даных - змены, унесеныя пасля прагляду вынікаў Дакладная справаздача можа сказаць мне, ці прыцягнула кампанія больш кваліфікаваных наведвальнікаў, ці рабілі гэтыя наведвальнікі дзеянні і якія часткі працы патрабуюць карэкціроўкі. Гэта таксама дапамагае аддзяліць стабільны прагрэс ад кароткатэрміновых змен, выкліканых сезоннасцю, зрухамі на рынку або часовым павышэннем. Напрыклад, інтэрнэт-крама можа атрымаць больш трафіку на вэб-сайце пасля публікацыі новага кантэнту. Толькі трафік не паказвае, ці дапамагла праца бізнэсу. Я хацеў бы таксама праверыць прагляды прадуктаў, формы запытаў, зробленыя пакупкі і кошт кожнага кліента. Калі колькасць наведванняў расце, але запыты застаюцца на ранейшым узроўні, наступны крок можа ўключаць у сябе паляпшэнне змесціва старонкі, падрабязную інфармацыю аб прапанове або працэс кантактаў. Такі падыход забяспечвае сувязь рашэнняў з карыснымі доказамі. Я таксама шукаю дакладную справаздачу, а не шырокія заявы. Добрая справаздача можа ўключаць: - Справаздачны перыяд - Крыніцу даных - Метад, які выкарыстоўваецца для збору даных - Змяненне прадукцыйнасці - Дзеянні, запланаваныя на наступны этап Лічбы патрабуюць кантэксту. Павелічэнне на 20% можа здацца пазітыўным, але вынік мала што значыць без ведання першапачатковай лічбы, перыяду часу і якасці новых патэнцыйных кліентаў. Меншае павелічэнне колькасці запытаў можа быць больш карысным, чым большае павелічэнне агульных наведванняў. Маё меркаванне простае: вартыя даверу вынікі павінны быць простымі для праверкі і тлумачэння. Адна толькі лічба не дае ніякіх вынікаў для бізнесу. Рынкавыя ўмовы, паводзіны кліентаў, якасць вэб-сайта, бюджэт і час могуць паўплываць на прадукцыйнасць. Адказны пастаўшчык паслуг павінен растлумачыць гэтыя фактары замест таго, каб прадстаўляць кожную змену як доказ поспеху. Калі я разглядаю прэтэнзію, я пытаюся: 1. Што было вымерана? 2. Што было адпраўной кропкай? 3. Адкуль узяліся дадзеныя? 4. Што змянілася за перыяд? 5. Ці можна звязаць вынік з пэўным дзеяннем? 6. Што будзе праверана далей? Гэтыя пытанні дапамагаюць мне знайсці карысную інфармацыю, не спадзяючыся на ціск ці празмерныя заявы. Факты не пазбаўляюць ад любой рызыкі, але яны палягчаюць прыняцце рашэнняў. Яны паказваюць, што працуе, што патрабуе ўвагі і дзе неабходна дадатковае тэсціраванне. Выразны працэс таксама дае абодвум бакам агульны погляд на прагрэс. Давер расце, калі працу можна праверыць, дадзеныя растлумачыць, а вынікі асцярожна падаць. Гэта стандарт, які я выкарыстоўваю пры праглядзе эфектыўнасці: доказы перад абяцаннямі, выразныя меры перад шырокімі патрабаваннямі і практычныя дзеянні, заснаваныя на тым, што паказваюць лічбы. Па любых пытаннях адносна зместу гэтага артыкула звяртайцеся да Чэнь Цзяньцю: mr.chen@mxhomepanels.com/WhatsApp 18606500377.

Спіс літаратуры Міжнародная арганізацыя па стандартызацыі — 2017 — ISO IEC 17025 Агульныя патрабаванні да кампетэнтнасці выпрабавальных і калібровачных лабараторый Нацыянальны інстытут стандартаў і тэхналогій — 2019 — Ацэнка эфектыўнасці і нявызначанасці сістэмы вымярэнняў Амерыканскае таварыства якасці — 2020 — Даведнік сертыфікаванага інжынера па якасці Міжнародная кваліфікацыйная рада па тэсціраванні праграмнага забеспячэння — 2023 — Сертыфікавана Праграма тэсціравання базавага ўзроўню Роберт М. Гроўвс — 2009 — Метадалогія апытання Дуглас Мантгомеры — 2019 — Распрацоўка і аналіз эксперыментаў