No-code nie znaczy no-test

No-code nie znaczy no-test
Jeśli do tworzenia swoich produktów używasz rozwiązań niewymagających żadnego (lub wymagających niewiele) programowania, to i tak musisz testować - pisze w swoim najnowszym raporcie Forrester.  Platformy low-code i ich testowania na przykładzie ekosystemu Salesforce.

Czym są platformy Low-Code/No-Code?

Ostatnie pół dekady przyniosło rozwój narzędzi programistycznych typu Low-Code/No-Code, które pomagają obejść niektóre z wyzwań stojących przed programistami. Są to narzędzia, które dostarczają szablony, architektury referencyjne i różnego rodzaju półśrodki do ograniczenia pisania kodu od podstaw.

Low-Code wciąż jednak wymaga dużo kodowania. Prostsze jest No-Code, które są platformami zaprojektowanymi tak, by dać nietechnicznym użytkownikom biznesowym możliwość zbudowania funkcjonalności oprogramowania poprzez "wyklikanie" w graficznych interfejsach czy przy użyciu funkcji przeciągnij i upuść. Obie techniki są użyteczne, ale obie mogą być częściowo lub potencjalnie odpowiedzialne za rozwój mniej doskonałego oprogramowania.

Przykładem takiego rozwiązania jest bardzo popularne rozwiązanie Salesforce wraz z całym ekosystem niestandardowych aplikacji, zarządzanych pakietem z AppExchange.

Jak testować Low-Code/No-Code?

Wraz z tak szybkimi innowacjami pojawia się potrzeba skalowalnych testów end-to-end. Ostatni raport Forrestera potwierdza, że organizacje korzystające z platform Low-Code, takich jak narzędzia Salesforce Low-Code, nie mogą sobie pozwolić na ignorowanie zautomatyzowanych testów. Wiele firm nadal stosuje tradycyjne metody testowania - takie jak testowanie ręczne lub rozwiązania oparte na skryptach - podczas gdy mogłyby one włączyć się w nową erę autonomicznych systemów kontroli, które oferują bardziej zautomatyzowane podejście do testowania.

Konsekwencją tego "automatyzacyjnego niedopatrzenia" jest to, że jakość wydań oprogramowania spada, ponieważ nie ma wystarczająco dużo czasu na przetestowanie zmian przed wdrożeniem. Defekty znalezione później w cyklu wydania są prawie zawsze droższe do naprawienia z powodu długu technicznego zaciągniętego przez szybkie wdrożenie. Dług musi być "spłacony" w czasie poprawiania kodu tak jak każdy dług finansowy.

Zgodnie z badaniami prowadzonymi przez firmę Copado zespoły korzystające z automatycznych testów wypuszczały produkty 50% częściej niż te polegające na testach manualnych (średnio 34 razy w roku, w porównaniu do 22 razy w roku). Zespoły korzystające z testów automatycznych o 50% częściej realizują wszystkie plany testowe dla każdego wydania (67% zespołów korzystających z testów automatycznych zgłosiło zakończenie wszystkich testów dla każdego wydania w porównaniu do zaledwie 45% zespołów polegających na testowaniu manualnym).
 
Uważa się, że zbyt często ogranicza się lub całkowicie rezygnuje się z testów automatycznych w obszarze Low-Code. Jeśli mamy zamiar używać Low-Code (a nawet No-Code) do tworzenia aplikacji, to powinniśmy również stosować automatyzację Low-code lub inne autonomiczne metody kontroli jakości do jej weryfikacji.

Źródła:
https://www.forrester.com/report/we-must-address-testing-in-low-code-development/RES162135
https://www.forbes.com/sites/adrianbridgwater/2022/01/12/why-low-code-isnt-no-test/?sh=3d145b322238
https://appexchange.salesforce.com/appxListingDetail?listingId=a0N3u00000PGrVaEAL
https://testerzy.pl/baza-wiedzy/artykuly/automatyzacja-testow-z-no-code-codeless-low-code

To powinno Cię zainteresować