In der automatisierten Testumgebung E2E* wurden im Laufe der Jahre viele Technologien zur Entwicklung freigegeben, sowohl vom Flutter-Team selbst als auch von externen Entwickler-Communities, die das Potenzial dieses Software-Entwicklungstools erkannt haben.

Heute wollen wir uns eine von den Entwicklern stammende Technologie anschauen, Maestro.

*(End To End, wobei zusammenfassend der Weg von Punkt X zu Punkt Y der Anwendung als QA aus der Sicht des Benutzers getestet wird).

Über das Automatische Testing in Flutter

Um zu entscheiden, ob wir uns für die eine oder andere Technologie entscheiden, wenn es um die Automatisierung der Testfälle unserer Anwendung geht, müssen wir zunächst verstehen, was genau „Automatische Flutter Tests“ sind.

Mit dem Fokus auf „end to end“ bietet Flutter die Bibliotheken flutter_test und bdd_widget_test. Dies sind Tools, die innerhalb der von uns entwickelten Anwendung platziert werden und vollen Zugriff auf die verschiedenen Widgets, Seiten und Codezeilen haben und uns eine großartige Kontrolle über alles, was innerhalb der Anwendung passiert, geben und die beste Lösung für Unit-Tests in Flutter sind.

Sie bieten auch Kompatibilität mit Cucumber, was unsere Tests dank der dort angebotenen Gherkin-Sprache, für nicht-technische Benutzer viel besser lesbar macht.

Obwohl all dies geboten wird muss trotzdem ein großer Punkt berücksichtigt werden. Und das ist das umfangreiche Wissen, welches der Tester über Flutter, die genannten Bibliotheken sowie Cucumber benötigt. Dies ist meist der größte Berg, den es in Bezug auf die QA in unserem Projekt zu erklimmen gilt.

Und genau hier kommt Maestro ins Spiel

Maestro, Wirksamkeit in der Einfachheit

Geschrieben u.a. auf der Grundlage von Appium, Espresso, UIAutomator und XCTest, werden mit Hilfe des so genannten „Flow“ (der Definition der Schritte des Benutzers in der Anwendung) Testmöglichkeiten angeboten, die sehr einfach und sofort überall ausgeführt werden können, da sie nicht zum Projekt gehören, sondern extern laufen..

Die Ausführung erfolgt über ein .yaml-Format (eine Sprache, die auch für Personen ohne umfassende Kenntnisse technischer Begriffe leicht zu lesen und zu schreiben ist).

Es ist so konzipiert, dass über die verfügbaren Befehle nicht nur jeder auf dem Bildschirm abgespielte Emulator leicht erkennbar ist, ohne dass irgendetwas verknüpft werden muss, sondern auch, dass die verschiedenen, für das Absolvieren der gewünschten Testroute notwendigen, Widgets schnell zu finden sind.

Um die fehlende Kompatibilität mit dem POM- und Cucumber-Modell zu kompensieren, bietet Maestro die Möglichkeit, eine Struktur von verschachtelten Ausführungen zu organisieren, die „Nested flows“ genannt werden. Mit Hilfe des „runFlow“-Befehls, der bei korrekter Verschachtelung die separate Ausführung von Maestro-Dateien ermöglicht, wird die Wiederverwendung von Code und die Möglichkeit, eine leicht verständliche und überschaubare Struktur zu organisieren, erheblich erleichtert.

Ausführliche Informationen über Maestro, seine Vor- und Nachteile

1. Die Einfachheit ist zu einfach

Wenn wir uns mit Maestro beschäftigen, ist auf den ersten Blick erkennbar, dass wir schon alles gesehen haben, was sowohl gut als auch schlecht ist. Auf dieses Thema werden wir im nächsten Abschnitt zurückkommen, weil es vielleicht der größte mögliche Wendepunkt ist.

Funktionen wie die korrekte Implementierung eines Page Object Model, Cucucmber,

Datenbankanbindung und weitere fortgeschrittene Ergänzungen sind mit Maestro nicht möglich, jedenfalls nicht in der gleichen Weise wie es bei den anderen Systemen angeboten wird.

2. Menschliche Sprache

Maestro ist schnell zu erlernen und dank der Verwendung der .yaml-Sprache sind keine fortgeschrittenen Kenntnisse erforderlich. Es bietet auch die Möglichkeit, Befehle mit Javascript auszuführen, was eine interessante zusätzliche Ebene des Tiefgangs bietet.

Dieser einfache Code würde es uns bereits ermöglichen, eine Anwendung auf einem Gerät zu öffnen und einen Tastendruck zu simulieren.

In den oben genannten Bibliotheken wäre dies wesentlich komplexer.

3. Vielzahl an Umgebungen

