Hej Habra!
Mamy nowy ważny temat - wysokiej jakości rozwój produktów IT. W HighLoad++ często mówimy o tym, jak przyspieszyć zajęte usługi, a na Frontend Conf mówimy o fajnym interfejsie użytkownika, który nie zwalnia. Regularnie poruszamy tematy dotyczące testowania i DevOpsConf dotyczące łączenia różnych procesów, w tym testowania. Ale o tym, co w ogóle można nazwać jakością i jak kompleksowo nad nią pracować - nie.
Naprawmy to — rozwiniemy kulturę myślenia o jakości produktu finalnego dla użytkownika na każdym etapie rozwoju. Nawyk nie skupiania się na swoim obszarze odpowiedzialności i kojarzenia jakości nie tylko z testerami.
Poniżej cięcia porozmawiamy z szefem komitetu programowego, szefem testów w Tinkoff.Business, twórcą rosyjskojęzycznej społeczności QA Anastazja Aseeva-Nguyen o stanie branży QA i misji nowej konferencji.
- Nastia, cześć. Proszę opowiedzieć nam coś o sobie.
Anastasia: Zarządzam testowaniem w banku, odpowiadam za bardzo duży zespół – jest nas ponad 90 osób. Mamy ważną linię biznesową, odpowiadamy za ekosystem dla osób prawnych.
Studiowałem mechanikę i matematykę i początkowo chciałem zostać programistą. Kiedy jednak dostałem ciekawą ofertę, postanowiłem spróbować swoich sił w roli testera. Co dziwne, okazało się to moim powołaniem. Teraz widzę całą moją pracę w tej branży.
Jestem gorącym zwolennikiem dyscypliny Zapewnienia Jakości. Nie jest mi obojętne to, jakie produkty powstają, jak traktuje się jakość w firmie, w zespole i w zasadzie w procesie rozwoju.
Dla mnie to oczywiste społeczność podążająca w tym kierunku nie jest wystarczająco dojrzałaprzynajmniej w Rosji. Nie zawsze rozumiemy, że zapewnienie jakości to nie tylko fakt przetestowania aplikacji pod kątem zgodności z wymaganiami. Chciałbym zmienić tę sytuację.
— Używasz słów „Zapewnienie jakości” i „testowanie”. W oczach przeciętnego człowieka te dwa pojęcia bardzo często się pokrywają. Czym się różnią, jeśli kopiesz głęboko?
Anastazja: Raczej niczym się nie różnią. Testowanie jest częścią dyscypliny Zapewnienia Jakości, jest działaniem bezpośrednim – samym faktem, że coś testuję. W rzeczywistości istnieje wiele rodzajów testów i różne osoby są odpowiedzialne za różne rodzaje testów. Ale tutaj, w Rosji, kiedy pojawiła się fala outsourcerów dostarczających firmom testery, testowanie zostało zredukowane do jednego typu.
W większości przypadków ograniczają się jedynie do testów funkcjonalnych: sprawdzają, czy to, co napisali twórcy, jest zgodne ze specyfikacją i tyle.
— Proszę nam powiedzieć, jakie inne dyscypliny zapewniania jakości istnieją? Co jeszcze poza testowaniem wchodzi tutaj w grę?
Anastasia: Zapewnienie jakości polega przede wszystkim na stworzeniu produktu wysokiej jakości. Oznacza to, że zadajemy sobie pytanie, jakie cechy jakościowe powinien posiadać nasz produkt. W związku z tym, jeśli to zrozumiemy, możemy porównać, kto wpływa na te atrybuty jakości. nie ma znaczenia, programista, kierownik projektu czy specjalista ds. produktu to osoba, która ma wpływ na rozwój produktu, jego backlog i strategię.
Tester staje się bardziej świadomy swojej roli. Rozumie, że jego zadaniem jest nie tylko badanie zgodności z wymaganiami, ale także testowanie wymagań, kwestionowanie sformułowań płynących od specjalisty ds. produktu i ujawnianie wszelkich ukrytych wymagań i oczekiwań klienta. Dostarczając nową funkcjonalność naszemu klientowi, musimy naprawdę spełnić jego oczekiwania i rozwiązać jego problemy. Jeśli pomyślimy o wszystkich atrybutach jakości, klient będzie usatysfakcjonowany i zrozumie, że firma, z której produktu korzysta, naprawdę dba o jego interesy, a nie działa na zasadzie „tylko po to, żeby wypuścić funkcję”.
— Wygląda na to, że to, co właśnie opisałeś, jest zadaniem specjalisty ds. produktu. W zasadzie nie chodzi tutaj o testowanie ani o jakość – ogólnie chodzi o zarządzanie produktem, prawda?
Anastasia: W tym. Zapewnianie jakości nie jest dziedziną, za którą odpowiada jedna konkretna osoba. Obecnie popularnym kierunkiem testowania jest podejście zwane Testowanie zwinne. Z jego definicji jasno wynika, że jest to zespołowe podejście do testowania, które obejmuje pewien zestaw praktyk. Za wdrożenie tego podejścia odpowiedzialny jest cały zespół, nie jest konieczne nawet, aby w zespole był tester. Cały zespół koncentruje się na dostarczaniu wartości klientowi i dbaniu o to, aby wartość spełniała jego oczekiwania.
— Okazuje się, że jakość krzyżuje się z niemal wszystkimi otaczającymi ją dyscyplinami, narzucając ramy wszystkiemu dookoła?
Anastasia: Prawidłowy. Kiedy myślimy o tym, jak chcemy stworzyć produkt wysokiej jakości, zaczynamy myśleć o różnych atrybutach jakości. Na przykład, jak sprawdzić, czy naprawdę wykonaliśmy funkcję, której potrzebuje nasz klient.
Tutaj pojawia się ten typ testów: UAT (testy akceptacyjne użytkownika). Niestety w Rosji jest to rzadko praktykowane, ale czasami występuje w zespołach SCRUMowych jako demo dla klienta końcowego. Jest to dość powszechny rodzaj testów w firmach zagranicznych. Przed udostępnieniem funkcjonalności wszystkim klientom najpierw wykonujemy UAT, czyli zapraszamy użytkownika końcowego, który testuje i od razu daje informację zwrotną – czy produkt rzeczywiście spełnia oczekiwania i rozwiązuje problem. Dopiero potem następuje skalowanie do wszystkich innych klientów.
Oznacza to, że skupiamy się na biznesie, na kliencie końcowym, ale jednocześnie nie zapomnij o technologii. Jakość produktu w dużej mierze zależy również od technologii. Jeśli będziemy mieli złą architekturę, nie będziemy w stanie szybko wypuścić funkcji i spełnić oczekiwań klientów. Podczas próby skalowania może wystąpić wiele błędów lub podczas próby refaktoryzacji możemy coś zepsuć. Wszystko to będzie miało wpływ na zadowolenie klientów.
Z tego punktu widzenia architektura powinna być taka, abyśmy mogli napisać czysty kod, który pozwoli nam szybko wprowadzać zmiany i nie bać się, że wszystko zepsujemy. Aby iteracje wersji nie rozciągały się na kilka miesięcy tylko dlatego, że mamy tak duże dziedzictwo i musimy przeprowadzać długie etapy testowania.
— W sumie zaangażowani są już programiści, architekci, naukowcy zajmujący się produktami, menedżerowie produktów i sami testerzy. Kto jeszcze jest zaangażowany w proces zapewnienia jakości?
Anastasia: Teraz wyobraźmy sobie, że dostarczyliśmy już tę funkcję klientowi. Oczywiście jakość produktu należy monitorować nawet wtedy, gdy jest on już w produkcji. Na tym etapie mogą pojawić się sytuacje o nieoczywistych scenariuszach, tzw. bugi.
Pierwsze pytanie brzmi: jak sobie poradzić z tymi błędami po wydaniu produktu? Jak na przykład reagujemy na stres? Klient nie będzie zbyt zadowolony, jeśli ładowanie strony będzie trwało dłużej niż 30 sekund.
Tutaj wkracza wyzysk lub, jak to teraz nazywają, DevOps. Tak naprawdę to właśnie oni odpowiadają za obsługę produktu, gdy jest on już w fazie produkcyjnej. Obejmuje to różne rodzaje monitorowania. Istnieje nawet podtyp testowania – testowanie na produkcji, kiedy pozwalamy sobie nie testować czegoś przed wdrożeniem i testujemy to od razu na produkcji. To szereg działań z punktu widzenia organizacji infrastruktury, które pozwalają szybko zareagować na incydent, wpłynąć na niego i skorygować.
Ważna jest także infrastruktura. Często zdarzają się sytuacje, gdy podczas testu nie da się upewnić, że naprawdę mamy wszystko, co chcielibyśmy dać klientowi. Wdrażamy to na produkcję i zaczynamy wyłapywać nieoczywiste sytuacje. A wszystko dlatego, że infrastruktura w teście nie odpowiada infrastrukturze w produkcji. Prowadzi to do nowego typu testów – testowanie infrastruktury. Są to różne konfiguracje, ustawienia, migracja bazy danych itp.
Rodzi to pytanie – być może zespół musi wykorzystać infrastrukturę jako kod.
Wierzę, że infrastruktura bezpośrednio wpływa na jakość produktu.
Mam nadzieję, że na konferencji będzie relacja z prawdziwym przypadkiem. Napisz do nas, jeśli jesteś gotowy opowiedzieć nam z własnego doświadczenia, jak infrastruktura jako kod wpływa na jakość. Infrastruktura jako kod ułatwia sprawdzanie wszystkich ustawień i testowanie rzeczy, które w innym przypadku byłyby po prostu niemożliwe. Dlatego w proces tworzenia produktu wysokiej jakości zaangażowana jest również operacja.
— A co z analizą i dokumentacją?
Anastasia: Dotyczy to bardziej systemów korporacyjnych. Kiedy mówimy o przedsiębiorstwie, od razu na myśl przychodzą nam analitycy i analitycy systemów. Czasami nazywa się ich pisarzami technicznymi. Dostają zadanie napisania specyfikacji i jej realizacji np. przez miesiąc.
Wielokrotnie udowodniono, że pisanie takiej dokumentacji prowadzi do bardzo długich iteracji programistycznych i długich iteracji udoskonalania, ponieważ w trakcie procesu testowania identyfikowane są błędy i rozpoczynają się zwroty. W rezultacie istnieje wiele pętli, które zwiększają koszty rozwoju. Ponadto może to spowodować powstanie luk w zabezpieczeniach. Niby mamy napisany kod referencyjny, ale potem wprowadziliśmy zmiany, które łamią doskonale przemyślaną architekturę.
Efektem końcowym jest produkt nie do końca wysokiej jakości, bo w architekturze pojawiły się już łatki, kod w niektórych miejscach nie jest dostatecznie objęty testami, bo terminy uciekają, wszystkie błędy trzeba szybko zamknąć. A wszystko dlatego, że oryginalna specyfikacja nie uwzględniała wszystkich punktów, które należy wdrożyć.
Programiści nie są szkodnikami i nie piszą celowo kodu z błędami.
Gdybyśmy początkowo przemyśleli specyfikację, która obejmowałaby wszystkie niezbędne punkty, to wszystko zostałoby wdrożone dokładnie tak, jak trzeba. Ale to jest utopia.
Prawdopodobnie nie jest możliwe napisanie idealnej 100-stronicowej specyfikacji. Dlatego trzeba pomyśleć o alternatywnych sposobach pisania dokumentacji, specyfikacje, ustawienie zadań, które przybliżą nas do tego, aby deweloper zrobił dokładnie to, co jest potrzebne.
Tutaj na myśl przychodzą mi podejścia z Agile – historie użytkowników z kryteriami akceptacji. Ma to większe zastosowanie w przypadku zespołów, które rozwijają się w małych iteracjach.
— A co z testowaniem użyteczności, użytecznością produktu, projektowaniem?
Anastasia: To bardzo ważny punkt, ponieważ w zespole są projektanci. Najczęściej projektanci są wykorzystywani jako usługa - albo przez dział projektowy, albo przez zewnętrznego projektanta. Często zdarzają się sytuacje, w których wydaje się, że projektant wysłuchał specjalisty ds. produktu i zrobił to, co zrozumiał. Ale kiedy zaczynamy iterację, okazuje się, że to, co faktycznie zostało zrobione, nie było tym, czego oczekiwano: projektant o czymś zapomniał, nie przemyślał do końca zachowania, bo nie jest w zespole i nie w kontekście, ani na froncie -end developer nie do końca zrozumiał układ. Może to zająć kilka iteracji tylko dlatego, że programista front-end ma problem ze zrozumieniem projektu.
Poza tym jest jeszcze jeden problem. Systemy projektowania zyskują obecnie na popularności. Jest o nich głośno, ale korzyści z nich nie są całkowicie oczywiste.
Spotkałem się z opinią, że projektowanie systemów z jednej strony upraszcza rozwój, ale z drugiej strony nakłada wiele ograniczeń na interfejs.
W rezultacie nie wykonujemy takiej funkcjonalności, jakiej życzy sobie klient, a taką, która jest dla nas wygodna, bo mamy już pewne kostki, z których możemy ją wykonać.
Myślę, że jest to temat warty uwagi i zastanowienia się, czy próbując ułatwić projektowanie, faktycznie rozwiązujemy problem klienta.
— Istnieje zaskakująca liczba tematów związanych z zapewnianiem jakości. Czy w Rosji odbywa się konferencja, na której można omówić wszystkie te kwestie?
Anastasia: Odbywa się najstarsza konferencja testująca, która odbędzie się w tym roku po raz 25. i nosi nazwę Konferencji Zapewnienia Jakości Dni SQA. Omówiono w nim głównie narzędzia i konkretne podejścia do testowania dla testerów funkcjonalnych. Z reguły raporty na SQA Days dogłębnie badają konkretne obszary w obszarze odpowiedzialności samych testerów, a nie skomplikowane działania.
Bardzo pomaga to w zrozumieniu różnych narzędzi i podejść, testowaniu baz danych, interfejsów API itp. Ale jednocześnie z jednej strony nie motywuje to do angażowania się w coś więcej niż tylko testowanie w tworzenie lepszego produktu. Z drugiej strony testerzy nie angażują się bardziej w proces, aby myśleć o globalnym celu produktu i jego komponentu biznesowego.
Prowadzę duży dział i przeprowadzam wiele wywiadów, które naprawdę dają wgląd w stan branży jako całości. Z reguły nasi ludzie pracują w przedsiębiorstwach i mają jasny zakres odpowiedzialności. Koledzy pracujący w projektach zagranicznych stosują różne rodzaje testów: sami mogą przeprowadzić testy obciążeniowe, testy wydajnościowe, a czasem nawet testy bezpieczeństwa, ponieważ naprawdę pomagają zespołowi zapewnić jakość produktu.
Chciałbym, żeby chłopaki w Rosji również zaczęli myśleć, że branża nie kończy się na testach funkcjonalnych.
— W tym celu organizujemy nową konferencję QualityConf, poświęconą jakości jako dyscyplinie integralnej. Opowiedz nam więcej o idei, jaki jest główny cel konferencji?
Anastasia: Chcemy stworzyć społeczność ludzi zainteresowanych wytwarzaniem produktów wysokiej jakości. Zaoferuj platformę, na którą będą mogli przyjść, wysłuchać raportów i wyjść po konferencji ze szczegółowym zrozumieniem tego, co należy zmienić, aby poprawić jakość.
Obecnie często słyszę od konsultantów prośby o to, co zrobić, gdy pojawiają się problemy z testowaniem i jakością. Kiedy zaczynasz komunikować się z zespołami, widzisz, że problem nie leży w samych testerach, ale w strukturze procesu. Na przykład, jeśli programiści uważają, że są odpowiedzialni tylko za pisanie kodu, ich odpowiedzialność kończy się dokładnie w momencie przekazania zadania testowaniu.
Nie każdy myśli o tym, że źle napisany, niskiej jakości kod o słabej architekturze grozi dużymi problemami dla projektu. Nie myślą o kosztach błędów, o tym, że błędy, które trafiają do produkcji, mogą skutkować dużymi kosztami dla firmy i zespołu. Brakuje kultury, żeby o tym myśleć. Chcę, żebyśmy zaczęli to rozpowszechniać na konferencji.
Rozumiem, że to nie jest innowacja – o kosztach błędu pisał już w ubiegłym wieku Edward Deming, autor 14 zasad jakości. Zapewnianie jakości jako dyscyplina opiera się na tej książce, ale niestety współczesny rozwój o tym zapomina.
— Czy planujecie poruszać bezpośrednio tematy związane z testowaniem i narzędziami?
Anastasia: Przyznaję, że będą raporty o narzędziach. Istnieją dość uniwersalne narzędzia, za pomocą których firmy i zespoły mogą wpływać na produkt.
Wszystkie raporty będą globalnie zjednoczone jedną wspólną misją: przekazać odbiorcom, że za pomocą tego podejścia, narzędzia, metody, procesu, rodzaju testów wpłynęliśmy na jakość produktu i poprawiliśmy życie klienta.
Zdecydowanie nie będziemy mieć raportów o narzędziu dla samego narzędzia. Wszystkie raporty uwzględnione w programie będzie łączył wspólny cel.
— Kogo będzie interesowało to, o czym mówisz, kogo postrzegasz jako gości konferencji?
Anastasia: Będziemy mieć raporty dla programistów, którym zależy na losach swojego projektu, produktu, systemu. Podobnie będzie interesujące dla testerów i, jak sądzę, zwłaszcza dla menedżerów. Przez menedżerów mam na myśli ludzi, którzy podejmują decyzje i mogą wpływać na losy i rozwój produktu, systemu, zespołu.
To ludzie, którzy zastanawiają się, jak poprawić jakość produktu lub systemu. Na naszej konferencji poznają różne zestawy środków i będą mogli zrozumieć, co jest z nimi teraz nie tak, a co należy zmienić.
Myślę, że głównym kryterium jest zrozumienie, że coś jest nie tak z jakością i chęć wpływania na to. Prawdopodobnie nie uda nam się dotrzeć do osób, które myślą, że uda się to tylko za pierwszym razem.
— Czy sądzisz, że branża jako całość jest dojrzała, aby rozmawiać nie tylko o testowaniu, ale także o kulturze jakości?
Anastasia: Myślę, że dojrzałem. Obecnie wiele firm odchodzi od tradycyjnego podejścia Waterfall na rzecz Agile. Koncentruje się na kliencie, ludzie w zespołach naprawdę zaczynają myśleć o tym, jak stworzyć produkt wysokiej jakości. Nawet przedsiębiorstwa skupiają się na poprawie jakości.
Sądząc po liczbie próśb, które pojawiają się we wspólnocie, uważam, że już czas. Nie jestem oczywiście pewien, czy będzie to rewolucja na dużą skalę, ale chciałbym, żeby ta rewolucja w świadomości nastąpiła.
- Zgadza się! Będziemy zaszczepiać kulturę i zmieniać świadomość.
Konferencja poświęcona wysokiej jakości rozwojowi produktów IT odbędzie się w Moskwie 7 czerwca. Wiesz, z jakich etapów składa się produkt wysokiej jakości, mamy przypadki skutecznego zwalczania błędów w produkcji, sprawdziliśmy w naszej praktyce popularne metody - potrzebujemy Twojego doświadczenia. ich zgłoszenia do 1 maja, a Komitet Programowy pomoże skupić temat w celu zapewnienia ogólnej integralności konferencji.
Połącz z , w którym omawiamy kwestie jakościowe oraz konferencję, zapisz się aby być na bieżąco z aktualnościami programowymi.
Źródło: www.habr.com