3 hours ago
Dear Ilya,
Have in mind that what i write is just one out of many ways of making this work. There are no right or wrong as long as it works in your context. I encourage you to make your version and do what it takes to make things work for you. I do not claim my way to be the superior way to do things, i just give you some suggestions based on my experience. Also my article only cover some parts that i choose to highlight this is not the complete story.
1. From a testing point of view i still claim that TDD is still merely checking. With merely i will emphasize that TDD and is not sufficient as the only source of quality related information as many tend to believe. I have several times from “agile experts” heard imaging you just push a button and all your automated tests runs and when all are green you are ready to ship. Every now and then i hear teams saying “we do TDD so we have no need to testers” going in the belief that since they have covered all the code with what they call tests (we call checks) they have done complete testing. I also come across teams that have testers on their team but the testers spend their time doing unit test or automated acceptance tests since those things have test in the name it must be the testers job to do, right? As you point out TDD often have lots of value and i too point that out in my article (“I assume that you have needed checking in place and that developers take responsibility for this so we testers can focus on providing value by testing.”). But to get the value developers should see it as an help for them to design and write good code. But no, i do not include TDD in the scope of testing i see it as a development practice that done right usually is very valuable.
2. In 1 you state that “there is no such thing as automated testing”. So if this is the only thing that is going on, then tell me what valuable and skilled testing occurs?
3. "writing manually scripted tests": traditionally testers write test cases with detailed step by step procedural instructions and often an expected result connected to each step. This is done in a “test design phase” after that follows a “test execution phase” when the tester follows the detailed step by step instruction to execute the test case and compare that to the pre defined expected result. Many testers believes this is the only way to perform proper testing and bring this way of testing into the sprint in scrum.
4. Well, maybe one can intrepid the description of scrum your way but think about it do you really think that is what is intended. So if the PO decides that we done when the code is written he do not even care if compiles we just ship it. Then the team should just bow and fulfill his wish without questions asked? for example not caring about things like the technical depth that this leads and will in the future shoot the team in the back or what if the PO has no clue about what his responsibilities are. In theory you can find a lot of extreme situations but instead looking at the reality most POs base their decisions on information and testing can provide a valuable part of that information. Or are you suggesting that the PO is the one doing all the testing himself to figure out if to accept or reject. If not, then tell me why would you write code if you do not care if it works or not?
5. My bad, of course it shall be the Product Owner!
6. Okay great, so you have different experience then me on this. Then i suggest you continue to sit with your team and split stories to tasks. But when do you plan your testing then? What i seen in many teams is that testers are quite passive during this activity and often the discussions are around developing stuff and very little time is spent on figuring out how to test it. We usually get a good understanding of the story when the whole team discuss the story together with the product owner. When we break out we still are in the same room so we can talk to dev if needed and vice versa. At the end of this meeting we all brief each other and we get feedback on our testing and dev tells us about what they have done, we also notice if we need to make any updated. This is a way that has worked for me to speed up our planning meetings and to make all members time as productive as possible. The sprint planning for testing in not the final plan where all test ideas are identified, we continuously during the sprint add new missions to test and re-prioritize our planned missions and charters.
7. You can do it your way too. It does not particular matter. We always brainstorm more missions then we can test during a sprint anyway so we can pick the ones that we believe are most valuable.
8. The charter help us as a guide through our test session. What shall we cover during our session and how are we going to do it. It also helps us in our daily planning and prioritization of what we shall spend our time testing.
9. Well, you can be really strict and do what a book tells you to do and if that works well for you that´s fine. But if it does not work well i suggest you change it to make it work. To me this is the essence of agile: try, learn and change to make it work in your context.
10. I offer a thought that if you react and respond to information immediately you might not need to store bugs in a bug tracking system with the intention to deal with them later. I do not say that one do not need a bug tracking system just because you do scrum or SBTM.
11. Usually the team spends time with the PO before the public demo. We go through what have been done and let the PO try the SW and ask questions. You can say that this is the private demo for the PO where we can have open discussions about the outcome of the sprint. We have the retro after the public demo.
12. With both the PO and internally within the team.
Hope i have addressed all your thoughts!
4 hours ago
Nice example of "individuals and interactions over processes and tools" and "working software over comprehensive documentation" with explicitly stated context ("My main goal was to stabilize the application as quickly as I could").
Still I wonder, wouldn't it be better to use simple pairing of developer & tester?
4 hours ago
Thanks for the feedback. I was trying to tell a narrative, with Web Consistency Testing as a motivating an example, rather than a piece about Web Consistency Testing. I'll try to work on conciseness for my next article.