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.
In this article, Andrew Hunter shares his opinion that unit tests and test driven development (TDD) now dominate the types of test that are used in software development. This situation has limited the attention available for other software testing types, such as the integration tests. Thus he asks the question: “Are unit tests overused?“
In this article, Cem Kaner explores the technical concept of software testing coverage and the legal concept of software negligence. The article discusses the idea of complete coverage and the trade-off that software developers have to make when testing software. The main idea is that complete coverage is a misleading concept. “This “completeness” is measured only relative to a specific population of possible test cases”. You might achieve line coverage, but to achieve path coverage, you must test every path through the program and this is an impossible task. The goal of the software tester is to prioritize among tests in a careful way. This means to select the test strategy that could be rationally considered as the most likely to find the most bugs or the most serious bugs. This article has an appendix that lists 101 coverage measures.
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.
Copyright © 2009-2024 Software Testing Magazine by Martinig & Associates