Czy uważasz, że to dobry pomysł, aby Inżynierowie oprogramowania musieli pracować przez pewien czas jako Inżynier ds. Zapewnienia Jakości? [Zamknięte]

12

Wierzę, że tak. Dlaczego?

  1. Spotkałem wielu inżynierów oprogramowania, którzy uważają, że są w jakiś sposób lepsi od inżynierów ds. Kontroli jakości. Myślę, że może to pomóc w stłumieniu tego przekonania, jeśli wykonają pracę inżyniera ds. Kontroli jakości przez pewien czas i zdadzą sobie sprawę, że jest to wyjątkowy i cenny zestaw umiejętności.

  2. Im lepiej inżynier oprogramowania testuje własne programy, tym mniejszy czas ponoszą ich kody podczas przechodzenia przez resztę cyklu życia oprogramowania.

  3. Im więcej czasu inżynier oprogramowania zastanawia się nad tym, jak program może się zepsuć, tym częściej muszą brać pod uwagę te przypadki podczas ich opracowywania, zmniejszając w ten sposób błędy w produkcie końcowym.

  4. Definicja „kompletna” inżyniera oprogramowania jest zawsze interesująca ... jeśli spędzili czas jako inżynier ds. Kontroli jakości, być może ta definicja będzie bardziej pasować do projektanta oprogramowania.

Uwaga: Sugeruję powyższą sugestię z niewielkim przedziałem czasowym, ponieważ jestem świadom, że ktoś pracuje na stanowisku innym niż stanowisko, na które jest zatrudniony, jest zdecydowanie receptą na utratę tego programisty.

Co wszyscy myślicie

Macy Abbey
źródło
1
Moją pierwszą pracą była kontrola jakości. Nienawidziłem tego, ale NAPRAWDĘ zrozumiałem znaczenie kontroli jakości.
Job
Nie w pełni doceniłem kreatywność związaną z kontrolą jakości, dopóki nie przeczytałem klasycznej sztuki testowania oprogramowania Glenford Myers .
Macneil
5
Spotkałem wielu inżynierów oprogramowania, którzy uważają, że są w jakiś sposób lepsi od wszystkich innych na świecie ;-)
Steven A. Lowe
Zbyt prawdziwy Steven.
Macy Abbey
1
Sugerowałbym zamiast tego zapytać, czy inżynierowie oprogramowania powinni zrobić kilka czynności związanych z kontrolą jakości, zamiast myśleć, że zmusi je jakiś niezidentyfikowany byt.
David Thornley,

Odpowiedzi:

13

1. Spotkałem wielu inżynierów oprogramowania, którzy uważają, że są w jakiś sposób lepsi od inżynierów ds. Kontroli jakości. Myślę, że może to pomóc w stłumieniu tego przekonania, jeśli wykonają pracę inżyniera ds. Kontroli jakości przez pewien czas i zdadzą sobie sprawę, że jest to wyjątkowy i cenny zestaw umiejętności.

Dobra inżynieria oprogramowania ma podłoże jakościowe, w tym testy, pomiary i statystyki. Każdy, kto tworzy oprogramowanie, powinien być świadomy (jeśli nie jest zaznajomiony) z utrzymywaniem wysokiej jakości kodu źródłowego i produkowaniem / utrzymywaniem efektywnych przypadków testowych. Z biegiem czasu podejrzewam, że każdy programista zrozumie różne aspekty jakości - jakość kodu, przenośność, łatwość konserwacji, testowalność, użyteczność, niezawodność, wydajność i bezpieczeństwo.

Inżynierowie oprogramowania mogą skoncentrować się na określonym aspekcie cyklu życia - inżynierii wymagań, architekturze i projektowaniu, budowie, testowaniu i konserwacji. Jednak niezależnie od tego, na czym się koncentrujesz (zarówno jako praca, jak i na obecnym etapie projektu), ważne jest, aby pamiętać o jakości.

2. Im lepiej inżynier oprogramowania testuje swoje własne programy, tym mniejszy czas poniesie ich kod podczas przechodzenia przez resztę cyklu życia oprogramowania.

To może być prawda. Ale niektóre problemy najlepiej widać później. Na przykład problemy z wydajnością i wydajnością mogą być widoczne dopiero po integracji. Posiadanie dobrego, solidnego kodu i skutecznych testów jednostkowych to dopiero początek. Jakość musi zaczynać się od wymagań i podążać przez cały czas czynnościami konserwacyjnymi.

