Software Testing Videos and Tutorials: Load Testing, Unit Testing, Functional Testing, Performance Testing, Agile Testing, DevOps
This is not a session about how or why to practice Test-Driven Development (TDD). Based upon research conducted during the first quart of 2012, I will outline the most common objections to TDD and describe in detail, with examples where appropriate, how to refute, avoid or mitigate each of them. The coverage will acknowledge that there are risks inherent to all techniques and will not promote the idea that TDD is some kind of silver bullet.
Martin Flower defines legacy code as code without tests. You test your server-side code, but if you are working on a site with a fair amount of non-trivial JavaScript (ajax call, extensive callbacks, etc.) you really should be testing your JavaScript as well. All the untested JavaScript code we are writing today is, in effect, legacy code, but we can address this with JavaScript unit testing!
Breaking concepts down into logical chunks, tackling them in isolation. Sound familiar? This is how we write tests, but it’s also how a mathematician writes proofs. Exploring the similarities and differences between the two can bring us back to our profession’s mathematical roots.
Traditionally, software testing occurs after the software is written. From a Lean perspective, this is waste because the software needs to be reworked, retested and often reworked again. Instead, Lean says that quality should be built-in to the way of working.
This presentation discusses software testing automation after the fact – or adding Selenium to an existing application. With an existing application, the first step to “doin’ it rite” is to stop doing it so wrong. This talk explains where the bodies are buried when taking an existing Rails application and adding front-end testing after the fact, well after the fact (like a couple of years). What approaches worked, what hasn’t worked and why. Keywords: Cucumber, Jasmine, Rails, Sadness.
This video presents the lessons that a team has learned from having a big code base of Selenium tests for acceptance testing. It covers different ways they have developed to track their tests across different projects and how this has helped them to identify flaky tests.
Unit tests are programmer’s best friend, but relying on them exclusively gives an illusion of overall system integrity. At some level, we need to verify how our components integrate and ensure unexpected behavior does not creep in when we shift the application into the target runtime. It all amounts to whether your application is providing the end user what he or she is really needs (tire swing) instead of what anyone thinks they need. How can we save our users from frustration, keep the fail whale at bay and communicate with stakeholders that the requirements are being met?
Copyright © 2009-2024 Software Testing Magazine by Martinig & Associates