Przesuń w górę i rozszerz: nowa koncepcja testowania z Iman Benlekehal

Discover how to deliver better software and systems in rapidly scaling environments. Join our Community

Iman Benlekehal proponuje nową koncepcję testowania o nazwie „Przesuń w górę i rozszerz”. Podkreśla znaczenie wczesnego zaangażowania testerów w proces tworzenia oprogramowania i przekonuje, że testerzy powinni aktywnie edukować interesariuszy w zakresie zapewniania jakości.

Iman jest doświadczoną liderką ds. zapewniania jakości z siedzibą w Québecu w Kanadzie. Została zwyciężczynią konkursu The Test Factor podczas The Testing Festival 2021, co z pewnością jest jak dotąd najważniejszym osiągnięciem w jej karierze… 

Porozmawialiśmy z nią, aby dowiedzieć się więcej o zwycięskiej koncepcji, o tym, co ją zainspirowało, o jej podejściu do testowania oraz o jej dotychczasowej drodze. Sądzimy, że wiele z tych kwestii będzie wam bliskich!

QAL

Cześć Iman, witamy w społeczności QAL. Zacznijmy od początku. Jak zainteresowałaś się testowaniem? Czy wcześniej byłaś programistką?

Iman Benlekehal

Uczyłam się programowania, więc wiem, jak kodować, ale nigdy nie pracowałam jako programistka. Po studiach uczestniczyłam w kilku rozmowach kwalifikacyjnych, a jedna z nich dotyczyła stanowiska testera. Zapytałam: „Dobrze, więc czym jest testowanie?” Ta osoba tak naprawdę nie odpowiedziała szczegółowo na moje pytanie, tylko zadała mi wiele pytań dotyczących mnie jako osoby — interesowała ją moja osobowość. Następnie powiedziała mi: „Czeka cię rozmowa w ING Direct, internetowym banku oszczędnościowym”

Podczas rozmowy kwalifikacyjnej wydarzyło się to samo. Osoba prowadząca rozmowę również zadała mi kilka pytań dotyczących testowania, na przykład: „Jak przetestowałabyś tę umowę lub te odsetki?” oraz „Wyobraź sobie, że mamy te oferty dla tego rodzaju konta. Jak byś je przetestowała?” Pamiętam, że zadawałam jej więcej pytań, niż ona zadała mnie.

Kiedy wróciłam do domu, przyjaciółka zapytała mnie, jak poszło, a ja odpowiedziałam: „Cóż, to dziwne. Zadałam jej  więcej pytań, niż ona zadała mnie, a na jej pytania dotyczące testowania nie potrafiłam odpowiedzieć. Więc nie wiem, chyba poszło źle”.

Ku mojemu zaskoczeniu zostałam zatrudniona i nadal zadawałam sobie pytanie: „Dobrze, czym jest to testowanie? Co będę testować?” A mój pierwszy szef powiedział: „Nie wiesz nic o testowaniu. Oto zdanie lub wymaganie — napisz przypadek testowy”. Odpowiedziałam mu: „Nigdy nie pisałam przypadku testowego”. Powiedział: „Zrób to, potem zobaczymy”. Więc [to] zrobiłam. A on powiedział: „Czyli zrobiłaś to dobrze”. Wtedy pomyślałam: „Dobrze, rozumiem. Nie będę testować przycisków?” „Nie, będziesz testować wymagania. Sprawdzać, czy są wiarygodne i zrozumiałe”. Pomyślałam więc: „Dobrze, to praca, w której mam prawo zadawać pytania?” A on odpowiedział: „Zgadza się”. Od tego momentu stało się to moją pasją. Uwielbiam tę pracę.

QAL

Więc tak opisałabyś testowanie — zadawanie właściwych pytań?

Iman Benlekehal

Właśnie to lubię, ponieważ mam prawo pytać „dlaczego” i „jak”. We Francji, kiedy jesteś młodą uczennicą lub studentką, nie wolno ci zadawać pogłębionych pytań o to, dlaczego i jak coś się dzieje, chyba że najpierw zdobędziesz dyplom, ale ja zawsze lubiłam rozumieć, dlaczego rzeczy dzieją się w określony sposób. Dlaczego proszą mnie, żebym coś zrobiła? W tej roli miałam prawo zadawać takie pytania. To należało do moich obowiązków, więc bardzo mnie to cieszyło. Byłam bardzo podekscytowana. To pierwsza rzecz, którą pokochałam.

Drugim powodem jest to, że lubię ludzi i pracę z różnymi osobami. Uwielbiam związane z tym wyzwanie oraz sprawianie, by ludzie mówili tym samym językiem i dążyli do tego samego celu. Użytkownik chce czegoś, szef [który] chce czegoś innego, a programista mówi jeszcze coś innego. A ty jesteś jakoś pośrodku tego wszystkiego i musisz sprawić, żeby się zrozumieli. To właśnie wyzwanie podoba mi się najbardziej — sprawianie, by ludzie się wzajemnie rozumieli.

