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]

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

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.

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).

„... 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.

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.

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.

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.

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ę.

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.