Poznámka: Jsem 25letým veteránem vývoje softwaru jako inženýr a technický vedoucí.

Dobrý inženýr QA má pro vývojový tým hodnotu své váhy ve zlatě a je součástí jeho práce má být nit-vybíravý - ale na konkrétní věci.

Mělo by dojít k očekávanému výsledku pro dodanou část funkce - v tomto případě je rozhraní uživatelským rozhraním. Inženýr QA by měl znát očekávaný výsledek a porovnat dodanou funkčnost s očekáváními. Pokud existují nějaké rozdíly, zdokumentujete je jakýmkoli způsobem dohodnutým (nástroj pro hlášení chyb atd.) A poskytnete co nejvíce podrobností - minimálně očekávaný výsledek, skutečný výsledek a kroky k reprodukci skutečného výsledku.

Sonarcube atd. kontroluje kvalitu kódu, což podle mého názoru není součástí odpovědnosti inženýra QA - nadřízený vývojář nebo technický vedoucí by to měl vyzvednout.

Požádání o ID na tlačítkách a pole umožňující automatizaci je zcela rozumný požadavek, a pokud se vývojáři zdráhají, možná je to proto, že si neuvědomují výhody automatizovaného testování? Mohli byste jim vysvětlit - možná by byla dobrá rychlá prezentace s funkčními příklady - dobří vývojáři si rychle uvědomí, že cokoli, co na začátku procesu zkontroluje chyby, jim v konečném důsledku usnadní život.

Zaměřit se na věci, které máte za úkol - přesnost softwaru, shoda s požadavky, automatizace testování. Doručte to a lidé uvidí vaši hodnotu procesu.

^{Pozadí: Jsem mladý vývojář softwaru}

Vysvětlete jim proč musí změnit způsob kódování. Předpokládám, že existují dobré důvody, proč je o to požádáte.

„Kvalita kódu, ovladatelnost a testovatelnost“ jsou výrazy, které znějí jako urážky vývojářů (tj. „váš kód má nízkou kvalitu“). Tyto podmínky jsou příliš obecné a obvykle nejsou dobře přijaty.

Místo toho podrobně vysvětlete, v čem je problém a proč je potřebujete ke změně určitých věcí. To jim buď umožní porozumět, nebo alespoň zmírní jejich hněv / mrzutost vůči rozhodovateli (tj. Osobě, která se rozhodla, že potřebujete řádné testy. Pokud jste náhodou vy, můžete také vysvětlit potřebu testů). Příklad použití testovatelnosti: Vysvětlení vašeho problému, jako je tento, přinese mnohem lepší výsledky než obecná kritika testovatelnosti:

Všiml jsem si, že některé důležité prvky HTML nemají vlastnost id. Vím, že k tomu, aby naše aplikace fungovala, nutně nepotřebují, ale bez nich nemůžeme vytvořit správné testy pro uživatelské rozhraní, které požadoval rozhodovací pracovník XY. Proto potřebuji vidět vlastnosti id přidané k tomuto, tomuto a tomuto prvku, stejně jako ke všem tlačítkům a vstupním prvkům v budoucích pohledech. Chápu, že to vyžaduje více práce na vaší straně, ale je to nutné pro správné testování naší aplikace.

TL; DR
Získejte pochopení vývojářů důvody pro změnu kódování. Když přesně pochopí, proč se to od nich ptáte, už proti vám nebudou mít zášť.

Způsob, jakým vývojáři kódují, je upřímně váš. Pokud se pokusíte přimět je, aby to změnili, nezískáte nic jiného než krvavý nos (obrazně řečeno). Vaše podnikání je kvalita produktu a vše, co vám pomáhá dělat vaši práci nebo ji ztěžuje. Kód vývojáře k tomu není součástí.

Pokud neexistují žádné procesy, které by usnadňovaly QA, určitě tyto procesy vytvořte, projednejte je se všemi zúčastněnými a implementujte je.