Es bietet nicht nur Hilfestellung bei der Portabilität von Tests, da es nicht dem Basisprojekt angehört, sondern das Tool erkennt sowohl angeschlossene Geräte als auch simulierte Emulatoren von Android Studio (Android-Geräte) und XCode (IOS-Geräte).

Im Gegenzug für diese Bequemlichkeit verliert Maestro auf der Seite des Testers an Handwerkszeug, da nicht auf Dinge zugegriffen werden kann, die im Basisprojekt vorhanden sind.

Maestro bei WATA Factory

Maestro ist ein Werkzeug, dessen Nützlichkeit und Zukunftsprognose von WATA Factory erkannt wurde. Die Einfachheit der Testentwicklung ist etwas, das man bei anderen Tools nicht sieht, und auch wenn das Tool bei einigen Projekten aufgrund ihrer jeweiligen Komplexität nicht zum Einsatz kommt, steht es dennoch immer im Mittelpunkt, wenn über Automatisches Testing in zukünftigen Flutter-Anwendungen gesprochen wird.

The post Die Zukunft des Automatischen Testing E2E in Flutter: Maestro appeared first on WATA Factory.

Wenn es darum geht, die Softwarequalität und die Testgrundlagen eines Projekts zu definieren, insbesondere bei Webanwendungen, wird die Entscheidung, welche Technologien zur Automatisierung unserer Tests eingesetzt werden sollen, zu einer echten Herausforderung. Dies gilt umso mehr, wenn wir eine Technologie zum Testen unseres Frontends wählen müssen.

Wenn wir uns auf E2E (End-to-End)-Tests konzentrieren, mit denen wir das Verhalten und die Interaktion eines echten Benutzers simulieren, indem wir die Benutzeroberfläche unseres Projekts testen, finden wir bekannte Technologien wie Selenium, Protractor oder Playwright.

Aber wenn es ein Test-Framework gibt, das dank seiner Benutzerfreundlichkeit und seiner Vorteile gegenüber den vorherigen immer beliebter wird, dann ist es Cypress.

Was ist Cypress?

Cypress ist ein Open-Source-Framework für automatische Frontend–Tests von JavaScript-basierten Webanwendungen. Seine Verwendung ist nicht nur auf E2E-Tests beschränkt, sondern ermöglicht auch die Erstellung von Integrations- oder Unit-Tests.

Da es über eigene Assertion-Bibliotheken, benutzerdefinierte Befehle und andere interessante Funktionen verfügt (z. B. ein Dashboard zum Debuggen und Ausführen unserer Tests), hat sich Cypress als vielseitiges Framework erwiesen, das an die Merkmale des modernen Webs angepasst ist.

All dies basiert auf einer Architektur, die von Grund auf neu entwickelt wurde: Sie müssen nicht mit Selenium beginnen.

So können wir mit einem Framework arbeiten, das keine Installation von externen Tools und Bibliotheken erfordert, um mit der Erstellung unserer Tests zu beginnen.

Warum Cypress?

Aufgrund der Entwicklung von Webanwendungen und dem Aufkommen aktueller und moderner JavaScript-basierter Frameworks wie Angular, Vue oder React haben sich auch die E2E-Test-Frameworks weiterentwickelt. In Anbetracht der Vielseitigkeit und Benutzerfreundlichkeit, die Cypress bietet, ist die Popularität, die es seit seiner Entwicklung erlangt hat, zu erwarten.

Ein weiteres interessantes Merkmal von Cypress ist, dass dieses Framework die Logik unserer Tests im gleichen Ausführungszyklus wie die Anwendung ausführt. Unter Cypress läuft ein NodeJS-Prozess, der auf die Ereignisse unserer Anwendung in Echtzeit reagiert, ohne dass wir WebDriver zur Ausführung unserer Tests verwenden müssen.

Cypress erleichtert uns auch die Arbeit bei der Entwicklung von Tests, da man für den Einstieg nur Grundkenntnisse in JavaScript benötigt. Es werden auch Assertions aus anderen bekannten Test-Frameworks wie Chai und Mocha verwendet.

Ein weiterer wichtiger Grund für die Verwendung von Cypress ist natürlich das Dashboard, eine grafische Oberfläche, auf der wir den Prozess und die Ausführung unserer Tests in Echtzeit verfolgen können, als wären wir an der Stelle des Benutzers, so dass wir debuggen können und einen direkten Überblick über die Fehler haben, die in unseren Tests auftreten.

Relevante Merkmale von Cypress

Cypress hat viele Funktionen, die gegenüber anderen Frameworks vorteilhaft sind und die uns bei der Entscheidung helfen können, es als E2E-Testwerkzeug für Webprojekte einzusetzen.

1. Aktueller Stand des Frameworks und Lernkurve