3. Im więcej czasu Inżynier oprogramowania zastanawia się nad tym, jak program może się zepsuć, tym częściej rozważa te przypadki podczas ich opracowywania, zmniejszając w ten sposób błędy w produkcie końcowym.

To całkowicie prawdziwe stwierdzenie. Ale z drugiej strony inżynierowie wymagań muszą sprawdzić, czy nie ma konfliktów w wymaganiach, architekci upewnią się, że projekt faktycznie spełnia wymagania i tak dalej. Wszyscy powinni starać się dziurawić dziury w swojej pracy, a następnie współpracować z odpowiednimi ludźmi, aby uszczelnić ich dobrze i mocno.

4. Definicja „kompletna” inżyniera oprogramowania jest zawsze interesująca ... jeśli spędzili czas jako inżynier ds. Kontroli jakości, być może definicja ta będzie bardziej pasować do projektanta oprogramowania.

„Kompletny” można zmierzyć tylko w odniesieniu do wymagań. Albo wymagania są spełnione, a projekt jest ukończony, lub istnieją niekompletne wymagania i projekt nie jest kompletny. Wszelkie inne miary kompletności są bezużyteczne.

Thomas Owens
źródło
Dzięki Thomas, to bardzo pouczająca i przemyślana odpowiedź.
Macy Abbey
6

Zadbanie o to, by programiści byli odpowiedzialni za swój kod i wymagali od nich naprawiania własnych błędów. To i utrata premii i / lub pracy.

Nie żeby to doświadczenie nie pomogło, ale jak daleko można posunąć się przy takim myśleniu? Wsparcie techniczne, sprzedaż, użytkownik wersji beta, szoruj toalety (byłoby to upokarzające doświadczenie).

JeffO
źródło
To prawda, Jeff, ale myślę, że pierwsze podejście niekoniecznie uczy ich narzędzi, których potrzebują, aby stać się bardziej wydajnymi / niezawodnymi programistami. To jednak wywiera presję, co jest dobre.
Macy Abbey
Ponadto, jednym z negatywnych aspektów tego podejścia jest utrata programisty na pewien okres czasu, tydzień ... dwa tygodnie, miesiąc? I nie sądzę, że dobrym pomysłem jest, aby wykonywały prace, które mają niewiele wspólnego z ich obecną pracą ... (szorowanie toalet: P)
Macy Abbey
6

„... muszą pracować jako inżynierowie QA ...”? Sprawiasz, że brzmi to przeciwnie lub kara.

Jestem programistą. Uważam, że częścią mojej pracy jest także inżynier ds. Kontroli jakości, mimo że mamy dział kontroli jakości. Moim zadaniem jest dostarczanie oprogramowania, które osiąga pewne cele, i aby to zrobić, muszę napisać testy jednostkowe i upewnić się, że oprogramowanie je pomyślnie przeszło.

Współpracuję z naszym działem kontroli jakości. Moim celem jest ułatwienie ich pracy, tak jak ich praca polega na tym, aby pomóc mi osiągnąć cel, jakim jest dostarczanie oprogramowania, które robi to, co powinno, a tym samym ułatwić mi życie. Uważam je za mój drugi zestaw oczu i coś w rodzaju siatki bezpieczeństwa, tak jak robię moje testy jednostkowe.

Wybieram tworzenie oprogramowania i chcę tworzyć oprogramowanie. Gdyby jakiś menedżer przyszedł do mnie i powiedział, że nie mogę tego zrobić i musiałem przeprowadzić kontrolę jakości, powiedziałbym im, że muszą znaleźć nowego programistę ORAZ osobę odpowiedzialną za kontrolę jakości, ponieważ nie będę tam pracował. Jestem analny, jak mogę, z moim kodem, ale proces twórczy i programowanie puzzli / wyzwań jest dla mnie niezwykle ważne. Wolałbym wrócić do jazdy na wózkach widłowych, jeśli nie mogę pisać kodu, ponieważ przebywanie w środowisku korporacyjnym bez przywileju kreatywności i wyzwania, jakim jestem, byłoby dla mnie absolutnym piekłem.

