Could you please review my story and tell if anyone else have been into situation like this? Books Iíve read tell that things mast happed VV. However test-before-code approach is already a practiceÖ
Two stories actually. The first about product design documents. Seen project with architect role talking to developers as they code. His main duty is writing down their ideas to the design document. Of course he also review ideas and come up wit some suggestions, but main idea is that the document are created for the only purpose to store the information that are on developersí minds. This information could be later used for reuse, support, etc.
The second story is about test design. In one project I did an experiment and asked testers to test without writing test cases. We wrote test cases after the first iteration was released: with the only purpose of use them as regression test cases. There were some drawbacks for this approach and initial resistance from experienced testers. Still I am proud of what we did with so little resources.
One of the roles of the architect is to make sure the overall infrastructure keeps pace with what is being developed, to incorporate non-functional requirements, and to consider maintainability. It also provides an opportunity for follow-up where there are interfaces to other systems that could be affected by an application change.
The story about documenting the results of what I see as exploratory testing is a good example of how that should be done. I still do not think of this as a replacement for a structured test plan.
I agree with the role of Architect as described by Frits - however in our SDLC the architect is involved in the creation design document and when appropriate an infrastructure document is created - however this is before coding is started. For the most part to start looking at infrastructure when coding is being done seems to be too late in the process.
What I think Ainars is referring to is the code walkthrough, which takes place after the code is written. The architect will in fact review if the implementation is consistent with non-functional requirements and consider any impact on interface code with other applications. I am sure you have something like that in your SDLC as well.
What I think you are referring to is an earlier SDLC workflow related to the functional design in order to make sure the right standards are used. This is all part of the QA process to validate that the code matches the expectations.
Frits Bos are 100% right. It was the first time I try to formally implement exploratory testing in my company and we really created (and got review by developers) detailed test plan (actually several subordinate test plans for different functional zones). And later used dashboard (as suggested by James Bach).
Regarding product design docs. It was very close to everything that Frits Bos described here and still it was little bit of what Lynne refers. I would like to call this exploratory coding. If exploratory testing is defined as simultaneous test design and execution, why then we canít have simultaneous application coding and design?