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.
In this blog post, Mark Prichard presents a solution on how to use Jenkins to give a “QA dashboard” view of a native Android application build. His goals were to show metrics for the results of unit test and code coverage in an Android build context on the Jenkins continuous integration system.
In this blog post, Jonathan Kohl discusses the similarities between software testing and game playing. He defines a game as a “situation involving cooperation and conflict with different different actors with different motivations and goals”. He sees software testing as an individual pursuit within a larger software development game and with two styles: scripted testing and exploratory testing..
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