Ogólnie rzecz biorąc, opcje, które prezentujesz, brzmią bardzo przeciwnie i pozostawiają mnie zastanawiającego się, czy masz naprawdę złe doświadczenia z okropnymi programistami. Moim zdaniem deweloper musi ZAWSZE zdawać sobie sprawę z problemów związanych z jakością i testami oraz powinien być na tyle dumny ze swojej pracy, że nie uzna ich za zakończone, dopóki nie przejdą tak rygorystycznych testów w testach jednostkowych, jak to, czego użyje oficjalny dział kontroli jakości. Gdybym miał rówieśnika lub był kierownikiem technicznym w zespole i miał programistę, który wykazywałby jakąkolwiek „skłonność” do kontroli jakości, znalazłby mnie, gdybym go odciągał w celu korekty postawy. Jeśli obie strony monety dostarczającej oprogramowanie nie mogą współpracować i działać jako zespół, istnieje prawdziwy problem kulturowy. Nie chciałbym tam pracować, a dział HR wraz z wyższym kierownictwem musiałby zostać wtrącony.

Blaszany Człowiek
źródło
Cześć Greg, zadałem pytanie myśląc o inżynierze oprogramowania, który jest nowy w tej dziedzinie i nie rozumie wartości QA i który nie miał dużego doświadczenia w opracowywaniu zestawu dobrze zdefiniowanych kryteriów akceptacji. Powodem, dla którego wybrałem „muszę” jest to, że, jak powiedziałeś, nie sądzę, aby wielu inżynierów oprogramowania wybrało pracę jako inżynier zapewniania jakości (jako ich jedyny obowiązek), ponieważ wyraźnie wybrali programistę. Zdecydowanie doceniam i podzielam twoje zdanie na temat tego, jakie powinno być podejście naprawdę dobrego programisty i związek z kontrolą jakości.
Macy Abbey
Czy uważasz, że zatrudnienie nowego inżyniera oprogramowania jako inżyniera ds. Kontroli jakości pomogłoby im osiągnąć punkt, w którym jesteś teraz?
Macy Abbey
1
Absolutnie nie. Upewnij się, że rozumieją, jak działają zespoły; Rozwijaj postawę własności problemów; Kultury otwartej atmosfery, która zachęca ludzi do pracy w zespołach ad hoc do dyskusji i rozwiązywania problemów. Zbyt wiele osób i firm popiera silosy wiedzy i postawę „my przeciwko wszystkim”. Szczerze mówiąc, „my przeciwko wszystkim” musi odejść w głąb firmowych ścian, ponieważ rani wszystkich.
Tin Man
2
@Macy Abbey, jedną z taktyk do rozważenia może być umożliwienie programistom współpracy z zespołem ds. Kontroli jakości w celu opracowania scenariuszy testowych. Testy jednostkowe mogą być napisane i zaprojektowane w tandemie, lub zespół kontroli jakości może dodać swoje testy do folderu „testy”, w którym programista przeprowadza testy jednostkowe. Niektórzy uważają, że powinno istnieć oddzielenie deweloperów od kontroli jakości, ale sprzyja to konkurencji. Jeśli obie grupy wspólnie używają gałek ocznych i testują sztuczki, być może mogą jeszcze szybciej wykryć błędy i pominięte funkcje.
Tin Man
@Greg Dzięki Greg, to brzmi jak dobra taktyka. Wierzę, że przekonałeś mnie, że kombinacja innych taktyk jest lepsza niż początkowo proponowałem.
Macy Abbey,
5

Pozyskanie programistów do pracy jako inżynierowie ds. Kontroli jakości to przepis na utratę najlepszych programistów. Programowanie i kontrola jakości wymagają różnych zestawów umiejętności i procesów myślowych.

Ważne jest jednak, aby programiści posiadali umiejętności testowania i zatwierdzania własnej pracy przed przekazaniem jej zespołowi ds. Kontroli jakości. Programiści i QA mają dostęp do różnych narzędzi, wiedzy i umiejętności. Programiści muszą posiadać umiejętność przechodzenia przez kod w poszukiwaniu nieoczekiwanego zachowania, testowania jednostkowego w warunkach granicznych, obciążania kodu wątkowego w poszukiwaniu warunków wyścigu itp. Tj. Testowanie z perspektywy programisty.

QA przeprowadzają testy z perspektywy użytkownika. Myślenie jak różne typy użytkowników, wymyślanie dziwnych przypadków skrajnych i odtwarzanie nieznanych problemów to umiejętności zapewniania jakości.

