Zuallererst sollten wir wissen, was eine Baseline ist, bevor wir verstehen, was Baseline Testing ist.

Technisch gesprochen –

Eine Baseline ist ein formales Dokument, das als Basisdokument für zukünftige Arbeiten dient. In Laiensprache ausgedrückt: Um ein Gebäude zu errichten, benötigt man eine Basis. Das Gleiche gilt für den Test. Wir müssen eine Baseline erstellen, von der aus die weiteren Tests durchgeführt werden. Zunächst einmal ist es sehr wichtig zu wissen, dass es sich um ein nicht-funktionales Testen handelt, was bedeutet, dass es nichts mit dem Testen der Funktionalität einer Anwendung zu tun hat. Vielmehr wird das Dokument getestet, das eine solide Grundlage für die künftige Arbeit bildet. Man kann also sagen, dass es als Grundlage für die künftige Entwicklung dient, was auch immer es ist. Es kann die Leistung oder die Entwicklung von Testfällen sein.

In Bezug auf Leistungstests –

Wenn man sieht, dass die Leistung der Anwendung eines bestimmten Servers mit einer Last von 100 Benutzern gut funktioniert, ohne Unterbrechung oder Verlangsamung oder Zusammenbruch, und danach die Leistung des Servers drastisch abnimmt, nachdem eine Last von mehr als 100 Benutzern auf den Server, der die Anwendung enthält, angewendet wird. Dann können wir sagen, dass der Standard für diesen Server 100 Benutzer ist. Nun kann dieser Standard mit dem Standardserver verglichen und der künftige Umfang der Leistungstests festgelegt werden.

Lassen Sie uns dies anhand eines anderen Beispiels verstehen: Nehmen wir an, dass Version 1 eine Antwortzeit von 2 Sekunden hat und Version 2 eine Antwortzeit von 3 Sekunden. Für Release 3 dient die Antwortzeit von 2 Sekunden von Release 2 als Grundlage oder Basis für die Leistung von Release 3. Daraus können wir ableiten, dass Baseline ein Dokument ist, das als Vergleichsbasis oder Referenz für zukünftige Arbeiten herangezogen wird. Es muss ein Dokument geben, das als stabiles, abgeschlossenes Dokument für zukünftige Arbeiten herangezogen werden kann.

Wenn wir von Softwareentwicklung sprechen –

Wenn wir von Softwareentwicklung sprechen, gibt es ein Dokument, das Design-Dokument genannt wird. Es kann ein Low-Level-Dokument oder ein High-Level-Dokument sein, auf dessen Grundlage die Entwicklungsarbeiten beginnen. Wenn wir vom Testen sprechen, dient ein Dokument, das vom Business-Analysten erstellt wird, der in Kontakt mit dem Kunden steht und für das Abholen der Anforderungen vom Kunden verantwortlich ist, als Bezugspunkt für den Kontakt mit den Testern, um den Entwicklungs- und Testprozess zu starten. Der Business Analyst geht nach der Terminvereinbarung zum Kunden, nimmt die Anforderungen auf und füllt sie in eine spezielle Vorlage ein. Nun bespricht er die Anforderungen mit dem Engagement Manager oder dem Project Management Manager, um die Anforderungen zu testen und ihre Durchführbarkeit zu prüfen. Ist er sich über die Anforderungen nicht im Klaren, bittet er den Entwickler, einen Prototyp zu erstellen, und wenn er zufrieden ist, übergibt er das Anforderungsdokument an den Projektmanager, der die Software-Anforderungsspezifikation erstellt. Ein vom Business Analysten erstelltes Dokument wird als Business Requirement Document oder Functional Requirement Specification oder User Requirement Specification oder Business Design Document oder Business Document bezeichnet, je nach der von der Organisation verwendeten Terminologie. Hier sehen wir also, dass die Anforderungsprüfung durchgeführt wird, um das Anforderungsdokument fertig zu stellen, das als Grundlage für das Designdokument oder den Projekt- und Testplan dient und die Basis für die Softwareentwicklung und -prüfung bildet. Diese Art des Testens wird als Baseline-Test bezeichnet. Bei dieser Art von Tests wird geprüft, ob das erstellte Dokument den Anforderungen entspricht und die Erwartungen erfüllt, oder anders ausgedrückt, wir validieren das Dokument und schließen es ab.

Nachdem die Baseline-Tests abgeschlossen sind und das Dokument zur Software-Anforderungsspezifikation fertiggestellt ist, können wir mit der Entwicklung und dem Testen beginnen. Für das Testen können wir mit der Vorbereitung von Testfällen auf der Grundlage der Anforderungsdokumente beginnen. Der Hauptvorteil der Baseline-Tests besteht darin, dass wir Fehler in den Anforderungen in der frühen Phase des Softwareentwicklungs-Lebenszyklus beseitigen können und so viele Probleme und Aufwände in einer späteren Phase vermeiden können und uns dabei helfen, das Projekt mit einem Minimum an Nacharbeit und weniger Aufwand abzuliefern.

