Project Quality
  • Home
  • Blog
  • 18 Narzędzi dla testera
  • Testowanie oprogramowania dla początkujących
  • Kontakt
25 listopada, 2021 przez admin

Shift-left testing, czyli testuj jak najwcześniej

Shift-left testing, czyli testuj jak najwcześniej
25 listopada, 2021 przez admin

Shift-left testing, czyli testujmy jak najwcześniej

Zapewniać jakość możemy, stosując wiele podejść, jednym z nich jest shift-left, czyli próba jak najwcześniejszego zapewnienia jakości.

Poruszając temat kosztu błędu, który znajdziesz we wpisie: https://projectquality.it/koszt-bledu/

Możemy zauważyć, że wraz z wcześniejszym etapem, na jakim zapewniamy jakość, cena kosztu błędu spada.

Tradycyjny model

W tradycyjnym modelu testowania, testowanie najczęściej następowało po developmencie zadania. Tester otrzymuje gotową funkcjonalność/zmianę od programisty, a następnie sprawdza jej działanie.

Takie podejście może powodować różne zagrożenia, jednym z nich może być zbyt duża ilość pracy w zbyt krótkim okresie czasu dla jednego testera co może spowodować opóźnienie wydania aplikacji na produkcję. Często również stosując to podejście, ciężko jest wyważyć, jakie jest odpowiednie ratio testerów do programistów, szczególnie gdy ilość pracy jest mocno zmienna podczas trwania sprintu. Wszystko to może powodować opóźnienia w dostarczeniu nowych funkcjonalności/naprawieniu błędów na produkcję.

Zagrożeniem w tym modelu może być również przypadek gdzie po oddaniu oprogramowania z fazy developmentu do testowania pojawi się defekt krytyczny, którego naprawa może zająć więcej czasu i napisanie samego rozwiązania.

Wszystkie zachowania jak wyżej mogą powodować między innymi niestabilność estymacji i problemy z dotrzymaniem terminów w kontekście dostarczania.

Tradycyjny model:

tradycyjny model zapewniania jakosci

Shift-left, testuj jak najwcześniej

W modelu shift-left większość wysiłku związanego z zapewnieniem jakości jest skierowana na etap, który znajduje się jeszcze przed zaczęciem implementacji. Daje nam to możliwość zapobieganiu powstania defektom, a nie jak w przypadku tradycyjnego modelu ich wykrywaniu.

Prewencja przed powstawianiem defektów w podejściu shift-left może obejmować wiele działań, jest to między innymi statyczna analiza, analiza wymagań, przygotowywanie scenariuszy testowych, analizowanie ryzyk.

Dodatkową różnicą, jaka jeszcze występuje, jest fakt, że programiści muszą brać większą odpowiedzialność za swój kod, ponieważ po fazie developmentu testerzy nie skupiają się już tak bardzo na wykrywaniu defektów. Przewagom jednak w takim scenariuszu jest perspektywa, że praca włożona w aspekt jakości i prewencję przed rozpoczęciem fazą developmentu powinna przynieść zysk w postaci pracy zawierającą mniejszą ilość defektów.

Shift-left testing:

shift-left testing

Shift-left daje nam to korzyści takie jak:

  • możliwość statycznego testowania jeszcze przed zaczęciem implementacji
  • w razie wykrycia defektu koszt jest zdecydowanie niższy.
  • zaprojektowanie testów na wczesnym etapie
  • współpraca ze wszystkimi interesariuszami biznesowymi

Recepta na wszystko – czemu więc shift-left nie jest tak popularnym kierunkiem?

Czemu więc skoro shift-left jest rozwiązaniem dużej ilości problemów związanych z wytwarzaniem software’u nie jest stosowane aż tak często? Czy jest to kwestia przyzwyczajenia do kaskadowego wytarzania oprogramowania?

Z drugiej strony nawet jeśli tester chciałby spróbować wdrażać shift-left to najprawdopodobniej będzie potrzebował zgody od kogoś na wyższym stanowisku (oczywiście zależy to od wielkości projektu), co nie zawsze może być takie proste. Często może wymagać to zmiany na poziomie projektu/organizacji gdzie zmiana kierunku nie zawsze musi być tak dynamiczna.

Mieliście do czynienia z projektem, który stosował podejście shift-left testing, a może z hybrydą testowania na początku i klasycznie po developmencie. Koniecznie dajcie znać w komentarzach.

Każdy tester potrzebuje dobrych narzędzi 💻

Zapisz się do newslettera i poznaj 18 narzędzi które wspierają pracę testera!

Twój dokument już czeka na Ciebie 🎉

Wejdź na swoją skrzynkę e-mail i pobierz dokument „18 narzędzi dla testera aplikacji webowych”

.

Photo by Nick Fewings on Unsplash

Podziel się:

  • Twitter
  • Facebook
Poprzedni wpisTworzenie dynamicznych danych do testów za pomocą Faker'a — Selenide automatyzacja testówNastępny wpis Role w obszarze zapewniania jakości

1 komentarz

#hubiontheRUN pisze:
26 sierpnia, 2022 o 9:07 am

U mnie sprawdza się dodatkowy refinament devlopersko/testerski na którym omawiamy historyjki tu nam najcześciej wychodzą błędy w założeniach od Product Owner biznesu jak i designerów.

Odpowiedz

Dodaj komentarz Anuluj pisanie odpowiedzi

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Ostatnie wpisy

7 zasad testowania w 5 minut8 stycznia, 2022
Role w obszarze zapewniania jakości18 grudnia, 2021
Shift-left testing, czyli testuj jak najwcześniej25 listopada, 2021

Kategorie

  • Automatyzacja testów
  • Kariera testera
  • Narzędzia
  • podsumowanie
  • Produktywność
  • programowanie
  • Quality
  • Testowanie oprogramowania
  • Testowanie oprogramowania podstawy
  • ui
  • Uncategorized
  • warsztaty

Wpadnij na nasze social media

Jeśli jesteś pasjonatem jakości dołącz do naszej grupy!

Polityka prywatności

Rife Wordpress Theme ♥ Proudly built by Apollo13

About This Sidebar

You can quickly hide this sidebar by removing widgets from the Hidden Sidebar Settings.

Ostatnie wpisy

7 zasad testowania w 5 minut8 stycznia, 2022
Role w obszarze zapewniania jakości18 grudnia, 2021
Shift-left testing, czyli testuj jak najwcześniej25 listopada, 2021

Kategorie

  • Automatyzacja testów
  • Kariera testera
  • Narzędzia
  • podsumowanie
  • Produktywność
  • programowanie
  • Quality
  • Testowanie oprogramowania
  • Testowanie oprogramowania podstawy
  • ui
  • Uncategorized
  • warsztaty

Meta

  • Zaloguj się
  • Kanał wpisów
  • Kanał komentarzy
  • WordPress.org