test objects design

Stickyminds article by Kenji Hiranabe: Agile Modeling with Mind Map and UML

Requirements gathering–or in an agile context, gathering user stories–is always a challenging phase in software development. There are no standard processes or notations defined, only the understanding that the primary factors that make this phase effective are communication and facilitation skills. In this article, Kenji Hiranabe proposes using mind maps that focus on those primary factors when exploring user wishes. Then he takes this concept one step further and models the results with UML

Brian Marick’s new book “Everyday Scripting in Ruby” is now available. - perhaps a subtitle should be “Just Automate It Already, Will You!?”.

I just lost a note which I was posting here so….hm, what was I trying to say? Ah.. Very specific and small vocabulary.

I just found these words on introduction to BDD:

“BDD relies on the use of a very specific (and small) Vocabulary to minimise miscommunication and to ensure that everyone – the business, developers, testers, analysts and managers – are not only on the same page but using the same words.”

So, I’ve mentioned before (at least to myself and my coworkers) about establishing vocabulary and I am digging more and more this BDD.

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.

Lean Software principle listed at Poppendieck’s site:

Write executable specifications instead of requirements

Take a look at Rspec - framework for BDD; Behaviour Driven Development in Ruby. in Rspec you define examples of behaviour as expectations in a context; which is defined by a set of known objects in a known state.

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