In Bezug auf die Phasen des Softwareentwicklungs-Lebenszyklus –

Wie wir wissen, reduziert mehr Arbeit in der frühen Phase des Softwareentwicklungs-Lebenszyklus zu viel Aufwand in einer späteren Phase. Um zu verstehen, wie wichtig Baseline-Tests sind, müssen wir den Lebenszyklus der Softwareentwicklung ein wenig verstehen. Die erste Phase ist die Anforderungsphase, in der der Business Analyst Informationen vom Kunden sammelt und Anforderungsdokumente erstellt, die je nach der von der Organisation verwendeten Terminologie als Business Requirement Document oder Functional Requirement Specification oder User Requirement Specification oder Business Design Document oder Business Document bezeichnet werden. Anhand des Anforderungsdokuments wird das Anforderungsdokument getestet, was als Baseline-Test bezeichnet wird, und die Anforderung wird fertiggestellt oder wir können sagen, dass die Anforderung eingefroren wird. Sobald die Anforderungen den Anforderungen entsprechen, werden sie in der Analysephase zur Erstellung der Software-Anforderungsspezifikation herangezogen. In diesem Dokument erstellt der Projektleiter, der technische Leiter oder der Systemanalytiker einen Projektplan, in dem er beschreibt, wie das Projekt entwickelt werden soll. Auf der Grundlage des SRS-Dokuments werden Design-Dokumente wie High-Level-Design-Dokumente und Low-Level-Design-Dokumente erstellt, auf deren Grundlage eine weitere Phase des Softwareentwicklungs-Lebenszyklus wie Codierung, Testen und Lieferung durchgeführt wird.

Angenommen, das Baseline-Testing wird nicht ordnungsgemäß durchgeführt und das Business-Requirement-Dokument wird nicht ordnungsgemäß fertiggestellt, dann wird die SRS, die auf der Grundlage des Business-Requirement-Dokuments erstellt wird, nicht ordnungsgemäß sein und das Design-Dokument wird auch nicht korrekt sein, und daher werden alle Aktivitäten der Entwicklung und des Testens nicht den Erwartungen des Kunden entsprechen, da es einen kleinen Fehler bei der Aufnahme der Anforderung geben kann oder die Anforderung nicht ordnungsgemäß als Baseline festgelegt wurde. Daraus können wir ersehen, wie wichtig das Testen der Baseline ist.

Eine wichtige Sache ist, dass es einen Begriff Baseline gibt, der im Konfigurationsmanagement verwendet wird, obwohl die Bedeutung auch dort mehr oder weniger dieselbe ist. Er bezieht sich auf die Versionierung von Dokumenten, wobei die Basisversion des Dokuments abgeschlossen ist und die neue Version des Dokuments pro Softwareanwendungsrelease freigegeben wird. Aber es gibt wenig Konzept der Baseline Testing in Configuration Management, als auch, weil Base Version aller Dokumente, ob es im Zusammenhang mit der Entwicklung, Testen, Web-Design oder jedes andere Dokument in Bezug auf die Software-Entwicklung vorbereitet, muss ordnungsgemäß in Bezug auf Formate und Inhalte überprüft werden, so dass die nächste Version des Dokuments mit weniger Aufwand in bereits richtig formatierten Dokument vorbereitet wird.

Fazit:

Wir sehen also, dass die Baseline-Prüfung von großer Bedeutung ist und dass, wenn und solange das Anforderungsdokument nicht ordnungsgemäß validiert wird oder mit anderen Worten, wenn die Baseline-Prüfung nicht durchgeführt wird, es in der späteren Phase eine Menge Probleme geben wird und der Aufwand für die Lösung der Probleme viel größer sein wird, was nur eine Verschwendung von Aufwand und Zeit ist, und dass neue Anforderungen gestellt werden und alle Phasen des Lebenszyklus der Softwareentwicklung durchlaufen werden müssen, um das Problem vollständig zu lösen. Wir können also sagen, dass Baseline Testing viele Probleme in einem früheren Stadium löst und Kosten, Aufwand und Zeit für die Organisation in der späteren Phase des Software Development Life Cycle reduziert.

⇓ Abonnieren Sie uns ⇓

Wenn Sie kein regelmäßiger Leser dieser Website sind, empfehlen wir Ihnen, sich für unseren kostenlosen E-Mail-Newsletter anzumelden! Melden Sie sich einfach an, indem Sie Ihre E-Mail-Adresse unten angeben:

Viel Spaß beim Testen!!!