2011-05-05 - Architecture Support for Testing

Skip to end of metadata
Go to start of metadata


Ideer for lyntaler og open spaces

IASA møter er avhengige på brukerinnhold. Bidra med et forslag for et lyntale (10-20 min) eller et tema for en open space diskusjon. Snakk kan være om problemer du møter, suksesser du har hatt, eller ideer du har hørt om at du ønsker andre å diskutere.

Hvis du er innlogget, kan du redigere siden for å legge til forslaget listen (nedover). Ellers ganske enkelt sende den rett til IASA team


One of the new initiatives of the Software Engineering Institute (SEI) is to explore the practice of Architecture support for Testing.

That is, using the system’s architecture to inform and guide the system’s testing activities. While there has been substantial work devoted to this topic in the research community, not much of that research seems to have filtered into communities of practitioners. Hence, the promise of architecture-based testing–to use architecture to reduce the time and expense of testing and to increase its effectiveness–remains unfulfilled.

It would be useful to collect experiences and ideas from IASA.no members around this topic and feed them into the project.
Similarly it would be useful to get ideas already collected by the SEI from other practitioners out to our community.


lyntale eller space Tittel Beskrivelse Forslått av
lyntale Summary of SEI's Architecture Support for Testing Initiative oppsummering av arbeidet så langt fra SEI initiativet Jason Baragry
Foredrag - 30min How your choice of middleware product affects your testability   Bård Lind
lyntale Enklere testing med arkitektur? En kjapp gjennomgang av noen vanlige løsninger og hvordan det påvirker testbarhet. Anders Sveen

Blir diskusjon/openspace/spørsmål enten rett etter hvert foredrag eller etter at alle tre er ferdig.


  • testing consequences of middleware
  • arch and testing ideas from Anders
  • strong experience with Agile and continuous build, test
  • arch support for automatic testing during dev process
  • mye focus on automatic testing because of agile focus in norway.
  • e.g., hard to test middleware that can't play nice automatic testing
  • identifying bounded contexts to help define test boundaries
  • sometimes easier to test req-resp because you don't need to test JMS / DB separately
  • the arch tendancy to modiarise and distribute without thinking through assumptions for them can be dangerous for testing. Esp for synch comms testing
  • important to be able to isolate components for testing. This can be hard with ESBs that try to do eveything. Hard to include these types of middleware in automatic testing.
  • can you include all arch qualities in an auto test system. E.g., specflow, cucumber. Which qualities can you test without a full test environment. E.g., perhaps msg-level security but not performance.
  • difference between check (auto) and test (manual) in how you consider testing.
  • how to get DBs and MQs into a certain state at the start of a test suite?
  • difficult to get infrastructure into a start state to do proper auto testing
    • DB, webserver, appserver, etc.
  • how do you affect the procurement process to influence technology choice based on middleware testability?
  • where does testing separate from monitoring?
      • E.g., ESBs are very good for monitoring the infrastructure so you can see what has actually happened. But they are not good for testing during dev
  • testers should be better educated about monitoring possibilities. E.g., use a http sniffer
        • google test blog
      • devOps -> devTesters


lyntale eller space Tittel Beskrivelse Forslått av
Lyntale og/eller openspace Integration architecture and testability   Erik Drolshammer
  The architect-test manager interface Hvilke forventninger/ønsker/krav har testleder? Ingvild Meyer Pedersen (ikke anledning til å snakke om dette)
year2011 year2011 Delete
medlemsmøte medlemsmøte Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.