Categories
Allgemein

Software Testing

Software testing is an investigation conducted to provide stakeholders with information about the quality of the software product or service under test.

Testing Levels

Unit testing

Unit testing refers to tests that verify the functionality of a specific section of code, usually at the function level.

These types of tests are usually written by developers as they work on code, to ensure that the specific function is working as expected. One function might have multiple tests, to catch corner cases or other branches in the code. It is performed by the software developer or engineer during the construction phase of the software development life cycle. Unit testing aims to eliminate construction errors before code is promoted to additional testing; this strategy is intended to increase the quality of the resulting software as well as the efficiency of the overall development process.

Unit testing alone cannot verify the functionality of a piece of software, but rather is used to ensure that the building blocks of the software work independently from each other.

Integration testing

Integration testing is any type of software testing that seeks to verify the interfaces between components against a software design. These types of tests are also written by developers.

Integration testing works to expose defects in the interfaces and interaction between integrated components (modules). Progressively larger groups of tested software components corresponding to elements of the architectural design are integrated and tested until the software works as a system.

Integration tests usually involve a lot of code, and produce traces that are larger than those produced by unit tests. This has an impact on the ease of localizing the fault when an integration test fails.

System testing

System testing tests a completely integrated system to verify that the system meets its requirements. For example, a system test might involve testing a login interface, then creating and editing an entry, plus sending or printing results, followed by summary processing or deletion (or archiving) of entries, then logoff.

System testing tests not only the design, but also the behavior and even the believed expectations of the customer. It is also intended to test up to and beyond the bounds defined in the software or hardware requirements specifications.

System testing – Manual Testing

For small scale engineering efforts, exploratory testing may be sufficient. It seeks to find out how the software actually works, and to ask questions about how it will handle difficult and easy cases. The quality of the testing is dependent on the tester’s skill of inventing test cases and finding defects. The more the tester knows about the product and different test methods, the better the testing will be. The documentation of exploratory testing ranges from documenting all tests performed to just documenting the bugs. During pair testing, two persons create test cases together; one performs them, and the other documents.

System testing – Test automation

Test automation may be able to reduce or eliminate the cost of actual testing. A computer can follow a rote sequence of steps more quickly than a person, and it can run the tests overnight to present the results in the morning. However, the labor that is saved in actual testing must be spent instead authoring the test program.

Acceptance testing

Formal testing with respect to user needs, requirements, and business processes conducted to determine whether a system satisfies the acceptance criteria and to enable the user, customers or other authorized entity to determine whether to accept the system.

•             User acceptance testing

•             Operational acceptance testing

•             Contractual and regulatory acceptance testing

•             Alpha and beta testing

Continuous testing process

Continuous testing is the process of executing automated tests as part of the software delivery pipeline to obtain immediate feedback on the business risks associated with a software release candidate. Continuous testing includes the validation of both functional requirements and non-functional requirements.

The scope of testing extends from validating bottom-up requirements or user stories to assessing the system requirements associated with overarching business goals.

Links:

https://en.wikipedia.org/wiki/Exploratory_testing

https://en.wikipedia.org/wiki/Software_testing

Categories
Desires

Agile setup

Spirit

  • talk, ask, doubt
  • four-eyes principle
  • burn with passion for your product
Categories
Allgemein

Projekte steuern

Projektmanagements operiert mit drei sich gegenseitig beeinflussenden zentralen Faktoren

  • Zeit,
  • Kosten und
  • Leistung

Werden diese Faktoren nicht im Sinne des Auftraggebers erfüllt, ist der Typ des Projektmanagements zu prüfen.

Klassisches Projektmanagement

Dieser Ansatz eignet sich gut für Projekte mit klaren, stabilen Anforderungen und einem geringen Maß an Unsicherheit.

Die fünf Phasen eines Projektes werden in der Regel streng sequenziell durchlaufen. Eine Phase muss also weitgehend abgeschlossen sein, bevor die nächste beginnt. Der Schwerpunkt liegt auf einer detaillierten und vollständigen Vorabplanung, die während der Durchführung möglichst exakt umgesetzt werden soll. Änderungen am einmal festgelegten Plan sind unerwünscht, oft aufwendig und werden über formale Change-Request-Prozesse gemanagt. Die Überwachung konzentriert sich stark auf die Kontrolle der Einhaltung des ursprünglichen Plans.

Agiles Projektmanagement

Agilität eignet sich besonders gut für Projekte mit sich ändernden Anforderungen, hoher Komplexität oder großer Unsicherheit.

Agile Ansätze arbeiten iterativ und inkrementell. Auch hier gibt es eine Initialisierung (z. B. Produktvision, initiales Product Backlog) und einen formalen Abschluss (z. B. Release), aber die weiteren Phasen verschmelzen und wiederholen sich in kurzen Zyklen (Iterationen oder Sprints, typischerweise 1–4 Wochen). In jedem Zyklus wird ein kleiner Teil des Gesamtprodukts geplant, entwickelt, getestet und den Stakeholdern präsentiert (Review), woraufhin Feedback eingeholt wird. Die Planung ist adaptiv und erfolgt fortlaufend; das Backlog wird regelmäßig angepasst. Die Überwachung findet fast täglich (z. B. Daily Scrum) und am Ende jedes Zyklus (Sprint Review, Retrospektive) statt.