Cypress ist ein modernes und aktuelles All-in-One-Framework mit einer guten Dokumentation, einer aktiven Community und kontinuierlichen Updates.

Es bietet eine schnelle Einrichtung des Frameworks in unserem Projekt, da die Installation schnell erfolgt und nur sehr wenig Konfiguration erforderlich ist. ie Tests sind in JavaScript geschrieben und die Cypress-Bibliothek verfügt über anschauliche und prägnante Befehle

All dies trägt zu einer flachen Lernkurve sowohl für das Entwicklungsteam als auch für das QA-Team bei.

2. Integration (oder nicht) mit anderen Technologien

Cypress erfordert keine Integration von Selenium, da die Architektur von Grund auf neu ist. Im Allgemeinen muss es nicht mit anderen externen Bibliotheken und Frameworks integriert werden, aber wir können es tun, wenn wir die Funktionalität des Frameworks mit bekannten Technologien wie Mocha, Chai oder jQuery erweitern wollen

Es funktioniert auch mit jeder JavaScript-basierten Bibliothek oder jedem Framework, das in einem Browser läuft.

3. Interaktion mit Browsern

Mit Cypress ist die Installation eines Browsers nicht erforderlich, da der Headless Browser (keine grafische Oberfläche) eine schnellere und weniger zeitaufwändige Ausführung ermöglicht. Dadurch wäre es nicht notwendig, einen Browser zu installieren, um die E2E-Tests durch kontinuierliche Integration auszuführen.

Andererseits brauchen wir keinen WebDriver in Cypress auszuführen, da unsere Tests innerhalb eines Browsers durch einen NodeJS-Prozess ausgeführt werden.

4. Automatische Wartezeiten

Bei der Verwendung von Cypress ist es nicht notwendig, beliebige Wartezeiten zwischen Befehlen und Assertions einzufügen, da dies automatisch geschieht, so dass es nicht notwendig ist, wait und async in unseren Tests zu verwenden.

5. Nützliches und einfaches Dashboard

Cypress verfügt über ein einfach zu bedienendes und intuitives Dashboard, mit dem wir zwischen den einzelnen Testschritten interagieren können.

Das Dashboard bietet uns Dynamik, da es nicht notwendig ist, die Tests neu zu starten. Die Änderungen werden automatisch ausgeführt und werden sofort reflektiert, sobald wir den Fortschritt unserer Datei speichern.

6. Lesbare und vielseitige Berichte

Die Ergebnisse der Konsolen- und Dashboard-Tests in Cypress sind sehr anschaulich. Darüber hinaus gibt es viele Optionen für die Berichterstattung über die Ergebnisse unserer Tests sowie die Möglichkeit, auf einfache Weise Screenshots zu erstellen und Videos aufzunehmen.

Cypress bei WATA FACTORY

Bei WATA Factory konzentrieren wir uns darauf, die Qualität unserer Software zu gewährleisten. Daher halten wir es für wichtig, die Testwerkzeuge, die wir in unseren Projekten verwenden, gut zu studieren, und wir glauben, dass die Einbeziehung von Cypress eine aktuelle und optimale Wahl für das Testen unserer auf JavaScript basierenden Webanwendungen ist.

The post E2E-Testautomatisierung mit Cypress: eine elegante und erschwingliche Lösung appeared first on WATA Factory.

In diesem Artikel werden wir über Codeception sprechen, eines der Tools, welches wir zum automatisierten Testing in unseren PHP implementierten Webprojekten verwenden.

Was ist automatisiertes Testing?

Wenn wir im Bereich des Softwaretestens von automatisiertem Testen sprechen, möchten wir erreichen, dass manuelle Tests unbeaufsichtigt ausgeführt werden können, mit Hilfe eines Tools, welches den Prozess automatisch durchführt und verbessert, ohne jedoch den Nutzen des manuellen Testens zu 100% zu ersetzen. Wir berichteten hierüber bereits in einem früheren Artikel.

Wenn wir die Tests so gestalten können, dass sie von einem Computer ausgeführt werden, dann erreichen wir eine kontinuierliche Durchführung der Tests während der Weiterentwicklung der Anwendung.

Warum ist automatisiertes Testing für uns interessant?

Bei WATA Factory sahen wir die Notwendigkeit, diese Art von Tests zu implementieren, da die Entwicklung unserer Projekte neue Funktionalitäten erforderte, die zusammen mit den bereits Bestehenden getestet werden mussten, um die Qualität unserer Produkte weiterhin zu gewährleisten.

Die Automatisierung von Tests bringt eine Reihe von Vorteilen mit sich, mit deren Hilfe das Qualitätsniveau des Produkts erhöht und seine Kosten gesenkt werden, da die Wiederholung von Tests keine große Zeitinvestition in den Phasen der Verbesserung oder Entwicklung des Produkts erfordert.