Get Free Access
Get regular tech leadership wisdom for delivering better software and systems.
Get Free Access

Have an account? Log In

QAL

Testowanie nie polega więc tylko na tym, że pojawiasz się pod koniec tworzenia oprogramowania, sprawdzasz je i próbujesz coś zepsuć?

Iman Benlekehal

Moim zdaniem nie, to znacznie więcej. To podstawowa rzecz, jedno z zadań. Załóżmy, że masz 100% zaliczonych testów — co sprawia, że te 100% zaliczonych testów jest odpowiednie dla użytkownika? 

Cieszysz się, ponieważ pokryłaś 100% wymagań. Ale co sprawia, że sądzisz, iż pokrycie obejmuje dokładnie to, co jest naprawdę potrzebne? Jeśli nie widzisz użytkowników i nie rozumiesz powodów ani sposobu działania, możesz testować wszystko, co chcesz, ale nie będzie to właściwe.

QAL

Lubisz więc ściśle współpracować z zespołem UX i zespołem ds. badań użytkowników?

Iman Benlekehal

Staram się pracować ze wszystkimi. W niektórych zespołach projektowych to właściciel produktu znajduje się na pierwszym planie i przemawia w imieniu wszystkich, w tym użytkowników. I to jest w porządku, lubię z nimi pracować. Ale lubię też słyszeć, czego użytkownicy naprawdę potrzebują z punktu widzenia jakości, a nie tylko funkcjonalności. Dlatego nawet jeśli menedżerowie produktu mówią mi, że to są te osoby i że to oni są interesariuszami, poszerzam perspektywę i zadaję więcej pytań. Kim oni są? Czy zdają sobie sprawę, że to, o co proszą, będzie miało taki wpływ? Tego rodzaju pytania. Dla mnie nie chodziło więc wyłącznie o testowanie — było ono tylko jednym z elementów.

Powiązany artykuł: PRZYWÓDZTWO W TESTOWANIU: NARZĘDZIA DO TESTOWANIA

QAL

Chodzi więc bardziej o całościowe spojrzenie na cały projekt?

Iman Benlekehal

Dokładnie.

QAL

Rozumiem. Czyli to właśnie zainspirowało koncepcję przesuwania w górę i rozpowszechniania? Przy okazji gratuluję zwycięstwa w konkursie Test Factor!

Iman Benlekehal

Dziękuję! Ta koncepcja pojawiła się po pracy we Francji i Kanadzie oraz po zauważeniu, że niezależnie od sektora i kontynentu wciąż mamy te same problemy. Jakość i testowanie są utrzymywane wyłącznie na poziomie projektu. I jak już mówiłem, przesuwam granice, naciskam na interesariuszy, ponieważ jeśli pozostawimy ich na tym samym poziomie, próbując rozwiązać lub przetestować wszystko, co zostało tutaj przekazane, wiem z własnego doświadczenia, że na końcu będziemy mieć problemy z użytkownikami. Będziemy mieć problemy budżetowe i inne problemy.

Pewnego dnia powiedziałem więc: „Dobrze, przestańmy myśleć o przesuwaniu w prawo, przestańmy myśleć o przesuwaniu w lewo. Przede wszystkim trzeba iść w górę i przekonać hierarchię, najwyższe kierownictwo, czym jest jakość. Czym jest zapewnianie jakości, jaki jest nasz cel? Jak to przebiega. Jak to działa. To nie tylko testowanie. A kiedy mówimy, że jakość jest obowiązkiem wszystkich, dla mnie zaczyna się to właśnie od nich. To oni są w pierwszej kolejności odpowiedzialni za jakość i testowanie wszystkiego.

Dlatego pojawił się ten pomysł, a przynajmniej ta nazwa, ponieważ wszyscy wiedzą, że od teraz musimy przekonać najwyższe kierownictwo i w jakiś sposób zaangażować je w działania. Dla mnie to warunek wstępny. To nie jest coś, co robimy w połowie procesu. To pierwsza rzecz, którą musimy zrobić, zanim zaczniemy się zastanawiać, gdzie możemy umieścić najlepsze obszary testowania. 

A potem rozpowszechnić, ponieważ samo przekonanie hierarchii, najwyższego kierownictwa czy dyrektorów generalnych nie wystarczy. Trzeba z nimi współpracować, aby rozpowszechnić jakość w całej firmie i stworzyć kulturę jakości oraz sposób myślenia oparty na jakości. Jeśli projekt zakończy się niepowodzeniem albo pojawi się ogromny błąd — na przykład w mediach społecznościowych — zespoły, które nad nim pracowały, nie pozostaną tam. Nikt nie będzie pamiętał osoby, która pracowała nad tym nieudanym projektem, ani tego, co spowodowało błąd. Zapamiętana zostanie nazwa firmy. Dlatego ważniejsze jest coś więcej niż tylko stwierdzenie, że za jakość odpowiadają projekt i zespoły — odpowiadają za nią wszyscy.

