6 QA грешки и как да ги избегнем

Елклинг предава своята мъдрост

Седем години опит в отрасъла за осигуряване на качеството в разработването на софтуер ми дава заблудата увереност да седна на моя люлеещ се стол, да събера младите наоколо и да започна разказ за това как се върна в добрите стари времена, грешките, които направих и досадно заяждам за юношите, за да се уча от грешките ми. Докато гледам всички съзнателно в пукащия огън (да, сега има огън, продължавайте с фантазията), аз недоволно приемам строг поглед и започвам да проповядвам. Ето шест QA грешки и как да ги избегнем!

1. Забравете по-голямата картина

Когато човек започне като младши тестер и изпитва вълнение от добре отпочинало кученце от златен ретривър, понякога е неизбежно да забрави по-голямата картина. Това е, когато един младши попълни дъската ми с Джира с подобрения, неправилно подредени пиксели, икони, които са леко извън центъра и липсват запетайки две седмици, преди да се наложи да изпратя окончателен кандидат за освобождаване. Това е и най-бързият начин да ме видите хипервентилиращ. Това, което ми трябва на този етап, е успокоението, че основните функции работят, нищо не е счупено, сривовете са отдалечена памет, а приложението е удобно за потребителя и лесно достъпно - не проверка на граматика и съвършенство на потребителския интерфейс.

Най-хубавото на новите тестери е безкрайната им готовност да намерят колкото се може повече бъгове и да се окажат ценни. Но най-лошото за новите тестери е тяхната безкрайна готовност да намерят колкото се може повече бъгове ... знаете как свършва това. Понякога са склонни да се съсредоточават върху дребни малки детайли в най-лошите възможни моменти. Приоритизирането е нещо, което се научава и с времето човек започва да разбира, че има подходящо време за подаване на тривиали и приближаващ се страшен краен срок вероятно не е този момент.

2. Добавете проблеми въз основа на вашите чувства

Мисля, че тази икона ще изглежда по-добре, ако беше оранжева вместо синя. Чувствам, че тази логика е малко трудна за разбиране, така че чувствам, че трябва да добавим поне още четири изскачащи прозорци. Не! Младшите тестери не стигат да правят предложения. Това е твърде грубо? Добре, нека опитам отново, младши тестери стигат да правят предложения в точното време на точните хора.

Когато за първи път започнем да разработваме функция или модул в началото на проектите, обикновено всички предложения са добре дошли. Ние мислим творчески, защото трябва да мислим за всички възможни крайни случаи и потребителски сценарии, за да пишем подробни и пълни тестови случаи. Това е, когато архитектите или дизайнерите на решения са най-склонни да слушат предложения и да вземат предвид нашите идеи.

Ако наистина вярвате, че вашият принос е ценен и сте направили изследването си, тогава продължете и ни заслепете. Въпреки това, ако нашите работни процеси, рендеринг и предложения вече са одобрени, внедрени и тествани, обикновено е твърде късно да промените нещата, без значение колко страхотни биха били вашите идеи. И никога не изпращайте грешки въз основа само на вашите собствени предпочитания.

3. Забравете за съществуването на вашия дизайнер

Говорейки за рендеринг, работни потоци и проблеми, свързани с тях, няма по-бърз начин да враг на вашия дизайнер, отколкото да надхвърлите главата им и да добавите подобрение в работата си или още по-лошо - грешки в дизайна им. Обичам дизайнерите си и много се доверявам на тяхната компетентност, че ако са проектирали функция по един начин, то те имат много добра причина да подкрепят това. Знам колко усилия влагат за изследване на различни идеи и знам, че те обикновено са в много тясно сътрудничество с клиента и вероятно са по-наясно с изискванията на клиента на потребителския интерфейс, отколкото аз.

Ако трябва да бъда напълно честен, все още понякога правя тази грешка и в разгара на момента решавам да добавя нещо към функция, без първо да се консултирам с моя дизайнер. Правя го с най-доброто намерение да подобря нещо, но най-доброто ми намерение означава малко, ако наруша договорения процес и добавя неочаквано забавяне.

4. Изпитай своите дяволи