Michael Shaw
źródło
1
Dzięki Ptolemeuszowi, proponuję tę sugestię z niewielkim przedziałem czasowym, ponieważ jestem świadom, że ktoś pracuje na stanowisku innym niż stanowisko, na które jest zatrudniony, jest zdecydowanie receptą na utratę tego programisty.
Macy Abbey
Nie chodzi tylko o to, że nie pracowaliby na stanowisku, dla którego zostali zatrudnieni, nie byliby też na stanowiskach, które wybrali jako swój zawód i poszli do szkoły. To poważny policzek dla wielu ludzi, którzy wkładają serca w karierę. Dla tych, którzy uważają pracę tylko za wypłatę, będzie dobrze.
Tin Man,
@Greg: Ci, którzy czekają na wypłatę, również jej się nie spodobają. Ich wznowienie będzie cenniejsze przy X + 1 roku inżynierii oprogramowania niż X lat inżynierii oprogramowania i roku kontroli jakości, przynajmniej na początku. Nie wspominając już o tym, że musisz płacić swoim pracownikom ds. Kontroli jakości, a także programistom, ponieważ nikt w wypłacie nie zaakceptuje obniżki wynagrodzenia.
David Thornley,
To znaczy, że pracujesz w miejscu, w którym wykwalifikowani ludzie QA płacą mniej niż deweloperzy. Wiem, że niektóre miejsca tak robią, ale to nie odzwierciedla mojego doświadczenia - kiedy znam pensje ludzi, są na ogół na równi.
testerab,
1
We wczesnych latach bycia programistą twoja pensja jest bardzo zależna od tego, ile masz lat doświadczenia w programowaniu. Zatem posiadanie 2 lat C # i rocznej kontroli jakości daje ci 2-letnią pensję C # zamiast 3-letniej pensji C #.
Michael Shaw,
3

Niekoniecznie - od programistów i testerów wymaga się różnych umiejętności. To, że jesteś dobrym programistą, nie oznacza, że ​​możesz być dobrym testerem (wiele osób tego nie rozumie, ale bycie programistą nie kwalifikuje cię automatycznie do bycia testerem).

Wielki tester musi mieć naprawdę diabelskie umiejętności, być w stanie robić rzeczy, do których oprogramowanie nie zostało zaprojektowane, ale może oczekiwać, że użytkownik zrobi to w prawdziwym świecie. Wymaga to umiejętności, cierpliwości, umiejętności zobaczenia, co może pójść nie tak, zrozumienia mentalności użytkownika i wielu innych czynników.

Zauważ, że używam słów programista i tester - ale jeśli jesteś inżynierem oprogramowania i jeszcze nie zdecydowałeś, czy chcesz zostać programistą czy testerem, to obejmuje obie te rzeczy, a zatem tak, powinieneś mieć doświadczenie w obu w pierwszych latach życia przed podjęciem decyzji.

Nie oznacza to, że bierzesz doświadczonego programistę i każesz mu przez chwilę testować, aby zrozumieć, jak ciężko pracują inżynierowie ds. Kontroli jakości.

Roopesh Shenoy
źródło
True Roopesh, chociaż myślę, że zdecydowanie istnieje skrzyżowanie dwóch zestawów umiejętności, gdzie praca jako QA przez krótki czas zwiększy szybkość, z jaką ktoś poprawi swoje umiejętności testowania.
Macy Abbey
1

Oto niektóre potencjalne problemy, które widzę z twoją propozycją:

1) Jeśli sugerujesz, że chciałbyś zatrudnić nowych inżynierów oprogramowania w dziale kontroli jakości na krótki czas, czy nie będzie to miało odwrotnego skutku? - mogą założyć, że QA jest czymś, co robisz, gdy jesteś nowicjuszem i nie rozumiesz, co robisz - w końcu tak to dla nich działało.

2) Będąc przez jakiś czas bardzo złym testerem, niekoniecznie nauczy ich niczego cennego. Ale może to uczynić ich później nieosiągalnymi, ponieważ założą , że wiedzą teraz wszystko o testowaniu, ponieważ spędzili kiedyś 6 tygodni w dziale testowym.