QAL

Czyli chcecie wejść do firmy i zmienić całą kulturę biznesową oraz sposób myślenia w biznesie?

Iman Benlekehal

Dokładnie. Testowanie jest tylko działaniem. To zaledwie ostatni element jakości. W przypadku jakości trzeba opracować strategię i zastanowić się, jakie kryteria należy uwzględnić w tym projekcie wraz z użytkownikami. Jeśli na przykład użytkownik potrzebuje wysokiej wydajności, do przetestowania tej wydajności potrzebujemy narzędzia, a zdarza się, że jest ono bardzo, bardzo drogie. Załóżmy, że nie uwzględniono go w budżecie i nie przeznaczono na nie żadnych środków. W rezultacie znów pojawia się ono zbyt późno.

Tak, musimy testować wcześniej, ale musimy też wcześniej się zaangażować oraz zrozumieć jakość i kryteria jakości — myślę, że obecnie jest ich 10 zgodnie z normą ISO 25010. Użytkownicy muszą wyrazić swoje potrzeby w odniesieniu do wszystkich tych kryteriów, a najwyższe kierownictwo musi zrozumieć, dlaczego te kryteria są tak ważne. 

Gdy już to zrobimy i zrozumiemy wszystkie zagrożenia, możemy testować. TDD i wszystkie te metody są świetne i bardzo ważne. Nie twierdzę, że nie rozwiązują żadnych problemów, ale wiele problemów można rozwiązać jeszcze przed rozpoczęciem testowania.

QAL

Czyli dzieje się to przed opracowaniem strategii testów i modelowaniem?

More Articles

Iman Benlekehal

Tak. Na przykład w niektórych projektach kierownik projektu cieszy się, że jestem w jego zespole. Mówią: „Dobrze, mamy Iman, zajmie się strategią testów”. Odpowiadam: „Świetnie. Czy możecie włączyć nas do rozmów z klientem, abyśmy mogli przedstawić mu strategię?” Zwykle się na to zgadzają. Wydaje się, że rozumieją tę filozofię i pozwalają mi porozmawiać z klientem. To idealna sytuacja. Jednak w następnym tygodniu kierownik mówi: „Dobrze, oszacowaliśmy twój budżet”. Pytam wtedy: „Kto oszacował budżet potrzebny zespołowi QA na jego działania?” 

Nie rozumieją, że nie chodzi tylko o teorię, która mówi, że musimy być zaangażowani w każdy aspekt. Trudno im zmienić sposób myślenia i zrozumieć, że testowanie i jakość nie są po prostu odsetkiem pracy programistów. Wydaje mi się, że przyjmują 40% szacunków. Nie jest jeszcze odruchem, aby zwrócić się do QA jako ekspertów i powiedzieć: „Dobrze, oto projekt — nawet jeśli nie ma w nim zaangażowanego zespołu QA — co o nim sądzicie?”

Dzięki naszemu doświadczeniu możemy wskazać, czego naprawdę chciał klient. Lubię czytać między wierszami i mówić: „Dobrze, powiedział to, ale w rzeczywistości oznacza to właśnie to, to i to. Zadaj mu to pytanie, a zobaczysz”. I właśnie to mogą wskazać eksperci ds. jakości lub doświadczeni ludzie, którzy pracowali w wielu, wielu sektorach. Ważne jest, aby pomóc zrozumieć to także najwyższemu kierownictwu i osobom zarządzającym projektami.

QAL

Dobrze, rozumiem! Z niecierpliwością czekam na to, jak projekt będzie się rozwijał z Jonathonem jako waszym nowym mentorem. Dziękuję za poświęcony czas. Mam jeszcze tylko jedno pytanie: czy masz jakieś rady dla osób, które dopiero zaczynają karierę w testowaniu, dotyczące tego, jak powinny podchodzić do swojej roli, rozwoju zawodowego lub czegokolwiek innego?

Iman Benlekehal

Nadal zadawaj pytania i nie bój się, gdy ludzie mówią ci „nie, twoja część, twoja rola jest tam, na końcu.” Nie. Testerzy QA mają do odegrania ogromną rolę. Nie zajmują się tylko testowaniem lub wykonywaniem, ale muszą także pomagać ludziom wzajemnie się rozumieć i dbać o to, abyśmy mówili tym samym językiem oraz dążyli do tego samego celu. W ciągu najbliższych dziesięciu lat technologie będą się rozwijać, a ludzie będą mniej potrzebni do faktycznego testowania, jednak filozofia testowania pozostanie i nadal będzie bardzo potrzebna.

Ucz się dalej i posłuchaj tego podcastu: POKOLENIE AUTONOMICZNEJ AUTOMATYZACJI I JEGO OBLICZE (Z BERTOLDEM KOLICSEM Z MABL)

You may also like