Pokud existují funkce produktu, které by vám pomohly při testování, ujistěte se, že tyto funkce identifikujete, požádáte o ně a budou upřednostněny jako ostatní požadavky na funkce. Pokud něco potřebujete, zeptejte se pěkně a v rozumném týmu vám pomůže, pokud to jejich čas a jiné priority dovolí.

Ale když vývojářům řeknete, jak mají dělat svou práci, udělá z vás spoustu nepřátel, bez ohledu na to, jak se o to pokusíte.

Pokud jde o „nitpicky“: Měli byste být nitpicky, když zkontrolujete, zda produkt dělá to, co má. „Nitpicky“ je pozitivní kvalita pro inženýra QA. Mám jednoho inženýra QA, který není nitpický, ale absolutně zlý a pomáhá hodně zlepšit kvalitu produktu.

A pokud má produkt spoustu drobných chyb, na které si stěžuje pouze „nitpický“ technik QA, pak jsou zákazníci mnohem méně shovívaví, pokud narazí na velké problémy. Další výhoda nitpického inženýra QA: Vývojáři často vědí o malých chybách a chtěli by je opravit, ale mají na vedení tlak dělat jiné věci. Tento vývojář vám může být vděčný za vytvoření hlášení o chybě, protože nyní může říci „Musím to opravit, protože QA si stěžoval“ místo „Chtěl bych to opravit, protože to nevypadá úplně správně“.

Po vašich dodatcích: Pokud vývojáři vypadají naštvaní na práci navíc, je to normální a nemusíte se ničeho obávat :-) Je však třeba prozkoumat, jak je práce u vás řešena.

Pokud řeknete „I need XYZ“ a vývojářovi trvá den, než pro vás XYZ udělá, vypadá to na jeho šéfa, jako by celý den nic neudělal. U mě byste vyplnili požadavek, já bych udělal práci, označil bych požadavek jako „hotový“ a mohu říci svému šéfovi „ne, nebyl jsem líný celý den, udělal jsem to velmi důležité věc, kterou Noon potřebovala pro svou práci “. To je ten rozdíl.

Pokud vaše místo ještě není tak dobře organizované (a když jsem QA zavedl před pouhými 2 týdny, mohl bych se obávat nejhoršího), je to něco, co musíte udělat. Je to pravděpodobně něco, kde by stálo za to převzít iniciativu. Důležité je, že pro vývojáře vytvoříte práci navíc (a to je přesně vaše práce), pak to musí být provedeno způsobem, který je viditelný pro šéfa.

Mluvím z pohledu vedoucího / softwarového architekta DevOps s mnoha zkušenostmi se spoluprací s QA folk, včetně automatizované QA.

Moje oficiální odpověď na vaši otázku je vybrat si pečlivě zahajte bitvy a nakonec zvyšte rozsah svých iniciativ, aby dopady, které si přejete, byly dobré.

Můj význam: přidejte iniciativy v oblasti kvality kódu, které budou mít nejrychlejší výplaty za dlouho, sloggingové kampaně. Dobrým příkladem je přidání id k věcem v HTML. Díky němu je kód testovatelný v automatizovaném prostředí a měl by být rychle realizovatelný.

Kvalita kódu má dlouhodobé výhody, ale při krátkodobých nákladech na zdroje, protože jde o práci, která se obvykle nepovažuje za produktivní (pro určité definice produktivních: tj. „získávání nových funkcí“).

V zavedené kódové základně je náročné zvyšovat kvalitu kódu těžko prodávat. Rovněž doporučuji strategičtější a postupnější proces, protože již funguje kód a změna kódu přináší riziko.

Doporučuji najít několik kratších iniciativ, které prokazují výhody, a v tom okamžiku si vývojáři pravděpodobně uvědomí že vaše iniciativy nejsou pouhými pedantskými protivnými pravidly, která je třeba dodržovat, ale spíše aktivitami, které pro ně budou mít dlouhodobý přínos.