Ааааа, дяволите могат да бъдат плашещи, дяволите могат да бъдат дразнещи, дяволите могат да бъдат арогантни и мрънкащи. Но девите винаги са най-добрият ти приятел, винаги! Така че опитвате всичко възможно и установявате доверителни отношения. Отиваш и мелиш, докато те търпят, смея да кажа, че дори и теб. Защото щастливи devs = щастливи QA. Дори ако трябва да чуете 1000 пъти „това не е грешка, това е функция“, вие хапете езика и упорствате. Ако не вярвате на нещо, което вашият дявол ви казва, можете да отидете при старши и да поискате второ мнение. Но в идеалния случай е най-добре, ако поддържате доверчиво партньорство. Трябва да се доверите на техния опит и тогава те ще се доверят на вашата компетентност. Тя е красива симбиоза, но крехка.

Девите трябва да се доверят, че имате гръб, че въпреки че искате да нарушите кода им, го правите с най-доброто намерение и за по-добро благо. И трябва да се доверите, че понякога, много рядко, бъг наистина е функция. :)

Най-бързият начин да ядосате dev btw е, когато тествате наполовина готов модул и добавяте куп грешки за неща, които още не са внедрени. Дайте им време, не ги бързайте и се опитвайте да задържите ентусиазма си, докато не свършат своята част и вашата част може да започне.

5. Да приемем, че сте твърде добри за документация

Аааа, това съм аз накратко. Най-досадната задача за мен е да пиша тестови случаи или да модифицирам съществуващите с нови крайни сценарии и информация, която разкрих по време на моето тестване. Когато съберете малко инерция и тествате увереността, започвате да пропускате основите. Намирате се, че сте твърде притиснати от времето, за да си направите труда следвайки шаблон за контролен списък, така че да го направите по памет без следа от вашите резултати. Толкова сте сигурни в способностите си, че забравяте, че всяко тестване трябва да има видим отпечатък. Особено, ако сами се справяте с даден проект и знаете всеки малък детайл за него, забравяте необходимостта от документи и това може толкова лесно да се върне и да ви захапе в тушата.

Виновна съм за това и за най-дълго време прескочих някои стъпки, за да имам повече време за други задачи. Но в някои случаи честната ви дума няма значение, освен ако нямате документ, който да ви направи резервно копие. Ако кажете например, че нещо е регресия, защото преди е работило безотказно и тогава някой ви моли да им покажете доказателство за това, а вие не можете, изглежда непрофесионално. Никога не знаете кога ще преминете към друг проект или някой друг трябва да поеме вашата работа и този някой друг ще бъде напълно загубен, освен ако не сте направили своята хартиена част.

6. Не се прави основата

Да приемем, че вашият проект е мобилно приложение, поддържано на Android и iOS. Младши тестер проверява телефон с Android и вижда срив. Джуниър е в екстаз, катастрофата е голяма работа, така че те бързат да го добавят в Джира възможно най-скоро и да вдигнат алармата. Това, което забравят, са всички останали стъпки, които човек трябва да направи, преди да добави грешка, особено важна. Преди да добавите проблем, има малко основи. Първо нещо е да проверите системата за подаване, каквато и да е тя, за дубликати. Никой не обича дубликатите и те карат да изглеждаш помия! Второто е да проверите на още няколко места, за да видите дали този проблем е специфичен за устройството, специфичен за платформата или общ. Така че те по-добре проверяват таблет с Android, а след това iOS устройство и др. Също така би било полезно да се съберат някои регистрационни файлове, така че разработващият да спести известно време, за да се опита да възпроизведе и бързо да провери регистрационните файлове. Също така е полезно да видите колко често можете да възпроизведете проблема, случва ли се всеки път или малко по-случайно. Изолирайте точните стъпки за проблема и също така проверете може би предишните компилации и версии, за да видите дали е наскоро въведена регресия или е била там и пропусната през цялото време.

Тези грешки са често срещана част от пътуването на QA и са естествена стъпка към процеса на обучение. Сега, след като преминах този скъпоценен товар от наследство по пътя, моля, уведомете ме в коментарите по-долу, ако сте виновен за някоя от тези грешки или може би има още по-непростими грешки за качество, които съм пропуснал.