|
Refactoring Your Wetware: Thinking Differently About Thinking (Part 1) Software development happens in your head-not in an editor, IDE, or design tool. We're well educated on how to work with software and hardware, but what about wetware--our brains? Join Andy Hunt for a look at how the brain really works (hint: it's a dual-processor, shared bus design) and how to use the best tool for the job by learning to think differently about thinking. Andy looks at the importance of context and the role of expert intuition in software development. Learn to take advantage of pole-bridging and integration thinking. Compare different laterally-specialized functions, including synthesis vs. analysis and sequential processing vs. pattern-matching. Go back to work with new techniques for harvesting your internal clues as you discover one simple habit that separates the genius from the "wanna-be."
|
Andy Hunt, The Pragmatic Programmers
|
|
From Here to Acceptance Test-Driven Development Acceptance test-driven development (ATDD) means different things to different people based on their experiences—from "It's all about testing" to "It has nothing to do with testing,” and from "TDD, ATDD—it's all the same" to "TDD and ATDD are nothing alike." These nine landmarks will help you navigate ATDD no matter where you are coming from.
|
|
|
It's in the Way That You Use It Rapid testers don't think of test automation merely as something that controls a program and checks for some expected result. Instead, we think of test automation as any use of tools to support testing. With that definition in mind, it may not be the most obvious automation tool that is the most useful.
|
|
|
Agile Testing as if People Mattered As a test professional in waterfall, I was used to getting the code much later and buggier than I expected and being under tremendous pressure to finish my testing before the go-live date hit. Then one day, I found out that there was a better way. Testers could be involved much earlier in the lifecycle, they could participate in requirements and design decisions as they happened, and the code could actually be unit tested before I received it! Heaven? Nope, agile.
|
|
|
Does Exploratory Testing Have a Place on Agile Teams? Exploratory testing—questioning and learning about the product as you design and execute tests rather than slavishly following predefined scripts—makes sense for many projects. But does it make sense for agile projects? In this column, Johanna Rothman examines how exploratory testing might work on an agile project.
|
|
|
Programming with GUTs Because tests are commonly viewed in terms of offering quantitative feedback on the presence or absence of defects in specific situations, Good Unit Tests need to both illustrate and define the behavioral contract of the unit in question. Do you have GUTs?
|
|
|
Two Cheers for Ambiguity Some people dismiss words such as skill, diversity, problems, and mission as being too ambiguous to be useful. But one tester's ambiguity is another tester's gauge for assessing consensus on a project and how to achieve that consensus.
|
|
|
Give Your Defects Some Static Computer security has raised the demand for automated tools that can analyze source code for vulnerabilities and defects. Find out how you can put automated static analyzers to work for you.
|
|
|
Stop The Insanity! Using Root Cause Analysis to Avoid Repeating Your Mistakes We've all heard Einstein's definition of insanity, and it definitely holds true in software development. We "are" going to make mistakes in product development, but root-cause analysis can help us understand those mistakes and be proactive in not repeating them.
|
|
|
Know Where Your Wheels Are Drawing from his experiences while learning to drive, Michael applies lessons he learned from written rules, experiential learning, and the advice of mentors to teaching new testers some valuable skills.
|
|