Rovněž velmi doporučuji minimalizovat nakládání a vaření oceánu tím, že budete dávat příliš mnoho pozadí a pozadí za tím, proč něco děláš. Kvalita kódu je důležitá a dobrá, ale mnoho lidí to považuje za nezajímavé.

A je nezbytné přijít s dobrým způsobem realizace iniciativ. Upřednostňujte výroky jako „Prosím, udělejte Y místo X“ místo „Nedělejte X, udělejte Y“. (Pokud pozorně sledujete, tato věta je strukturována podle pokynů, které zastává.)

Dobře, máme tu již spoustu odpovědí, které vám poradí ohledně vaší otázky z hlediska profesionálního inženýrství a pracoviště. Můžu se všemi víceméně souhlasit, takže se budu držet toho, co pro mě znamená 2 centy, a pokusím se odpovědět na tuto otázku s ohledem na mezilidské hledisko vaší situace.

Odmítnutí odpovědnosti: Být na autistické spektrum Mohl bych jít do podrobností, které většina ani nebude považovat za problém. Ale protože pro mě byly / jsou problematické, je to záloha pro můj způsob řešení.

Takže první kontrast, který zde vidím z většiny odpovědí na rozdíl od vaší situace, většina lidí odpovídá profesionálové s předchozími zkušenostmi v QA. Dokud většina zaměstnanců ve vaší společnosti nejsou starší vývojáři, můžete předpokládat, že nemají takové předchozí zkušenosti.

V mých předchozích zaměstnáních jsem vždy byl „tím nitpicky otravný spolupracovník “, ale to byla hlavní příčina, protože QA nebyla moje práce. Zajímavá věc, kterou vám tehdy mohu říci, je: Lidé se mnou obvykle nesouhlasili. Byli jen v pracovní kultuře, která se nestarala o kvalitu, a proto našli někoho, kdo se stará o kvalitu, omezující hluk.

Mějte tedy na paměti, že by tomu tak mohlo být i ve vaší práci (I když se to zjevně předpokládá bude změněno).

Dovolte mi, abych vám řekl něco o mé současné pracovní pozici. Vím, že je to něco, co nemůžete provést sami, ani to není kulturní změna, kterou lze provést krátkodobě. Ale může vám poskytnout představu o tom, jak nebýt nitpickou zlobou, pokud je na vaší straně horní úroveň společnosti ¹ .

Takže na rozdíl od svých předchozích pracovních míst nyní pracuji pro velmi velkou společnost a utrácím obrovské množství zdrojů za kvalitu. Nejsem přímo pracuje v QA, ale jako analytik dodržování licencí, takže v rozpisu je stále mojí prací ověřovat kód jiných národů. Zde skutečně musí každý produkt projít našimi kontrolami, než bude povoleno jeho vydání. Existují zdokumentované požadavky, které produkt musí splňovat, aby mohl být zkontrolován mým týmem, a vše, co musíme udělat, je zkontrolovat a udělit souhlas nebo odmítnout. Není tedy na nás, abychom rozhodli, co je třeba zkontrolovat. To má za následek, že projektové týmy nás nevidí jako lidi narušující jejich termíny, ale spíše nás požádají o pomoc, pokud jejich projekt neprochází našimi analýzami a nemohou přijít na to, jak to opravit ^{2 .}

Vezmeme-li v úvahu tento dobře fungující postup, doporučuji vám následující:

Za prvé, a hlavně pro mě nejdůležitější, protože jsem autista ³ , ujistěte se, že máte jistotu, co se od vaší role očekává. Navzdory tomu, že nitpicky je pro QA inženýra dobrá vlastnost, může mít vaše společnost špatnou představu o tom, jaká by měla být odpovědnost QA inženýra.

