Pour les applications low-code, il n'est pas nécessaire de tester certaines techniques comme l'intégration avec la base de données et la syntaxe d'un écran. Mais vous devez toujours réaliser des tests fonctionnels pour vérifier si vous construisez la bonne méthode. Les tests de bout en bout et les tests non fonctionnels sont parfois importants pour les applications low-code.
Cannegieter parlera des tests low-code à QA&TEST Embedded 2022. Cette conférence se tiendra du 19 au 21 octobre à Bilbao, en Espagne.
Les tests permettent de gérer les risques liés au développement low-code, comme l'explique Cannegieter :
Avec un low-code nous avons toujours des risques liés aux erreurs humaines et aux règles métier complexes. Mais il existe encore un risque supplémentaire car les plateformes à low-code semblent d'une simplicité trompeuse. Il semble que tout le monde puisse construire des systèmes. Et dans certaines situations, c'est vrai ! Mais lorsque les règles métier sont complexes, la base de données est volumineuse et complexe, et lorsque le parcours client demande plusieurs fonctionnalités connexes, des défauts sont désormais introduits. Le risque supplémentaire est que des développeurs inexpérimentés introduisent des défauts.
Selon Cannegieter, les examens techniques et les tests écrans ainsi que les règles métier et la gestion de la base de données peuvent aider à faire face aux risques de développement low-code. Ensuite, c'est à l’équipe de bien connaître la plateforme et de créer les fonctionnalités adaptées afin d’atteindre le niveau de performance et de sécurité voulu.
InfoQ a interviewé Jan Jaap Cannegieter sur les tests concenant les applications low-code.
InfoQ : Quelles sont les principales différences entre "high-code" et "low-code" ?
Jan Jaap Cannegieter: Le high-code est le code de programme tel que nous le connaissons, où les développeurs saisissent le code en utilisant une syntaxe spécifique. Comme C# ou Java. Ceci est très laborieux et sujet aux erreurs. En plus, il n'y a pas assez de développeurs bien formés et expérimentés.
Dans une plateforme low-code, vous construisez une application au moyen d'une interface utilisateur. Par exemple, vous pouvez créer des écrans en faisant glisser et déposer des éléments et vous pouvez créer une logique à l'aide de flux de type processus. Cela semble simple, mais cela peut être très complexe et source d'erreurs.
Nous avons vu quatre générations d'applications low-code. Au début, les applications étaient petites, simples et autonomes. Ensuite, nous avons eu de petites applications sur SAP, Oracle Fusion ou Microsoft Dynamics. Pour finir, la troisième génération était des applications critiques mais toujours petites, elles permettaient ainsi d'offrir des fonctionnalités supplémentaires en plus du système ERP. Avec ces applications, vous n'avez pas de solution de contournement. Aujourd'hui, nous construisons des systèmes de base importants, complexes et critiques pour l'entreprise qui doivent être fiables, sécurisés et conformes. Le niveau de test augmente à chaque génération et dans la quatrième génération, nous constatons que les tests ne sont que légèrement différents des tests d'applications high-code.
InfoQ : Qu'en est-il des fournisseurs de plateformes low-code, quel type de test font-ils ?
Cannegieter: Cela dépend des fournisseurs. Pour les grands fournisseurs de plateformes bien connus, les plateformes fonctionnent bien. Certains fournisseurs proposent également des blocs de construction standard ; ces blocs fonctionnent bien aussi. Mais lorsque vous utilisez des blocs de construction construits par d'autres, vous ne savez jamais quelle est la qualité. Avec autant de plateformes low-code aujourd'hui, certaines plateformes ne sont pas si bien testées.
InfoQ : Que pouvons-nous oublier lorsque nous testons des applications low-code ?
Cannegieter : Le fonctionnement technique de la plateforme, l'intégration au sein de la plateforme et la fonctionnalité standard de la plateforme peuvent être ignorés lorsque vous utilisez une plateforme bien connue et largement utilisée.
Si vous sélectionnez un champ de date et que vous le déposez sur l'écran, vous établissez une connexion avec un champ de base de données. Vous n'avez pas à tester l'intégration avec la base de données, mais je testerais certainement afin de vérifier que la date saisie dans le champ est utilisée correctement dans la règle métier.
Les tests sont importants pour limiter les risques lors du passage en production. Surtout lorsque l'application est critique pour les utilisateurs, vous devez la tester de manière professionnelle, ou lorsque l'application est techniquement considérée comme complexe. Les tests sont toujours une partie importante du développement du système que vous utilisiez du high-code ou du low-code.
Si vous créez des applications simples en utilisant uniquement les fonctionnalités standard de la plateforme ou en utilisant uniquement des blocs de construction standard, n'utilisez pas de high-code. Par ailleurs, lorsqu'il existe une solution de contournement disponible, vous pouvez tester moins ou tester avec des testeurs non professionnels ou des utilisateurs non formés.