Einige der Vorteile, die wir in der WATA Factory durch die Implementierung von automatisierten Tests erreicht haben, sind:

• Automatische Überprüfung der Einhaltung der definierten Vorgaben unter Anwendung von BDD (Behavior Driven Development). Einer der großen Vorteile hiervon ist die Nutzung einer gemeinsamen Sprache zwischen Kunden und Entwickler-Team, um somit zu bestätigen, dass das Verhalten des Codes aus Sicht des Benutzers korrekt ist.
• Reduktion der Anzahl von Bugs, da wir sicherstellen, dass sowohl die neue als auch die alte Funktionalität weiterhin korrekt funktioniert.
• Zeitersparnis beim Testen, da wir wiederkehrende Aufgaben vermeiden, und sicherstellen, dass Änderungen in unserem Programm keine anderen Bereiche des Systems beeinflussen.
• die Erstellung von solider Dokumentation.
• Die Teamarbeit einfacher und sicherer zu machen.

Um mit der Entwicklung des automatisierten Testings zu beginnen, informierten wir uns über verschiedene Testing-Frameworks und stießen auf Codeception, welches alles was wir brauchten, in einem einzigen Tool vereinte.

Was ist Codeception und wie kann man es installieren?

Codeception ist ein PHP-Testframework, das zum Ziel hat, lesbare Tests zu erstellen und die Vorgänge aus der Sicht des Benutzers zu beschreiben. Es erlaubt uns, Akzeptanz-, Funktions- und Unit-Tests durchzuführen.

Der Schlüssel zu Codeception ist seine Mitwirkenden (Actors). Codeception versteht Tests als Vorgänge, die von einer Person angestoßen werden. Zusammengefasst kann man sagen, dass ein UnitTester Vorgänge startet und den Code testet, ein FunctionalTester die Anwendung als Ganzes testet, und ein AcceptanceTester interagiert mit der Schnittstelle.

Jeder Actor führt sogenannte Steps aus, das sind einzelne Anweisungen innerhalb eines Szenarios. Die Anweisungen, die ein Actor erzeugen kann, sind in Modulen gruppiert: PhpBrowser,WebDriver, DB, FileSystem, etc.

Zur Installation folgen wir den in der offiziellen Dokumentationbeschriebenen Schritten.

Bei der Installation wird ein Ordner mit dem Namen tests angelegt, und innerhalb dieses Ordners wird eine Grundstruktur für die Codierung der verschiedenen Testtypen erstellt.

Als Beispiel werden wir den klassischen Login testen. Obwohl es in diesem Test noch mehr Szenarien gibt, zeigen wir nur einige von ihnen, um nicht allzu sehr auszuschweifen.

Um den Test zu erstellen, führt man folgenden Befehl aus:

php vendor/bin/codecept g:feature acceptance Login

Dadurch wird eine ‚.feature‚-Datei erstellt, in der wir unsere User Story in einer formalen Sprache namens Gherkin schreiben, mit der Besonderheit, dass wir diese Szenarien als automatisierte Tests ausführen können.

Feature: Login page
Check that the user can access correctly with correct credentials, in other case a warning text is shown.
 
Scenario: User inserts empty password and empty username
   Given I am on login page
   When I fill fields with empty value
     And I click on login button
   Then I see the entered user data are not correct
 
Scenario: Successful access with valid credencials
   Given I am on login page
   When I fill the fields with correct credencials
     And I click on login button
   Then I see Welcome Dummy Name

Szenarien werden Schritt für Schritt unter der Verwendung von GIVEN-WHEN-THEN Kriterien geschrieben.

• Der GIVEN-Teil ist die Vorbedingung für den Test. Von wo aus begonnen wird
• Der Teil WHEN ist das spezifische Verhalten, also die Aktionen, die wir brauchen.
• Und schließlich THEN, der Teil, in dem wir das erwartete Ergebnis erhalten.

Definieren der Tests

Unser nächster Schritt ist die Definition und Umwandlung der Feature-Datei in einen gültigen Test. Sie wird in der AcceptanceTester-Datei definiert.

Um die notwendigen Schritte zu erhalten, wird der folgende Befehl ausgeführt:

php vendor/bin/codecept gherkin:snippets acceptance

Da wir in der Acceptance Suite sind nutzen wir zum implementieren WebDriver als Modul, was uns die Interaktion mit dem Browser ermöglicht. Das bedeutet, dass wir seine Methoden innerhalb der Testerdatei verwenden können, so wie wir es bei den Skripttests tun können, mit

$I->

