This blog post discusses how a Test-Driven Development approach can coexist with good design requirements when a system wants to evolve. Can we just refactor or do we need to think more about design in the first place? Evolution of code and design could depend on the programming language and design granularity.
Programmers use Coding Dojos to exercise their programming skills in a group setup. Deliberately they get together to pair program and get feedback from peers. But how do testers train their skills? Testing Dojos provide a similar setup as Coding Dojos, but help testers to practice their individual skills in a group. This web site is a reference for everything about Testing Dojos. http://www.testingdojo.org/
An interesting posts about how a tester collaborate with the product owner in an agile team to define the acceptance tests.
“Would you trust a programmer to test your application? It’s like asking a Fox to guard the chicken-house, right?” This is the beginning of this post that deals with the issue of having programmers testing their own code.
Selenium is an open source project with no formal guidance, making problem investigation time-intensive for testers. This article provides best practices for common issues during testing based on Selenium 1.0, which was released in June 2009.
Many of the most common problems people have with implementing BDD or agile acceptance testing come from a misalignment of conceptual models. By changing our view at the specifications/tests we can make most of those issues go away instantly. This post explains the principle of symmetric change: one small change in a business model should require one small change to executable specifications.
This website presents a list of open source and commercial continuous integration tools. http://www.continuousintegrationtools.com/
Copyright © 2009-2025 Software Testing Magazine by Martinig & Associates