Takže si domluvte schůzku s nadřízeným a požádejte ho, aby vám dal jasná definice vaší odpovědnosti ve vaší roli. Zkuste se vyvarovat toho, o čem si myslíte, že je vaše zodpovědnost, a požádat o potvrzení a raději je nechat vysvětlit. Snažte se vidět jejich vysvětlení plně oddělené od vaší vlastní představy o tom, jaká by měla být vaše odpovědnost, pokud se vám zdá neúplné, požádejte o vysvětlení, ale nehádejte se.

Poté napište návrh své odpovědnosti. Opět to, jak jste jim porozuměli, ne to, co si myslíte, že by mělo být. A pak do tohoto návrhu přidejte část, ve které bude uvedeno, za co NENÍ vaše odpovědnost. Zde můžete přidat všechny části, o kterých si myslíte, že by měly být součástí vaší role, ale nebyly zmíněny. Čím více se budete cítit nepříjemně, když něco není součástí vaší role, tím dramatičtější bude moje formulace ⁴ .

Dejte tento návrh svému nadřízenému a požádejte ho, aby ho schválil. Nakonec tento návrh přizpůsobte, dokud nebude schválen a voilà, máte definitivní klasifikaci své odpovědnosti.

To vám dává jistotu třemi způsoby:

• Víte jaké aspekty kvality jsou pro společnost důležité, a tedy o co se musíte starat.

• Nemusíte si dělat starosti s tím, co považujete za důležité ohledně kvality softwaru, protože mají výslovnou písemnou radu, aby tyto aspekty nezohledňovaly. To je také užitečné, abyste se v budoucnu vyhnuli obviňování z toho, že jste se o tato opatření nestarali, jak jste již písemně doporučili.

• Nejdůležitější ohledně OP. Už to není váš osobní názor na kvalitu, ale písemná smlouva o tom, jaký je názor společnosti na to, co by mělo být zajištěno. Takže už za to nemůžete rozumně obviňovat. Nebo pokud je součástí „ne“, nemusíte se obtěžovat ani vy, ani vývojáři, protože společnost jasně vyjadřuje, že si nepřeje, aby byla tato část pokryta.

¹ Doufám, že jsou, protože jinak by vaše zaměstnání bylo fraškou.

² No, v jejich rámci jsem si docela jistý týmy nás tak stále vidí. Jde ale o to, že jim nemusíme říkat, jak opravit svůj kód, ale musí se nás zeptat, co máme dělat, pokud dojde k problémům s kódem, díky kterému neprojde našimi výslovně definovanými a zdokumentovanými kontrolami.

³ Právě jsem si uvědomil, jak moc se tu může pokazit, když jsem přišel do pracovního prostředí, kde je naštěstí zdokumentováno vše v každém ohledu, a všiml jsem si, kolik prostoru pro nedorozumění bylo v mém nedostatek takových zásad předchozí práce.

⁴ Nevím, jestli je to dobrá nebo špatná rada, je to přesně to, co bych udělal.

Jsem vývojář (C ++) a často čelím přesně stejnému problému. Jsem trochu starší (26), ale stále poměrně mladý. Náš tým se skládá z 5 lidí s průměrným věkem 35 let. Jsem jediný v našem týmu, kterému opravdu záleží na dobrém kódu, pokud jde o čitelnost, udržovatelnost a konzistenci. 3 z nás dělá tuto práci od 6 do 10 let a mají své (částečně špatné) návyky.

Když se je snažím přesvědčit, měl jsem nejlepší úspěch, když jsem jim vysvětlil výhody změny specifické chování kódování. Je velmi důležité, abyste je nekritizovali, ale aby byl nový styl atraktivnější, protože nikdo nemá rád, když mu někdo říká, že dělá něco špatně.

Váš příklad, ke kterému bych přistoupil jako:

Dobrý den, vaše konvence pojmenování je pochopitelná, můžeme ji však vylepšit přidáním „id“ do identifikátoru. Tímto způsobem bude velmi pohodlné iterovat prvky tím, že najdete všechny řádky obsahující „id“. Také bychom měli lepší přehled o použití automatického doplňování / intellisense.