Man kann verschiedene Methoden verwenden, die bereits entwickelt wurden (z. B. amOnPage oder click). Jeder Schritt des Gherkin-Szenarios wird um die in Codeception definierten Methoden erweitert.

Wir zeigen nun, wie das in unserem Fall umgesetzt werden kann:

/**
 * @Given I am on login page
 */
public function iAmOnLoginPage()
{
 $I->amOnPage('/login');
}

/**
 * @When I fill fields with empty value
 */
public function iFillFieldsWithEmptyValue()
{
 $I->fillField('#username','');
 $I->fillField('#password','');
}

/**
 * @When I fill the fields with correct credencials
 */
public function iFillTheFieldsWithCorrectCredencials()
{
 $I->fillField('#username','correctUsername');
 $I->fillField('#password','correctPassword');
}

/**
 * @When I click on login button
 */
public function iClickOnLoginButton()
{
 $I->click('Login');
}

/**
 * @Then I see the entered user data are not correct
 */
public function iSeeTheEnteredUserDataAreNotCorrect()
{
 $I->see('the entered user data are not correct');
}

/**
 * @Then I see Welcome Dummy Name
 */
public function iSeeWelcomeDummyName()
{
 $I->see('Welcome Dummy Name,');
}

Schließlich führen wir unsere .feature-Datei mit folgendem Befehl aus

php vendor/bin/codecept run acceptance Login.feature --steps 

um zu sehen, dass Given/When/The mit Teilschritten erweitert wird und das erwartete Ergebnis bei der Ausführung angezeigt wird.

Acceptance Tests (2)
-------------------------------------------------------------
Login page: User inserts empty password and empty username Signature: User inserts empty password and empty username
Test: App/Tests/surveys/Login.feature:User inserts empty password and empty username

Scenario -- 
Check that the user can access correctly with correct credentials, in other case a warning text is shown.

Given i am on login page
 I am on url "https://###########/login"
When i fill fields with empty value
 I fill field "#username"," "
 I fill field "#password"," "
And i click on login button 
 I click "LOGIN"
 I wait 5
Then i see the entered user data are not correct 
 I see "the entered user data are not correct" 
PASSED 

Login page: User inserts proper information - Successful access with valid credencials 
Signature: Successful access with valid credencials 
Test: App/Tests/surveys/articulo_test.feature: Successful access with valid credencials

Scenario --
Check that the user can access correctly with correct credentials, in other case a warning text is shown.

Given i am on login page 
 I am on url "https://########/login"
When i fill the fields with correct credencials 
 I fill field "#username","correctUsername"
 I fill field "#password","correctPassword"
And i click on login button 
 I click "LOGIN"
 I wait 5
Then i see welcome dummy name 
 I see "Welcome Dummy Name,"
PASSED 
-------------------------------------------------------------
Time: 19.57 seconds, Memory: 18.00 MB OK (2 tests, 2 assertions)

Dieses Tool bietet uns viele Vorteile, es hat auch eine Anwendung, bekannt als Webception, in der der Kunde alle Tests vom Browser aus ausführen kann und somit in der Lage ist, den Status der Anwendung zu verfolgen.

The post Einführung in das automatisierte Testing mit Codeception in PHP-Projekten appeared first on WATA Factory.

Wir können also kontrollieren, ob der Entwicklungsprozess, die verwendete Architektur oder die eingesetzten Algorithmen einer geeigneten Struktur folgen, einem Muster, welches uns eine einfache Pflege des Produkts ermöglicht.

Was ist SonarQube?

