Schlagwort-Archive: testing

Meetup-Interview: Testing mit Postman

Veröffentlicht am von
Kommentar

Am 17. November geht unsere Tech-Meetup-Reihe WUE.tech in die nächste Runde. Unser Torsten „Totti“ Wunderlich wird euch eine eine Einführung in das Testing mit Postman geben. Doch das ist nur der erste Streich … 

… denn in einem Folge-Meetup im Dezember wird er nämlich mit dem Testing aus der Konsole, der Integration von GitHub-Actions und vielem mehr noch tiefer in die Thematik einsteigen.

Doch fangen wir mit dem an, was euch am 17. November erwartet. Dazu haben wir mit Totti gesprochen; u. a. über seine Berührungspunkte mit Postman, über die Herausforderungen des Testens von APIs und über Collections. Aber lest selbst.

Infos und Anmeldung zum Meetup

Weiterlesen →

Unkonventionelles UX-Testing: The User is Drunk

Veröffentlicht am von
8

„Don’t make me think“ – nach dem gleichnamigen Buch von Steve Krug – ist der Claim, der Usability und User Experience seit nun fast 20 Jahren bestimmt. Nutzer wollen nicht nachdenken, wenn sie tagtäglich Produkte verwenden. Die Bedienung soll „intuitiv“ sein und schnell zum gewünschten Ergebnis führen.

Intuitive Bedienung ist jedoch eine der größten Mythen der Produktentwicklung, da die vermeintliche Intuition bei der Verwendung von Produkten fast immer auf vorher erlerntes Verhalten zurückgeführt werden kann. „There really is no user interface metaphor that is truly intuitive“ proklamierte Scott Francis 1994 (The Only Intuitive Interface Is The Nipple). Es gibt keine intuitiven Bedienkonzepte – moderne User Interfaces sind immer eine Mischung aus gewohnter (und damit erwarteter) Methodik und der Anreicherung eben dieser mit neuen Ideen und Konzepten.

Weiterlesen →

mobile dev hint #2 – Use Browsersync for mobile testing

Veröffentlicht am von
1

While testing mobile websites on different devices and browsers, testing time grows exponentially. You need to duplicate click-through movements on all the devices, fill out forms many times and do all the user interaction for too many times. This is where Browsersync starts, it cuts out all the repetitive manual tasks. You can mirror all interactions on your testing devices and you  can integrate Browsersync in your web platform and build tools easily. The CLI usage is simple and developer friendly and the great UI can help the testers to interact with the software live during the testing. Weiterlesen →

Crowdtesting – Wie kann man das nutzen?

Veröffentlicht am von
2

 

Eine Freundin von mir kam neulich ganz erfreut auf mich zu und erzählte mir von ihren ersten Crowdtesting-Erfahrungen innerhalb ihres aktuellen Projekts. Crowdtesting? Was ist das denn? Und wie kann das in der Praxis funktionieren? Von ihrer Begeisterung ein wenig angesteckt, begab ich mich auf die Suche nach diesen Fragen und löcherte sie nochmal ausgiebig, denn auch ich fand das einen äußerst interessanten und zukunftsträchtigen Ansatz. Schließlich dachte ich mir, das wäre doch eigentlich was für ‘alle’ – Praxiserfahrungen zu einem noch recht neuen Testing der ganz anderen Art! Die Ergebnisse hierzu also im folgenden Blogartikel! Weiterlesen →

Go-repro: a rewriting reverse proxy for testing multi-domain setups

Veröffentlicht am von
1

Web applications that span multiple domains come with their very own set of challenges. As requesting resources that cross domain boundaries is a pattern common to many different attacks that threaten the security of websites, browsers restrict such requests to conform to with the same-origin policy: most resources (in particular if requested from Javascript via XHR) may only be requested from the domain that served the requesting web page.

However, as there are also completely legitimate reasons for such requests, various techniques exist for circumventing the same-origin policy, for example JsonP or the modern HTML5 CORS standard (Cross Origin Resource Sharing). While these techniques enable cross-domain web applications, the same-origin policy remains a source for subtle and hard-to-debug issues. Therefore, reproducing this setup in development and testing environments is vital to make sure that potential issues can be caught and fixed early before they hit production.

Weiterlesen →

Unser mobiles Open Device Lab

Veröffentlicht am von
Kommentar

Für unseren Besuch der IPC/webinale Berlin 2015 hatten wir uns etwas Neues ausgedacht – ein mobiles Open Device Lab für die Konferenzteilnehmer. Schließlich bauen wir die mobilen Apps für Louis und Vaillant und machen täglich die Erfahrung, wie wichtig echtes Testen auf echter Hardware ist.

Da wir am Standort Würzburg jüngst erst ein neues Open Device Lab unterstützen, mit der Infrastruktur, wie wir sie auch in echten Projekten nutzen, standen im Grunde alle wesentlichen Ressourcen zur Verfügen, so etwas auszuprobieren. Ein kleiner Text über unser technisches Setup und unsere Erfahrungen damit auf einer Konferenz.

LabUp-Setup Weiterlesen →

Testing your ExtJS 3.4 components with Jasmine

Veröffentlicht am von
2

Developing your own ExtJS components for your application is more fun and results into more resilient code if you write them hand-in-hand with test code. A solid test basis can also facilitate the task of refactoring your software.

Although, test driven development is easy for javascript code, how can ExtJS 3.4 components be tested? Which parts of our components should be tested to accomplish a successful refactoring?
Weiterlesen →

Komprimiertes JavaScript unter Kontrolle: Source Maps

Veröffentlicht am von
Kommentar

Haben Sie schon einmal versucht, den Fehler in Zeile 1 der Datei app.js zu finden, wenn diese Datei aus nur einer Zeile mit einer Zeilenlänge von etlichen tausend Zeichen besteht und weder über vernünftig gesetzte White Spaces noch über Kommentare verfügt? Wartungsfreundlich und gut lesbar ist ein so optimierter Quellcode sicherlich nicht. Zur Hilfe kommt Ihnen hier das Konzept der Source Maps. Weiterlesen →

Laravel 4 – Static or not static. That is the question.

Veröffentlicht am von
6

Als ich das erste Mal das noch zu unbekannte Framework Laravel vor der Nase hatte, sind mir sehr schnell die statischen Zugriffe der API aufgefallen. Wo sich viele qualitätsbewusste Entwickler heutzutage die „und wie soll man das testen“ Frage stellen, stand ich hier vor verschlossenen Türen.

THE PHP FRAMEWORK FOR WEB ARTISANS.

Hier scheint sich Laravel 4 eines uns sehr gut bekannten Design Patterns zu bedienen. Die Rede ist von einer Facade. Jede Klasse welche scheinbar statische Methoden bereitstellt, erbt von einer „Facade“-Klasse. Wenn wir also „Config::get(‚database‘)“ aufrufen, wird eine fast leere Facade benutzt. Diese kennt lediglich ihren Accessor (facadeAccessor = ‚config‘) und erweitert entsprechend die Laravel Facade. Die eigentliche Implementierung der genutzten Methode ist dort also gar nicht enthalten.

Das führt uns zu zwei Fragen:

  • Welche Klasse wird bei dem Genannten nun wirklich aufgerufen?
  • Und woher kennt die Facade augenscheinlich diese Klasse?

Nun dann schauen wir mal genauer hin.

Weiterlesen →