Cześć, Habr!
Mamy nowy ważny temat – wysokiej jakości rozwój produktów IT. Często mówimy na HighLoad++, jak uczynić obciążone usługi szybszymi, a na Frontend Conf – o świetnym interfejsie użytkownika, który nie spowalnia. Regularnie poruszamy tematy związane z testowaniem, a na DevOpsConf omawiamy integrację różnych procesów, w tym testowanie. Natomiast na temat tego, co można nazwać jakością w całości i jak kompleksowo nad nią pracować – nie ma.
Naprawimy to na – będziemy rozwijać kulturę myślenia o jakości końcowego produktu dla użytkownika na każdym etapie rozwoju. Nałogowo nie skupiając się tylko na swojej strefie odpowiedzialności i kojarząc jakość nie tylko z testerami.
Pod katem porozmawiamy z przewodniczącą komitetu programowego, kierującą testowaniem w Tinkoff.Business, twórczynią rosyjskojęzycznej społeczności QA Anastasiją Aseyevą-Nguen o stanie branży QA i misji nowej konferencji.
– Nastya, cześć. Powiedz, proszę, coś o sobie.
Anastazja: Kieruję testowaniem w banku, odpowiadam za bardzo dużą drużynę – mamy ponad 90 osób. Mamy ważną linię biznesową, odpowiadamy za ekosystem dla klientów instytucjonalnych.
Studiowałam na matematyce i początkowo chciałam zostać programistką. Ale gdy pojawiła się interesująca oferta, postanowiłam spróbować swoich sił w roli testera. Jak się okazało, to moje powołanie. Teraz całą swoją pracę widzę właśnie w tej branży.
Jestem zagorzałą zwolenniczką dyscypliny Quality Assurance. Nie jest mi obojętne, jakie produkty są tworzone, jak traktuje się jakość w firmie, w zespole i w zasadzie w procesie rozwoju.
Dla mnie oczywiste jest, że społeczność w tym zakresie jest niewystarczająco dojrzała, przynajmniej w Rosji. Nie zawsze rozumiemy, że zapewnienie jakości to nie tylko sam fakt testowania aplikacji pod kątem zgodności z wymaganiami. Chciałabym zmienić tę sytuację.
– Używasz słów Quality Assurance i testowanie. W oczach przeciętnego człowieka te dwa terminy bardzo często się przenikają. Czym się różnią, jeśli sięgnąć głęboko?
Anastazja: Właściwie, nie różnią się. Testowanie to część dyscypliny zapewnienia jakości, to konkretna działalność — sam fakt, że coś testuję. Rodzajów testowania jest naprawdę bardzo wiele, a za różne rodzaje testów odpowiadają różne osoby. Jednak u nas w Polsce, kiedy pojawiła się fala outsourcingu, który dostarcza testerów do firm, testowanie zostało zredukowane do jednego rodzaju.
W większości przypadków ogranicza się jedynie do testowania funkcjonalnego: sprawdzają, czy to, co zaprogramowali deweloperzy, odpowiada specyfikacji i tyle.
— Opowiedz, proszę, jakie są jeszcze inne dyscypliny zapewnienia jakości? Co jeszcze, oprócz testowania, się na to składa?
Anastazja: Zapewnienie jakości to przede wszystkim tworzenie produktu wysokiej jakości. Innymi słowy, zadajemy sobie pytanie, jakie atrybuty jakości powinien mieć nasz produkt. Odpowiednio, jeśli to rozumiemy, możemy zdefiniować, kto wpływa na te atrybuty jakości. Nie jest istotne, czy to deweloper, project manager czy product owner — to osoba, która ma wpływ na rozwój produktu, jego backlog oraz strategię.
Tester lepiej zaczyna rozumieć swoją rolę. Rozumie, że jego zadaniem nie jest tylko testowanie zgodności z wymaganiami, ale także testowanie wymagań, stawianie pod znakiem zapytania sformułowania pochodzące od product ownera, odkrywanie wszystkich ukrytych wymagań i oczekiwań klienta. Kiedy dostarczamy nową funkcjonalność naszemu klientowi, musimy naprawdę spełnić jego oczekiwania i rozwiązać jego problemy. Jeśli będziemy myśleć o wszystkich atrybutach jakości, klient będzie zadowolony i zrozumie, że firma, której produktu używa, naprawdę dba o jego interesy, a nie działa według zasady 'byleby wypuścić funkcję'.
— Wydaje mi się, że to, co teraz opisałeś, to zadanie product ownera. To w zasadzie nie dotyczy testowania ani jakości — to w ogóle dotyczy zarządzania produktem, prawda?
Anastazja: W pewnym sensie. Zapewnienie jakości to nie dyscyplina, za którą odpowiada jedna konkretna osoba. Obecnie szczególnie popularne jest podejście do testowania, które nazywa się Agile TestingW jego definicji bezpośrednio zaznaczone jest, że to podejście zespołowe do testowania, które obejmuje określony zestaw praktyk. Za realizację tego podejścia odpowiada cały zespół, nawet niekoniecznie musi w nim być tester. Cały zespół jest ukierunkowany na dostarczenie wartości klienta, aby ta wartość odpowiadała jego oczekiwaniom.
— Czyli jakość przecina się niemal ze wszystkimi otaczającymi dyscyplinami, nakładając ramy na wszystko wokół?
Anastazja: Zgadza się. Kiedy myślimy o tym, co chcemy stworzyć jako wysokiej jakości produkt, zaczynamy zastanawiać się nad różnymi atrybutami jakości. Na przykład, jak sprawdzić, czy rzeczywiście stworzyliśmy funkcję, która jest potrzebna naszemu klientowi.
Tutaj pojawia się taki rodzaj testowania jak UAT (testowanie akceptacji przez użytkowników). Niestety, w Rosji rzadko jest praktykowane, ale czasami występuje w zespołach SCRUM jako demonstracja dla końcowego klienta. W zagranicznych firmach to dość powszechny rodzaj testowania. Przed udostępnieniem funkcjonalności wszystkim klientom najpierw przeprowadzamy UAT, to znaczy zapraszamy końcowego użytkownika, który prowadzi testy i od razu przekazuje feedback — czy produkt rzeczywiście odpowiada oczekiwaniom i rozwiązuje problem. Dopiero po tym następuje skalowanie dla wszystkich pozostałych klientów.
Czyli orientujemy się na biznes, na końcowego klienta, ale przy tym nie zapominamy o technologii. Od technologii również w dużym stopniu zależy jakość produktu. Jeśli będziemy mieć złą architekturę, nie będziemy w stanie szybko wypuszczać funkcji i spełniać oczekiwań klienta. Może być wiele błędów przy próbie skalowania, albo podczas próby refaktoryzacji możemy coś zepsuć. To wszystko wpłynie na satysfakcję klienta.
Z tego punktu widzenia architektura powinna być taka, abyśmy mogli pisać czysty kod, który pozwoli szybko wprowadzać zmiany i nie bać się, że wszystko się zepsuje. Aby iteracje poprawkowe nie trwały kilka miesięcy tylko dlatego, że mamy tyle legacji i potrzebne są długie etapy testowania.
— Już zaangażowani są programiści, architekci, produktowcy, menedżerowie produktu, sami testerzy. Kto jeszcze jest zaangażowany w proces zapewnienia jakości?
Anastazja: Teraz wyobraźmy sobie, że już dostarczyliśmy funkcję klientowi. Oczywiście, jakość produktu musi być monitorowana, nawet gdy jest już w produkcji. Na tym etapie mogą wystąpić sytuacje dotyczące nieoczywistych scenariuszy, tak zwanych błędów.
Pierwsze pytanie - jak radzimy sobie z tymi błędami po wydaniu produktu? Jak reagujemy na obciążenie? Klient nie będzie zbyt zadowolony, jeśli strona ładuje się dłużej niż 30 sekund.
Tu wchodzi w grę eksploatacja lub, jak to się teraz określa, DevOps. W rzeczywistości są to osoby odpowiedzialne za eksploatację produktu, gdy jest już na produkcji. Obejmuje to różne rodzaje monitorowania. Istnieje nawet podrodzaj testowania - testowanie na produkcji, kiedy pozwalamy sobie na coś nieprzetestowanego 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 go naprawić.
Infrastruktura również ma znaczenie. Często zdarzają się sytuacje, gdy podczas testów nie można upewnić się, że rzeczywiście mamy wszystko, co chcieliśmy przekazać klientowi. Wdrażamy na produkcję - i zaczynamy natrafiać na nieoczywiste sytuacje. A to dlatego, że infrastruktura w testach nie odpowiada infrastrukturze na produkcji. Stąd pojawia się nowy rodzaj testowania - testowanie infrastruktury. Są to różne konfiguracje, ustawienia, migracja baz danych itd.
Stąd rodzi się pytanie - może zespół powinien korzystać z infrastruktury jako kodu.
Wierzę, że infrastruktura ma bezpośredni wpływ na jakość produktu.
Mam nadzieję, że na konferencji będzie prezentacja z rzeczywistym przypadkiem. Napiszcie do nas, jeśli jesteście gotowi podzielić się swoim doświadczeniem, jak infrastruktura jako kod wpływa na jakość. Infrastruktura jako kod pozwala łatwiej sprawdzać wszystkie ustawienia i testować to, co w innym przypadku byłoby po prostu niemożliwe. Dlatego w procesie tworzenia jakościowego produktu zaangażowana jest również eksploatacja.
— A co z analizą i dokumentacją?
Anastazja: To odnosi się bardziej do systemów enterprise. Kiedy mówimy o enterprise, od razu myślimy o takich ludziach jak analitycy i analitycy systemowi. Czasami nazywani są pisarzami technicznymi. Otrzymują zlecenie na napisanie specyfikacji i realizują je, na przykład, przez miesiąc.
Wielokrotnie udowodniono, że tworzenie takiej dokumentacji prowadzi do bardzo długich iteracji rozwoju oraz długotrwałych iteracji poprawek, ponieważ w procesie testowania wykrywane są błędy, co prowadzi do zwrotów. W efekcie powstaje wiele pętli, które zwiększają koszt rozwoju. Dodatkowo może to wprowadzić podatności. Wydaje się, że napisaliśmy wzorcowy kod, ale potem wprowadzamy zmiany, które łamią idealnie przemyślaną architekturę.
W rezultacie otrzymujemy produkt niezbyt wysokiej jakości, ponieważ w architekturze pojawiły się już łatki, kod w niektórych miejscach jest niewystarczająco pokryty testami, ponieważ terminy gonią, trzeba szybciej zamknąć wszystkie błędy. A wszystko to dlatego, że w pierwotnej specyfikacji nie uwzględniono wszystkich aspektów, które należy zrealizować.
Programiści nie są złoczyńcami i nie piszą celowo kodu z błędami.
Gdybyśmy na początku przemyśleli specyfikację, w której przedstawione byłyby wszystkie niezbędne aspekty, wszystko byłoby zrealizowane tak, jak należy. Ale to utopia.
Najprawdopodobniej napisanie idealnej specyfikacji na 100 stron jest niemożliwe. Dlatego należy pomyśleć o alternatywnych sposobach pisania dokumentacji, specyfikowania, definiowania zadań, które przybliżyłyby nas do tego, aby programista robił dokładnie to, co potrzeba.
Tutaj przychodzą na myśl podejścia z Agile — historie użytkowników z kryteriami akceptacji. To bardziej stosowne dla zespołów, które rozwijają się w małych iteracjach.
— A co z testowaniem użyteczności, wygodą korzystania z produktu, designem?
Anastazja: To bardzo ważny aspekt, ponieważ w zespole są projektanci. Najczęściej przydają się jako usługa — albo dział projektantów, albo projektant na zlecenie. Często zdarza się, że projektant wysłuchał lidera produktu i zrobił to, co zrozumiał. Ale gdy przystępujemy do iteracji, okazuje się, że tak naprawdę zrobiono coś innego, niż oczekiwano: projektant coś zapomniał, nie do końca przemyślał zachowanie, ponieważ nie jest w zespole i nie jest w kontekście, albo front-endowy programista nie do końca zrozumiał jego makietę. Może być konieczne kilka iteracji tylko z powodu problemu z zrozumieniem designu przez front-end developera.
Jednakże istnieje jeszcze jeden problem. Obecnie zyskują popularność systemy designu. Są na fali, ale korzyści z nich nie są do końca oczywiste.
Spotykam się z opinią, że systemy designu, z jednej strony, upraszczają rozwój, a z drugiej strony nakładają wiele ograniczeń na interfejs.
W efekcie nie tworzymy funkcji, której klient chce, lecz taką, która jest dla nas wygodna, ponieważ mamy już określone elementy, z których możemy ją stworzyć.
Uważam, że warto zwrócić na to uwagę i zastanowić się, czy próbując uprościć pracę nad designem, rzeczywiście rozwiązujemy problem klienta.
— Wydaje się, że istnieje zadziwiająco wiele tematów związanych z zapewnieniem jakości. Czy w Rosji jest konferencja, na której można je wszystkie omówić?
Anastazja: Jest najstarsza konferencja poświęcona testowaniu, która w tym roku odbędzie się po raz 25 i nosi nazwę — Konferencja poświęcona zapewnieniu jakości SQA Days. Głównie omawia się na niej narzędzia i konkretne podejścia do testowania dla testerów funkcjonalnych. Zazwyczaj w wykładach na SQA Days dogłębnie rozważa się konkretne obszary odpowiedzialności samych testerów, ale nie kompleksowe działania.
To świetnie pomaga zrozumieć różne narzędzia i podejścia, jak testować bazy danych, API itp. Ale z jednej strony nie motywuje to do angażowania w tworzenie bardziej jakościowego produktu nie tylko testowania. Z drugiej strony, testerzy nie stają się bardziej zaangażowani w proces, aby myśleć o globalnym celu produktu i jego aspekcie biznesowym.
Kieruję dużym działem, przeprowadzam wiele rozmów kwalifikacyjnych, które tak naprawdę pozwalają przedstawić stan branży w całej rozciągłości. Zazwyczaj nasi ludzie pracują w dużych firmach i mają jasno określoną odpowiedzialność. Koledzy, którzy pracują w projektach zagranicznych, wykorzystują różne rodzaje testowania: sami mogą przeprowadzać testy obciążeniowe, testy wydajności, a nawet czasami testy bezpieczeństwa, ponieważ naprawdę pomagają zespołowi zapewniać produkt jakością.
Chciałbym, aby w Rosji także ludzie zaczęli myśleć o tym, że na testowaniu funkcjonalnym branża się nie kończy.
— Dlatego organizujemy nową konferencję QualityConf, poświęconą jakości jako całościowej dyscyplinie. Opowiedz więcej o koncepcji, jaki jest główny cel konferencji?
Anastazja: Chcemy stworzyć społeczność ludzi zainteresowanych tworzeniem wysokiej jakości produktów. Chcemy zaoferować platformę, na którą mogą przyjść, posłuchać prezentacji i wyjść z konferencji z konkretnym zrozumieniem, co muszą zmienić, aby poprawić jakość.
Często słyszę teraz zapytania od firm konsultingowych, co zrobić, gdy występują problemy z testowaniem, z jakością. Kiedy zaczynasz rozmawiać z zespołami, widzisz, że problem nie tkwi w samych testerach, lecz w tym, jak zorganizowany jest proces. Na przykład, gdy programiści uważają, że są odpowiedzialni tylko za napisanie kodu, ich odpowiedzialność kończy się w momencie, gdy przekazują zadanie do testowania.
Nie wszyscy zdają sobie sprawę, że źle napisany, niskiej jakości kod z kiepską architekturą grozi dużymi problemami dla projektu. Nie zastanawiają się nad kosztami błędów, nad tym, że błędy, które trafią do produkcji, mogą prowadzić do poważnych strat dla firmy i zespołu. Nie ma kultury myślenia o tym. Chcę, aby na konferencji zaczęto ją szerzyć.
Rozumiem, że to nie jest innowacja. Edward Deming, autor 14 postulatów jakości, pisał o kosztach błędu jeszcze w ubiegłym wieku. Na tej książce bazuje Quality Assurance jako dyscyplina, ale, niestety, współczesny rozwój o tym zapomina.
— Czy planujecie poruszyć tematy dotyczące testowania i narzędzi?
Anastazja: Przypuszczam, że będą prezentacje dotyczące narzędzi. Istnieją całkiem uniwersalne narzędzia, za pomocą których firmy i zespoły mogą wpływać na produkt.
Wszystkie prezentacje globalnie będą połączone jedną wspólną misją: przekazać publiczności, że za pomocą tego podejścia, narzędzia, metody, procesu, rodzaju testowania wpłynęliśmy na jakość produktu i poprawiliśmy życie klienta.
Na pewno nie będzie prezentacji dotyczących narzędzi dla samych narzędzi. Wszystkie prezentacje, które znajdą się w programie, będą miały wspólny cel.
— Kto według Ciebie byłby zainteresowany tym, o czym mówisz, kogo widzisz w roli gości konferencji?
Anastazja: Będzie to konferencja dla programistów, którym zależy na losie swojego projektu, produktu i systemu. Interesujące będzie to również dla testerów, a, jak sądzę, zwłaszcza dla menedżerów. Przez menedżerów rozumiem osoby, które podejmują decyzje i mogą wpływać na przyszłość i rozwój produktu, systemu oraz zespołu.
To są ludzie, którzy zastanawiają się, jak poprawić jakość produktu i systemu. Na naszej konferencji dowiedzą się o różnych zestawach działań i będą mogli zrozumieć, co jest teraz nie tak, co należy zmienić.
Uważam, że głównym kryterium jest świadomość, że z jakością jest coś nie tak i chęć wywarcia wpływu. Prawdopodobnie nie uda nam się dotrzeć do tych, którzy myślą, że wszystko jest w porządku, za pierwszym razem.
— Jak myślisz, czy branża dojrzała do rozmowy nie tylko o testowaniu, ale o kulturze jakości?
Anastazja: Uważam, że tak. Wiele firm odchodzi od tradycyjnego podejścia Waterfall w stronę Agile. Zaczynają się ukierunkowywać na klienta, ludzie w zespołach naprawdę zaczynają myśleć o tym, jak stworzyć produkt wysokiej jakości. Nawet w firmach korporacyjnych następuje przewartościowanie na poprawę jakości.
Patrząc na liczbę zapytań, które pojawiają się w społeczności, uważam, że to już czas. Nie jestem pewna, czy to będzie wielka rewolucja, ale chciałabym, żeby ten przewrót w myśleniu nastąpił.
— Umowa! Będziemy kształtować kulturę i zmieniać świadomość.
Konferencja o jakościowej produkcji IT. odbędzie się w Moskwie 7 czerwca. Wiecie, z jakich etapów składa się jakościowy produkt, mamy doświadczenia w skutecznym radzeniu sobie z błędami na produkcji, w naszej praktyce sprawdziliśmy popularne metody — potrzebujemy Waszego doświadczenia. swoje zgłoszenia do 1 maja, a Komitet Programowy pomoże skupić się na temacie w celu zachowania spójności konferencji.
Dołączcie do , na którym omawiamy kwestie jakości i konferencję, subskrybujcie , aby być na bieżąco z informacjami o programie.
Źródło: habr.com