3) Biorąc pod uwagę, że oczywiście będą tam tylko przez krótki czas, a dział kontroli jakości będzie o tym wiedział, prawdopodobne jest również, że zostaną im przydzielone stosunkowo mało wymagające, łatwe zadania, które wymagają niewielkiego nadzoru lub zrozumienia, ale które utrzymują ich zajęty . To tylko wzmocni 1 i 2.

4) Jeśli chcesz uniknąć 1, 2 i 3, w jaki sposób przekonasz swój dział testowy, że warto zainwestować ogromną ilość energii w nauczanie i nadzorowanie osoby, która nawet nie jest zainteresowana testowaniem? (Mogę powiedzieć, że praca z kimś, kto, pamiętajmy, nie został wybrany ze względu na swoje umiejętności testowe , zajmuje strasznie dużo czasu i energii . Nie oferujesz zespołowi testowemu dodatkowych zasobów przez kilka tygodni, proszą ich o utratę jednego z najbardziej doświadczonych ludzi na kilka tygodni, podczas gdy uczą nowicjusza).

Powiedziawszy to wszystko, myślę, że twój ogólny cel - zwiększenie zrozumienia nowych inżynierów oprogramowania w zakresie testowania - jest naprawdę fantastyczny. Myślę, że sugestia Grega jest bardziej prawdopodobna - spraw, by zespoły projektantów i kontroli jakości ściśle ze sobą współpracowały i pracowały nad przełamaniem wszelkich barier między zespołami. (Obecnie pracuję w firmie, w której testerzy i programiści pracują w tym samym zespole - to naprawdę świetne i nigdy nie chcę wracać do pracy w osobnych zespołach).

Jeśli nadal chcesz, aby programiści zaczęli ćwiczyć kontrolę jakości - oto sugestia: dawaj przykład. Idź sam pierwszy. Być może sprawią, że członkowie twojego zespołu zrobią to, gdy są już dobrzy i chcą uzyskać dodatkową przewagę, spędzając co tydzień trochę czasu z innymi zespołami, które specjalizują się w nakładających się obszarach - test, DBA itp. Jeśli przedstawisz to w ten sposób, wtedy będziesz mieć większą szansę na sukces.

testerab
źródło
0

Miałem rodzaj ścieżki kariery, która jest odwrotnością tego, co zwykle widzisz. Zaczynałem jako wsparcie oprogramowania dla naukowo trudnej fizyki, a potem pracowałem na skrzyżowaniu architektury, programowania i algorytmów dla firmy komputerowej. Po tym skończyłem przez kilka lat optymalizowałem wydajność głównego kodu inżynierskiego, ale nawet ta praca się skończyła. Teraz, gdy zbliżam się do wieku emerytalnego, przeprowadzam kontrolę jakości tego samego kodu. Jest to połączenie wyzwania i znoju. Mamy naprawdę sprytnego nowego faceta, który w 100% pracuje nad poprawkami błędów i spędzam z nim dużo pracy. To trudna pozycja i możesz się wiele nauczyć. W tym momencie moim głównym zainteresowaniem w rozwoju zawodowym są moi bliźniacy, którzy są studentami pierwszego roku na uczelni. Mam więc nowe zainteresowanie nauką (lub ponownym uczeniem się) rzeczy, które będą odpowiednie dla ich kariery, szczególnie matematyki stosowanej. Mam teraz inną perspektywę rzeczy, gdy martwię się o kontrolę jakości / walidację. W poprzednim kwartale była to prędkość, prędkość, prędkość za wszelką cenę.

Omega Centauri
źródło
Ta anegdota nie wydaje się zawierać żadnej odpowiedzi na pytanie.
nikt
-2

Testowanie oprogramowania jest procesem destrukcyjnym, a nie konstruktywnym. Ale programiści myślą o konstruktywności swojego produktu, aby zapewnić, że produkt zostanie ukończony na czas i zgodnie z budżetem. Jeśli twórca oprogramowania myśli o destrukcji własnego produktu, to kto będzie następny do jego zbudowania. Tak więc każda część cyklu tworzenia oprogramowania musi być wykonana przez osoby przypisane do każdej części cyklu programowania. Jeśli zaangażowałeś się w co najmniej dwa pola, to jest pewne, że nigdy nie będziesz doskonały na żadnym z nich, więc zrób jedną rzecz albo programistę, albo QA, albo dowolne inne opcje i bądź na tym doskonały.

Panjiyar Rahul
źródło