SonarQube ist eines der meistgenutzten Tools, um Codes zu überprüfen, Bugs, Schwachstellen und andere Probleme in unserem Projekt zu erkennen. Es ermöglicht die Analyse eines Codes, der in den gängigsten Programmiersprachen geschrieben wurde (Java, PHP, JavaScript, C#, HTML, etc.).

SonarQube wird als eine weitere Datei in das zu analysierende Projekt integriert, und wenn die Pipeline, in der die Tasks gestartet werden, richtig konfiguriert ist, wird die Code-Inspektion jedes Mal automatisch durchgeführt, wenn wir eine Änderung in irgendeinem Teil des Projekts vornehmen.

Wie man in dem Bild sehen kann ist das typische Szenario, in welcher man die Nützlichkeit am besten verstehen kann, eins mit drei klaren Phasen:

• Entwicklung – Der Code wird von den Entwicklern im Repository aktualisiert. Bevor sie den SonarQube-Dienst mit der Analyse der Änderungen beauftragen, können sie dank des SonarLint-Tools, das in die IDEs integriert werden kann, sofortiges Feedback erhalten.
• CI/CD – Wenn die neuen Änderungen in das Repository aufgenommen werden, prüfen und erstellen die Continuous Integration Tools den Code und führen die Tests aus. Dann wird der SonarQube-Scanner aufgerufen, um die Ergebnisse einiger dieser Tests und den Code als solchen zu analysieren.
• SonarQube-Plattform – Sobald die Analyse des Projekts abgeschlossen ist, werden die Ergebnisse in der Plattform gespeichert und abhängig von den konfigurierten Qualitätsbedingungen können die Teammitglieder informiert werden, wenn sie einen Mangel beheben müssen.

Für die verschiedenen Projekte, die bei WATA Factory, durchgeführt werden, haben wir uns für die Community-Edition entschieden, die frei und Open Source ist. Es gibt jedoch auch kostenpflichtige Alternativen, die die Installation und Wartung des SonarQube-Dienstes durch dasselbe Unternehmen erleichtern. Die Community-Version kann auf zwei Arten installiert werden:

• Lokal – Der Entwickler kann den SonarQube-Dienst auf seinem Localhost einrichten, um seinen Code analysieren zu können, ohne ihn auf einem externen oder entfernten Server hosten zu müssen.
• Remote – Der SonarQube-Dienst wird auf einem Remote-Server gehostet, auf den man mittels vom Dienstadministrator generierter Anmeldeinformationen zugreifen kann.

Je nach Bedarf und Größe des Projekts (Mitglieder, Ressourcen oder Dienstleistungen, die in Anspruch genommen werden müssen) kann man die am besten geeignete Option wählen.

Allgemeine Konzepte

Um ein wenig mehr über die Relevanz der Verwendung dieses Tools zu verstehen, werden wir die allgemeinen Konzepte, welche auf der Plattform erscheinen, detailliert erläutern:

1. Benutzer und Gruppen: Wie in jeder Umgebung können wir Benutzer definieren, die in Gruppen verwaltet werden. Jeder dieser Benutzer verfügt über eine Reihe von Berechtigungen, die ihnen ermöglichen die Analyse eines Projekts anzufordern, falsch positive Ergebnisse der durchgeführten Analyse zu validieren oder sogar zu stornieren.
2. Projekte: Um die Analyse unseres Codes durchzuführen, müssen wir ein Projekt mit den notwendigen Parametern, die unser Softwareprojekt identifizieren, auf der Plattform erstellen. Diese Parameter sollten, abhängig von der Sprache, die wir in unserem Projekt verwenden, auf die eine oder andere Weise angegeben werden. Innerhalb dieser Projekte finden wir die Analyse der einzelnen Projekte, die folgende Daten enthält:
3. Bugs: Fehler im Code, die so schnell wie möglich behoben werden müssen
4. Schwachstellen: Stellen im Code, die offen für externe Angriffe sind und die Integrität und Sicherheit des Projekts gefährden können.
5. Hotspots: Bereiche des Codes, die überprüft werden sollten, um größere Probleme zu vermeiden, sie müssen nicht unbedingt die Sicherheit des Projekts gefährden.
6. Code Smells: Elemente, die den Code unverständlich oder schwer wartbar machen.
7. Abdeckung: Aus den Berichten der ausgeführten Unit-Tests importiert SonarQube die Ergebnisse und zeigt die Abdeckung an.
8. Duplikate: Anzahl der erkannten duplizierten Blöcke, Dateien und Zeilen.
9. Gesamtzeilen: Gesamte Anzahl der Codezeilen im Projekt.
10. Sprachen: Programmiersprachen, die im Projekt verwendet werden.
11. Aktueller Status: Failed/Passed, abhängig von den im zugehörigen Qualitätsprofil festgelegten Werten.
12. Tags: Tags, die dem Projekt zugewiesen wurden.
13. Zeitpunkt der letzten Analyse: Aufzeichnung jeder durchgeführten Analyse.
14. Qualitätsprofile: Sie hängen direkt von den in den Quality Gates festgelegten Bedingungen ab, welche die Regeln angeben, die in jeder der in SonarQube verfügbaren Sprachen befolgt werden müssen. Die Bedingungen der Qualitätsprofile spiegeln die Grenzen der Mindestabdeckung, der duplizierten Zeilen, des Sicherheitsindex oder des Wartbarkeitsindex wider.

Wie wir sehen können, sind der Bericht und die generierten Informationen sehr umfangreich, was uns einen sehr genauen Überblick über den Status unseres Projekts ermöglicht.

Bei WATA Factory haben wir mit SonarQube ein weiteres Werkzeug etabliert, welches die Verbesserung der Codequalität und auch ein indirektes Lernen bei den Entwicklern ermöglicht. Denn mit jedem der Berichte lernt man, welche schlechten Praktiken zu vermeiden sind und wie man sie mit den Vorschlägen, die das gleiche Tool anbietet, dank der in den Quality Gates definierten Regeln lösen kann In zukünftigen Artikeln werden wir sehen, wie wir unser Projekt konfigurieren, um es mit SonarQube automatisch aus einer Pipeline heraus analysieren zu können.

The post SonarQube: Wie man die Qualität des Codes während eines CI/CD-Prozesses gewährleisten kann appeared first on WATA Factory.

Wie wir bereits in einem früheren Artikel gesehen haben, gibt es innerhalb des Software-Testings zwei verschiedene Arten: manuelle Tests und automatisierte Tests.

In diesem Artikel erläutern wir die Merkmale und die Vor- sowie Nachteile des automatischen Testens in einem Softwareprojekt. Um den Inhalt dieses Artikels zu erarbeiten, habe ich meine persönlichen Erfahrungen mit denen verschiedener Kollegen in unserem Team bei WATA Factory erweitert.

Wir werden die wichtigsten Aspekte aufweisen, die man auf jeden Fall beachten sollte, um den Weg zum Erfolg so einfach und schnell wie möglich zu gestalten.

Merkmale des automatischen Testens

Automatisches Testen ist die Vorgehensweise, welche auf den von Testautomatisierungswerkzeugen entwickelten Prozessen basiert. Eines seiner Hauptziele ist, als Ergänzung zur Verbesserung der manuellen Tests, den Testprozess eines Softwareprojekts zu verbessern.

Mit dem heutigen Stand kann das automatische Testen niemals zu 100% die Vorteile, die uns das manuelle Testen bringt, ersetzen. Die Automatisierung verbessert den Testprozess nur, indem sie Vorteile wie paralleles Testen, automatisches Reporting, Eliminierung von sich wiederholenden Aufgaben für manuelle Tester oder Wiederverwendung von Testszenarien bietet. Aber derzeit kann das Software-Testen eines Projekts nicht vollständig durch automatisiertes Testen allein abgedeckt werden.

Bei dieser Art des Testens liegt die Verantwortung des Prozesses vollständig bei dem ausgewählten Tool und den Skripts, die der Tester für die zu testende Anwendung (Application under Test – AUT) entworfen hat. m Gegensatz zu manuellen Tests können automatische Tests nicht in jedem Bereich angewendet werden. Vor allem lässt die automatische Anwendung gerade bei visuellen und UI-Tests noch viel zu wünschen übrig. Es gibt Projekte, in denen täglich bessere Tools auf Basis von KI entwickelt werden, die es aber trotzdem nicht schaffen, alle gewünschten Ziele zu erreichen.

Anhand dieser Daten können wir die wichtigsten Vor- und Nachteile des automatischen Testens ermitteln:

Vorteile

Im Gegensatz zum manuellen Testen können wir beim automatisierten Testen viele Arbeitsabläufe parallelisieren. Die Planung dieser Abläufe bietet eine Vielzahl von Möglichkeiten, um die Qualität des Produkts zu verbessern. Mit einem höheren Detaillierungsgrad könnten wir sagen, dass uns das automatisierte Testen folgendes bietet:

• Schnelligkeit: Die Ausführungszeit ist kürzer.
• Zuverlässigkeit: mehr Permutationen und Pfade können in der AUT abgedeckt werden.
• Effizienz: mehr Tests werden in kürzerer Zeit ausgeführt und die AUT-Abdeckung wird verbessert.
• Die Tests werden automatisch aus den Skripts ausgeführt.
• Die Tests können in verschiedenen Szenarien wiederverwendet werden.

Nachteile

Andererseits bringt die Anwendung dieser Prüftechnik eine Reihe von Auswirkungen mit sich. Unter diesen ist die Herausragendste die Notwendigkeit, ein technisch besser ausgebildetes Testteam für die Gestaltung der Skripts zu haben. Und wie wir schon erwähnt haben, die Einschränkungen, die wir in verschiedenen Bereichen, wie z. B. bei Benutzertests, beachten müssen. Wenn wir diese Nachteile analysieren, können wir die folgende Auflistung erhalten:

• Die Tester müssen technische Kenntnisse haben, um die Testskripte umsetzen zu können.
• Kann nicht auf alle möglichen Arten von Testungen angewendet werden. Zum Beispiel die visuelle Prüfung.
• Wenn die Skripts nicht korrekt gestaltet sind, können falsch negative Ergebnisseerzeugt werden, die die Zuverlässigkeit der Berichte verringern.
• Wir können Aspekte wie den Grad der Benutzerfreundlichkeit oder wie intuitiv die AUT ist, nicht automatisieren. Dazu benötigen wir den manuellen Test.
• Empfohlen für beständige und langfristige Projekte, aufgrund der zu tätigenden technischen Investition.

Der Einsatz von automatisierten Tests wird in den verschiedenen Bereichen der Software immer häufiger, aufgrund der vielen, sich bietenden Vorteile. Denn trotz der möglichen Nachteile, mit denen wir konfrontiert werden, ist das Ergebnis einer guten Anwendung immer positiv.

Basierend auf all diesen Details, die wir analysiert haben, ist es jedoch notwendig, dass zwei sehr wichtige Aspekte vom automatischen Tester berücksichtigt werden: die Auswahl eines guten Testautomatisierungswerkzeugs und das passende Design der Testskripts. In zukünftigen Beiträgen werden wir erörtern, wie wir diesen Herausforderungen begegnen können und wie wir diese Art des Testens in unseren Projekten implementieren können.

The post Automated Testing: Merkmale, Vor- und Nachteile appeared first on WATA Factory.

Es stellt einen kompletten parallelen Zyklus innerhalb der Softwareentwicklung dar, und dieser Zyklus wird als Software Testing Life Cycle (STLC) bezeichnet.

Innerhalb des STLC können wir zwei verschiedene Arten von Testungen finden: manuelle Tests und automatische Tests. Im Falle von manuellen Tests wird die Tätigkeit zu 100% vom Tester ausgeführt. Und im Falle des automatischen Testens wird nur ein gewisser Anteil dieser Tätigkeiten von einem Tester ausgeführt, während der Rest von Automatisierungswerkzeugen erledigt wird.

Merkmale der manuellen Prüfung

Manuelles Testen ist die am weitesten verbreitete Technik in der Geschichte der Software-Entwicklung. Sie ist die Erste, welche die Anwendung von Tests auf verschiedenen Ebenen ermöglichte: Unit Tests, Integrationstests der Komponenten, User Interface… Doch auch wenn jede Art von Prüfungen mit manuellem Testen durchgeführt werden kann, birgt es auch gewisse Nachteile. Schauen wir uns die Merkmale im Detail an:

Vorteile:

• Das manuelle Testen ermöglicht jede Art von Test. Tatsächlich kann die Qualität auf der Ebene der Benutzerschnittstelle (oder der Benutzerfreundlichkeit) nur durch diese Art von Tests kontrolliert werden.
• Es ermöglicht die Analyse komplexerer Szenarien dank des Erfindungsreichtums, den der Tester während seiner Tätigkeit entfalten kann.
• Das Risiko, ein falsches Negativ-Ergebnis zu finden, ist aufgrund der direkten Interaktion mit dem zu testenden System sehr gering.
• Die Tester müssen keine technischen Kenntnisse haben, um die notwendigen Tests durchzuführen.

Nachteile:

• Die Ausführung der Aufgaben ist aufgrund der Schwierigkeit einiger Szenarien sehr langsam.
• Der Tester muss kreativ, geduldig und mit Eigeninitiative ausgestattet sein, um Situationen zu finden, die die Eigenschaften des Produkts auf die Probe stellen.
• Das Erledigen von Aufgaben nimmt viel Zeit in Anspruch.
• Sehr mühsam aufgrund der manuellen Ausführung aller Schritte, die bei jedem der Tests anfallen.
• Es ist schwierig, den Grad der Testabdeckung zu quantifizieren, den wir mit der Durchführung dieser Art von Tests haben.

Umsetzung in die Praxis

Wir bei WATA Factory können auf eine lange Reihe von Projekten zurückblicken, in denen wir manuelle Prüftechniken implementiert haben, um das Qualitätsniveau unserer Produkte sicherzustellen und zu garantieren.

Jedes Projekt hat unterschiedliche Charakteristiken und die Umsetzung dessen erfordert eine Analyse der Ressourcen sowie Anforderungen, die überprüft werden müssen.. Daher werden beim Start von manuellem Testen folgende Schritte empfohlen:

1. Systemanalyse: Definition der zu testenden funktionalen und nicht-funktionalen Anforderungen.
2. Analyse der verfügbaren Ressourcen: Personal, Ausrüstung, Zeit usw.
3. Planung der zu entwickelnden manuellen Tests: Arten und Ausführungszeiten.
4. Durchführung der Tests.
5. Dokumentation der erzielten Ergebnisse: Fehlerberichte, Ergebnisberichte und analysierte Anforderungen.

Viele dieser Schritte sind im STLC-Prozess üblich, aber im Falle manueller Tests ist ihre Anwendung und Ausführung recht sequentiell.

Deshalb beginnen wir im Rahmen unserer Projekte mit der Anwendung automatisierter Prüftechniken, mit denen es uns gelingt, die Defizite manueller Tests zu verringern und so die Qualität unserer Produkte zu erhöhen.

The post Manual Testing: Anwendung manueller Tests auf ein Software-Projekt appeared first on WATA Factory.