Schlagwort-Archive: testing

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 →

JavaScript Tests mit Karma schnell an den Start bringen

Veröffentlicht am von
2

Schon seit geraumer Zeit gibt es für fehlende Unit Tests in JavaScript keine Entschuldigung mehr. Erstens weil JavaScript mit Sicherheit keine “toy language”, sondern eine ernstzunehmende Programmiersprache ist. JavaScript steuert heutzutage client- und serverseitige  Applikationen, die ohne Wenn und Aber getestet werden müssen. Zweitens existieren auch für JavaScript bereits seit längerem Frameworks, die das Schreiben von Unit Tests vereinfachen und standardisieren. Zu nennen sind hier JSUnit, YUI Test, QUnit, Mocha und Jasmine. Drittens und schließlich sind auch automatisierte Testläufe mit Runnern wie JSTestDriver, YUI Yeti, BusterJS und eben Karma ohne Probleme durchführbar. Der zuletzt genannte Test Runner Karma ist der neueste von allen. Seine Vorzüge werde ich im Folgenden darstellen.

Weiterlesen →