How can we be effective at conducting unit and integration tests with an Agile Development Team?

Stating that tests are crucial to any successful solution implementation, is far from being new. Undertaking quality control is imperative for all product components. However, ensuring quality of a solution requires a testing strategy.

This posting is inspired by comments from Dave Couture - in the discussion of Viewpoints. 

Macroscope embodies a very powerful principle of system ownership by the business. One of the major implications of this principle is to assign key responsibilities to the BSM role - with a supporting team drawn from the business, not from IT.  And Macroscope clearly defines the ideal qualifications of the BSM - deep business knowledge, excellent relationships inside the business - and uppermost - being clearly identified as "from the business", not IT.

As you may have guessed from the previous dialog , the next question on the hit-parade of the most frequent questions is something like: In which deliverable should I document this information? A question generally accompanied by: You would not have a template or an example, by any chance? To make my point, let me be somewhat blunt in my dialog. Th...

The notion of viewpoints advocated by Macroscope in solution delivery integrates concerns of all stakeholders and thus allows to reach a business solution that meets their needs. This is simple and logical.

When I introduce people to the standard roles in the Solution domain – I know that the Business Analysts in the crowd will quickly become very upset. I can almost hear, “Where am I?” And when I show them that one of the key deliverables of business process modeling is assigned to the System Architect, their discomfort turns to horror. In their minds, such models should always be the responsibility of business analysts, and BAs are not“architects”!

Even when I show the “BA Discipline” that can be viewed throughout Macroscope, that still doesn’t do the trick.