Here is the slides with notes/transcripts of the webinar ‘Design Scientifically ‘, the third in the Tri-series webinar ‘How to test a user story’.
The audio recording of the webinar is available here.
You can view the webinar slide deck below:
You can see the Q&A session of this webinar below. Click on each question to see the answer.
1. Why does it become ‘stimulate to uncover’ in agile projects while in waterfall model it was ‘discover bugs/defects’?
We normally think of test cases as something that has to be executed (stimuli that have to be executed) on the System Under Test (SUT) to uncover the issues. Our entire notion of test design is always been to “come up with the list of test cases” whether it is agile or waterfall.
What I meant is that, it is not only the act of design but is the process of digging deeper to understand the indented behavior and then finally to validate that the intended behavior is met or not.
In a waterfall model, we make a kind of assumption that everything that needs to be known about the behavior is given in the form of a document, which is not applicable in the case of Agile.
Here ‘stimulate to uncover’ means we are in the process of evaluation; that means we ‘kind of know’ what is supposed to done/evaluate.
In agile world, we are in the process of constant and continual discovery. Hence it is not only to stimulate to uncover, it is also about to ‘know the unknown’.
2. You explained E1, E2, E3 and E4. It is clear that E1 is smallest and E2, E3 and E4 become bigger and complex. Should we list up there E1-E2-E3-E4 in mixed? Or can we separate each of the entity from E1 to E4? I think it is very difficult to list up with mixed mode of E1- E2 - E3 - E4. I think it is easier for us to list each entity. Can we compare Ex (E1 - E4) one time? It must be very complex and difficult.
When we talk about user stories, we always think of these smaller elemental pieces (E1).
When you have a set of test cases to evaluate, what are we tracing these test cases to; A user story(E1)?, a collection of user stories(E2)?, or a usage flow that constitutes a set of user stories(E3)?. So having these four categorization will help you to trace those test cases into different type of entities.
It probably may not be ‘complex and difficult’ as the fact is that, it is a constant and continual integration that is in progress. As long as we know that there are these TEN major flows that are implemented in THREE sprints using say 50 user stories, the list is there. It is not that, it is available in the beginning but is constructed as we go.
3. In Agile model the user story may keep change until it get deliver, so how can we prevent a bug/fault in advance?
Please note that what we build today could probably be modified rapidly, and that is the whole idea of being agile/responsive. So when you build something like a user story and trying to evaluate the same, If you have a standardize set of defects or a standardized set of scenarios then we know that these are all the probable defects that may occur. So if we know that, we become more sensitive to that and will prevent such defects automatically. So you will not 'make the defect' and then 'uncover the defect'.
The whole approach will shift and we will produce 'less waste' and producing higher value, which is exactly the philosophy of agile says.
The notion of 'Think&Prove' is a process of higher degree of sensitization, so that we will kind of prevent issues rather than find issues.
4. Whatever we discussed, does it hold good only for BDD or TDD also?
The fundamental notion for both of these is to prevent defects.
BDD – Behavior Driven Development – approach is to prevent defects, use behaviors rather than guess work. That is, list down the series of conditions (behaviors) and use that to develop the software.
TDD – Test Driven Development - approach is to come up with various potential scenarios of use/abuse and then use it to prevent some of these issues.
So whatever we have discussed is very much part of BDD/TDD.
5. Is there any certification HBT providing?
At this point of time we have more internal HBT certification and have not done anything in terms of certification. We work with the organizations to go beyond the training and call it as “Indoctrination”. As part of indoctrination we work with organizations to help them understand HBT and subsequently work with them to deploy HBT into their organization within their process. Typically this starts with the base line, to understand this is what we are doing currently, these are some challenges existing and post the indoctrination and deployment we would like to see some significant improvement.
6. If we need explore more on these frame work, where we get the information?
We are in the process of coming up with the portal which will contains more information on HBT. It is in some sense available now, but is in the process of being constructed. In a few weeks of time this will be updated with reasonably good information. An email will be sent to all the participants about this. The URL of the link is http://hbtcentral.org. There is information available in the form of blog which will have various articles. URL of blog is http://www.stagsoftware.com/blog .
7. What kind of education class is available for HBT training? Is that possible to get that training from Japan?
At this point of time what we do is kind of physical class. There is an ongoing work that we are doing which will be done in few more months where we are trying to have online educational materials for HBT.
8. Are there any constraints to use this framework?
Please understand that it is a methodology, a system of thinking that provides you a set of tools for thinking. We constantly learn to meaningfully adapt to the situation. There is no rigidity in the entire stuff like we should write like this, follow these steps etc. These are simple set of thinking tools which we learn to adapt to variety of different situations whether it technology or the process model or be it a kind of application.