Zažil jsem, že málokdy mám úspěch, pokud moje návrhy zní jako kritici. Pokud víte, že váš návrh je skutečným zlepšením, najdete dobré důvody proč. Prostě nikdy nebuďte osobní, ale ukažte výhody oproti skutečnému stylu kódování.

^{Pozadí : Mám 10 a více let zkušeností v managementu, 19 let pracuji v IT prostředí a moje současná role 2 roky je součástí vývojového týmu. sup >}

Možná máte pravdu o tom, jak někteří vývojáři mohou reagovat na kontrolu své práce, ale protože se zdá, že máte technické zázemí a používáte technická řešení k provádění těchto kontrol I myslím, že pravděpodobně budeš v pořádku.

Vývoj je jen částí mé práce, takže ve své odpovědi mohu být méně technický než někteří jiní, ale viděl jsem, jak se moje vlastní prostředí mění od prostředí, kde je nebyly téměř žádné ovládací prvky na místě a vývojáři byli v kapsách kolem velké organizace, vyvíjející se s úplnou autonomií ve svém vlastním stylu, do správně řízeného prostředí pomocí repozitářů Git, řízení verzí atd. Tyto věci vývojáři rychle přijali, protože jedna věc o většině vývojářů můžete říci, že milují udržování aktuálních informací o nejnovějších nástrojích. Mít kontrolní opatření přináší míru administrativní zátěže, ale také mnoho výhod, a protože technologie sama o sobě je docela „cool“ :) Totéž může dobře platit o vás, když zavádíte věci jako SonarQube, vývojářům se to může líbit.

Moje rada by byla:

1. Udělejte vše o kódu, ne o jednotlivcích.
Jasně od začátku a vše, co děláte, je, že vaší rolí je dohlížet na kvalitu kódu , nevystavovat vývojáře s nedostatečnou výkonností.

2. Buďte techničtí. Ale neblafujte
Viděl jsem to už desítkykrát - lidé přicházejí pracovat do IT prostředí a jsou tak vystrašení z toho, že vědí méně než kdokoli jiný, co se snaží a blufují si cestu technologickými rozhovory. Ne. Nakonec vypadáš jen hloupě. Každý má své silné a slabé stránky, takže buďte asertivní v tom, co víte, ale upřímní v tom, co ne. Pozvěte lidi, aby vám pomohli vyplnit všechny mezery ve vašich znalostech. Mnoho vývojářů miluje příležitost hovořit o tom, co vědí, a pokud budete dost pokorní na to, abyste přiznali, že něco nevíte, budete přístupnější.

3. Proměňte všechna nová opatření nebo kontroly, které zavedete, na „příležitosti osobního rozvoje“.
Mnoho dalších organizací již zavedlo mnoho opatření, která zavedete. Namísto toho, abyste se cítili, jako byste jim představovali administrativní zátěž, „prodejte“ jim změny jako něco, co je osobně rozvíjí. Pokud se v budoucnu rozhodnou pro nové zaměstnání jinde, bude jejich zkušenost zde velkým rozhodnutím. Možnost říci, že pracovali ve správně kontrolovaném prostředí s kontrolou kvality na místě, je tak říkajíc pírko v čepici.

4. Udržujte svou autoritu
Vyvažujte všechny výše uvedené skutečnosti a udržujte úroveň autority, která se od vás v rámci této role očekává. Manažeři, kteří se snaží spřátelit se svými zaměstnanci, obvykle zjistí, že jejich autorita je podkopána. I když možná nejste přímým manažerem vývojářů, máte co dělat, takže se ujistěte, že vám v tom nebrání. Jistě, vaším stanoveným cílem je vyhnout se tomu, abyste se nestali „nitpickerem“ a dráždili lidi, se kterými pracujete, ale z hlediska kariéry možná budete chtít více sledovat, jak plníte očekávání své role a potěšíte své šéfy, než abyste byli přijati vývojáři jako „jeden z nich“, i když ve skutečnosti máte jinou a odlišnou roli.