test objects design

StickyMinds.com :Bolton : Test Patterns

“In this column I’ll summarize the HTSM’s nine categories of techniques for testing systems. Notice the term “systems” rather than “programs.” The former, more general term allows flexibility in modeling what we have to test, from a single line of code to a functional module, an application, or a suite of interacting applications and the platforms on which they work. The scope of the effort affects the techniques we choose and the ways in which we use them.(…)

I’ve noted in previous columns that coverage is the extent to which we’ve tested the system according to our mental models. Each test technique in the HTSM affords us a different way of modeling the product. Each technique is a heuristic—a fallible method for solving testing problems. No single technique can reveal all of the information that we seek about a system, but a variety of techniques will reveal more bugs—and more varieties of bugs”

Reading a paper “Removing Requirement Defects and Automating Test” posted on stickyminds.com from Mark Blackburn of T-VEC (from in PDF format)

Quotes from the PDF file

Verification Model Development: “A ‘pure’ requirement model specifies the requirements in terms of logical entities representing the environment of the system under test, where as, a verification models specifies requirements in terms of the interfaces for the system under test; a design engineer typically defines the interfaces. This is analogous to the way a test engineer develops tests in terms of the specific interfaces as opposed to logical concepts of the environment for the system under test. SCR is a table-based modeling approach”

Process Roles and Flows: “the typical organization roles: 1) a requirements engineer performs requirement analysis, 2) a designer/implementer develops    system/software architecture, design and implementation, and 3) a test engineer performs verification,    including testing, analysis and reviews, and some validation. Any person on the team may perform    one or more roles. Requirements are typically recorded textually and are sometimes supplemented    with graphics, tables or formalized models and algorithms. The requirements typically pass to the    system designers and testers as documents that can include Software/System Requirement    Specifications (SRS), function lists, or change requests.

The key change to a typical process is the introduction of verification models. These models support automated means of identifying model defects and generating tests highly effective in verifying a system is consistent with the model. (…)

This approach has been effective in many organizations not already developing rigorous models. Other successful approaches have involved requirements engineers or designers using existing modeling tools or adopting new tools, such as MATRIXx, ObjecTime, or Statemate to develop models that support both development, validation and verification. This paper highlights a process in which testers develop models to support verification in SCR (Software Cost Reduction). SCR, and the associated SCRtool developed by the Naval Research Laboratory, have been used in a variety of industrial applications to model system and software requirements”

chris blogs: Announcing test/spec 0.3, a BDD interface for Test::Unit

What is test/spec?

test/spec layers an RSpec-inspired interface on top of Test::Unit, so you can mix TDD and BDD (Behavior-Driven Development).

test/spec is a clean-room implementation that maps most kinds of Test::Unit assertions to a ‘should’-like syntax.

I think for test design I will stick with Rspec. It closely relates to my pseudo code and TestObject modeling.

FAQ - Watir - How do I create an Application\Object Map?

FUNTOM maybe the answer - Functional Test Object Model. - Create FUNTOM of your application. Put Watir implementation in FUNTOM Classes.

Tom and Mary Poppendieck on Agile Toolkit.

Another aspect of respecting people is the idea that the process that the team uses to generate value is owned by the team. Processes are what the team uses to achieve its goals.
It rapidly morphs into a situation  where the team is the tool that the process uses to achieve its goals. That’s rather disrespectful of the individuals involved.

Foundations for software engineering - AC

The key in transferring lessons from manufacturing to engineering is to recognize that the “unvalidated decision” is the unit of inventory in engineering (or cooperative games of invention and communication in general)

…
Replace manufacturing’s flow of materials with engineering’s flow of decisions, however, and the rules governing the two are remarkably similar. One remaining difference is that the flow of decisions in an engineering project has loops (requests for validation and correction), which designers of manufacturing lines try hard to avoid. These loops complicate the optimal strategies for the team but do not change the rules of the situation

…

• The users and sponsors make decisions about what they want.
  They feed those decisions to UI designers and business analysts (BAs).

• The UI designers and BAs, collaboratively with the users or on
  their own, make detailed decisions about the appearances, behaviors,
  and data to be put into the system. They feed those decisions to the
  programmers.

• The programmers make decisions about the program. Those
  decisions probably change some of the users’ requests and the decisions
  made by the UI designers and BAs, but let’s skip that topic for the
  moment. However they make their decisions, those decisions go to the
  testers.

• The testers make decisions about where the foregoing people have made mistakes (note: bolding mine. Yes, I am a tester) .

The testers can’t tell whether the program is correct until they get
running code; the programmers can’t know what to code until the UI
designers and BAs make their detailed choices; and the UI designers and
BAs can’t decide what to request until the sponsors and users make up
their minds.

As with manufacturing, there is “inventory,” there are
“work-in-progress” queues between work stations, and there is the
problem of selecting batch sizes for those handoffs.

The engineering team’s inventory is made up of unvalidated
decisions. The more decisions saved up and passed from one person to
another at one time, the larger the batch size involved in that handoff

FUNTOM as opposed to PHANTOM.

FUNTOM:

Functional Test Domain Model. see. phantom (work in progress)

PHANTOM (also FANTOM):

noun. 1) a) Something apparently seen, heard, or sensed, but having no physical reality. 2) An image that appears only in mind; an illusion.

Cockburn on AgileToolkit podcast

Frequent Delivery (distinguish frequent, distinguish delivery)

Close Communication (Osmotic communicaiton. The speed of the project is related to the speed at which ideas move between minds)

Reflective Improvement (Review the working habits and keep it, alter it or discard it. What new things can we try).

Today I discovered a new feature to add to my jEdit setup for Ruby. The SuperAbbr plugin. Excellent addition. I already use Abbreviations, a jEdit built in feature but this new plugin is impressive because it introduces markers in a block of code so with tag you can jump to and fill in the blanks so to speakHere is a nice tutorial I found at this site
I must say I use jEdit every day as my main text editor and viewer for all types of files, not only Ruby code. And it’s my main tool for text search and replace using regular expressions. (p.s. Greg Merrill, one of the authors of XSLT plugin for jedit, introduced me to Jedit few years back when we worked on a project together)

## Ruby example for John
# Initializing instance variable on superclass. 
# class B is a subclass of A and inherits attribute a from superclass. 
# Then in B we add attribute b.

class A
  attr :a, true
end

class B < A
  attr :b, true
  def initialize(a,b)
    @a = a
    @b = b
  end
end

a = A.new
a.a = "value a for object a"
b = B.new("value a for object b", "value b for object a")
puts b.a
#b.b = "b"

puts "b.b is " + b.b
puts "b.a is " + b.a
puts "a.a is " + a.a

=begin
PRINTOUT WILL BE
value a for object b
b.b is value b for object a
b.a is value a for object b
a.a is value a for object a
=end