Even as my work life keeps me busy, I try to keep up with at least some of what other product developers are writing about Agile development and testing. Two of my favorite sources are InfoQ and Stickyminds. You can find them online (at InfoQ.com and Stickyminds.com) and on Twitter. InfoQ recently released a couple of interesting podcasts on pair programming and diversity in tech (check them out here and here if you’re curious). Stickminds released their ‘top ten testing articles for 2016’ at the end of the year and there were a couple that stood out to me. One was on how testing is different in an Agile development environment than in other contexts (read it here if you’d like). The other one addressed key things to keep in mind when creating test plans. I wanted to summarize what struck me most below.

The article by Terry Wiegmann talks about the NEBS framework, which suggests that tests should examine, “Normal conditions (what should happen), Error conditions (what could go wrong), Boundary tests (maximum and minimum values), and Special tests (situations that have not been tested before).” Terry goes on to discuss how a team she worked with applied these ideas to verify not just that the ‘happy path’ worked but also that reasonable problem scenarios were tested and coded for. Terry also expanded the N in NEBS beyond “Normal” conditions to include examining what is “not supposed to happen” or testing “Negative” conditions.

The testers on the Agile teams I work with do work that is frequently outstanding; their persistence in stressing “Special tests” and their creation of thorough regression tests to automatically verify “Normal” conditions have contributed to growing confidence in the reliability of our products. I’m eager to get their thoughts on adding “Error” and “Boundary” conditions to the ways they script the test suite. I’m also continually glad to run across great material from other Agile practitioners like Terry and the folks from InfoQ and Stickyminds so that we can learn from each other. There’s a lot of ways to improve as we build on each other’s areas of expertise. We need each other’s insights because in truth, it’s not that simple.