What I learn from 011 talk: "Death by User Stories" by Jenny Martin

BDDX ’2016 in London OOPSI MODEL

It was an very interesting talk which focus on OOPSI model as way to do user stories and epics. It is a very interesting approach to describe work to do. OOPSI model shows one of the approaches to describe project.

What I learn from this talk?

• According to Jenny, user stories can be dangerous, because stories can be like virus. Virus has only one purpose, to reproduce. It multiplying until they overwhelm delivery. It is called a creeping scope.
• Jenny used very interesting definition of acceptance criteria:  "Acceptance criteria define the boundaries of a user story,and are used to confirm when a story is completed and working as intended."  For Jenny, problem with them is that they looks like stories too.
• I like this definition, For me Acceptance criteria verify understanding of task and define when a story is completed with enough confidence.
• Catching large amount of users stories (as Jira ticket or post it note) on beginning on project is not  good use of time, because we cannot do enough analysis. It generates massive backlog that is not good use of time either.  it is  difficult to manage , many of these tickets nobody cares and they will be thrown away in the end. Many people doing this mistake of explosion of stories and output is similar or the same as  in waterfall.
• I called this water-scrum-fall problem where we are using agile tools but we still deliver project in waterfall style.
• Good thing about user stories are:
• Act as a token for conversation, to discover value.
• Helps us deliver things in smaller chunks, so that we can get value earlier.
• Help us track and estimates work
• Stories are to helps us understand what awesome outcome looks like.
• Stories in Oopsi contains following components:
• Outcome - it helps us focus on value and impact of the project that is describe as “In Order to xxx, As a xxx, I need xxx” (based on impact mapping)
• Output - Illustrate output with examples without details but with general case
• Process - where we split into Activities (linear)  tasks
• Scenarios - Given,When,Then . A different path though process to generate the outputs (test cases)
• Inputs - Inputs (concrete example and living documentation). Input and data needed to drive the scenarios.  Like test conditions or detailed examples.
• Story mapping. It helps you to describe epic and split into deliverable chunks. Look for the picture of incremental delivery by henrik kniberg delivery to help you picture this point. ( http://blog.crisp.se/wp-content/uploads/2014/10/Screen-Shot-2014-10-07-at-08.20.00.png ) where from his blog when he talking about .
• Other things that was mention in this talk:
• Documentation is treat as a rude word in agile
• Oopsi in reverse looks like  “Is poo”.

I think, there  are many  bits and pieces that can be useful to use in the place where I work now as in my opinion, it will help deliver project smoother. Describing output through conversation  drives whole process into deliverable chunks of work. Story mapping is a technique that can help you do that. Oopsi can help you to have living documentation 

What I learn from 010: talk "Testable Software Architecture" by Aslak Hellesøy

BDDX ’2016 in London TESTABLE SOFTWARE ARCHITECTURE

Aslak Hellesøy is creator of Cucumber. Cucumber is a collaboration and communication tool .It helps create living documentation. It is used as regression test but this is side effect.

This is what I learn from this talk:

1. Test should inspire confidence. In order to be confident about tests:
1. They shouldn’t be any false positive or false negative. They can fail only, when system is broken).
2. They must be lighting fast. 
1. Fast feedback (you should not wait more than than 1 hour for test to complete. If test takes hours , there is an architecture problem.
2. Remove all IO file/network  . No DB, No HTTP. No external architecture.
3. Low cost (as Ken Beck said :  “I pay to write code (solving problems ), so I don’t want spend time to maintain tests. 
4. They need be consistent and you cannot depend on third party ,
2. You must have decoupled architecture to get confidence through tests. Decoupled architecture allowed you to swap elements. In testing you can swap real thing with fake. TDD helps you to write decoupled architecture.
3. Low cost tests
1. Cost of writing test.
2. Cost of maintain test.
3. Test should gives you precision what , why and where went wrong.
4. If you CANNOT do above things if you do it through UI , because in the system UI changing all the time  . UI tests doesn’t give précised diagnose what went wrong. It is take long time to fix them.
4. (I need to do more research about it) Fakes with Port and Adapter patterns. Use Adapter pattern for fake service. Fake service should be tested by contract that need be passed in real and fake implementation.
5. What’s QA role ? Programmers writes tests  after QA design tests. QA do not write tests). Test are written before the production code. QA is involved from start by writing acceptance criteria based on requirements from BA and PO says. QA focus on prevent defects not finding them in later stage.
6. Acceptance and regression tests should be automated because machine can do boring repeatable task, while QA could do more valuable things and perform  manual exploring tests.

It was an awesome talk. I learn more about QA role and how I as developer should fit to testing part of developing lifecycle.

What I learn from 009 talk: "BDD is not about testing" by Dan North

BDDX ’2016 in London BDD is not about testing

Dan is a legend. Dan is one of the funniest and definitely most humble speaker in our galaxy.
I attended to BDDx in London organised by Skills Matters, where Dan was one of the speakers.
Below, you can find informations that I learn or I believe are useful to know from

1. Dan starts from point out that testers feel unloved and abandoned by Agile . "Goals of testing is To increase confidence for stakeholders through evidence" because as Kent Beck said : “I paid for code that works, not for tests, so my philosophy is to test as little as possible to reach given level of confidence”. Different stakeholder has different need for confidence that can be achieved through evidence. For example security stakeholder  needs have confidence that it is secure and so on.   
2. We don’t see bug because of 2 cognitive bias:
1.     Confirmation bias when my unconscious unconsciously delete anything with my world model. My world model is I am good programmer and I write really good code otherwise I will be depressed and I will be sad and I don’t want code.
2.     Fundamental attribution error is You assumed If something good happen to me I assume that I have something to do with it. If something bad happen to other I assumed they have something to do with it.
3. Good tester have 3 super powers:
1. Empathy for stakeholders (to think like them).
2. Ingenuity for evidence.
3. Balance for trade off. 
4. Programmers and Agile movement does NOT understand testing. Programmers usually see testing as irritation, managers see testing as source of risk. Industry see this as non-critical activity.  One of the reason is Agile movement doesn’t understand testing because Agile was invented by programmers (people who created Agile Manifesto are programmers ) so tester role is poorly defined.
5. Agile testing is poorly defined and not mature yet. He shows example where 5 days agile testing course contains 1.5 day about testing and rest not (things like Agile manifesto , principles , planning ,estimations or soft skills assessment . Agile testing should cover things like test strategy (one of the most important elements ) , regression tests , functional and non functional testing , write automated and normal acceptance criteria , test metrics , tools for exploratory testing  
6. TDD is a programming technique (discipline ) for programmers not testing
7. BDD is not about testing.
1. BDD acknowledge multiple stakeholder , because PO cannot know everything ( , security, compliance and so on ) and we need describe behaviour of the system 
2. Acceptance criteria is first class citizen . We describe output (result)
3. Acceptance criteria the outset ... What is outcome what is correct ,deployable
4. Everything in BDD happens from perspective of the stakeholder. BDD implementing system by describe it behaviour from perspective of the stakeholder. Goal of BDD is to working software that matters for stakeholders. It happens while we build software we using various testing activities to build confidence . We increase confidence for stakeholders through evidence .
5. In BDD ,testing is business critical
8. Testing is a part duty of care.  
9. BDD should be called BGD Behaviour Guided Development (name was inspired by book titled “ Growing Object-Oriented Software: Guided by Tests” by Nat Pryce and Steve Freeman . 
10. Good Automated tests should have:
1. Intention revealing name.
2. Intention revealing error (need to know why and how it failed).
3. Consistent language.
4. Must be fast.
5. Close to the action (if is communication through Http ,test through http).
11. Gherkin is not designed for testing .It is tool for guide development bad for that because it is bad in intention revealing error, Consistent language (14 scenarios to catch one intent) and they are slow.
12. BDD is not about testing , however testing is mandatory part of BDD because it helps gain confidence.
13. Test thinking is critical to successful delivery .
14. Most important aspect Good architecture/software is testability and simplicity (not flexibility and reusability as most people thinks).

Dan's talk was sublime. Last thing worth mention is I decided to learn 1 language and 1 technology per year. After his talk language that I will learn is Python , because he said it is a great language for … automated tests.

What I learn from BDDx

In November, I attended to Agile Testing & BDD eXchange 2016. It was conference about Agile Testing and BDD. Information about conference can be found here: https://skillsmatter.com/conferences/7428-agile-testing-and-bdd-exchange-2016. 
It was a great conference worth money I spent. I learn how I  as developer should interact with QAs and why QA is not only about  manual testing. In next few weeks I want share some information what I learn from talks by Dan North, Jenny Martin and Aslak Hellesøy. In this article I will include  main things that I learn and what I learn from talks Kevlin Henney, Ciaran McNulty, Alan Parkinson, Konstantin Kudryashov and Cosmina Bradu. There were a few talks that I missed and I didn't watch yet.
I have noticed that many speakers moaning about Jira and Gherkin.

My main take out from this conference were:

1. QA in Agile feels unloved and abandoned by Agile. Main reason for that is that Agile was created by developers, but truth is that QA is critical part of Agile methodology.
2. QA role is to focus on design test strategy but they shouldn't write tests. It is a Developer job (with exception if they want to do it). They should be involved with from beginning when requirements are clarified by BA and PO to help them write acceptance criteria . Automate test do not replace QA.
3. Test should be give confidence to everybody therefore they need be fast and low cost (to write and maintain) . Few talks shows how it is possible to achieve.
4. Automate tests of everything is overkill.  Don't write automate test for prototypes or in early stages when code is likely to change in near future. Purpose of test is to gain a confidence that code does what we expected .Write automated test (like acceptance criteria, regression) for stable code to remove dull manual tests done by QA as they could this time doing a valuable things and perform exploring tests and so on.
5. Few talks mentions various techniques that can improve your productivity like:
• Impact mapping
• Three amigos
• OOPSI model
• How to structure your tests
6. TDD is a programming technique (discipline ) for programmers not testing.

Below you have my quick notes from other talks.

• Don't fire the testers by Alan Parkinson.
• It was useful  talk about why  testers/QA  shouldn't be replaced by automatic tests and what’s role as they critical  part of Agile Testing  and that they shouldn’t write code. This talk is another example why automate tests are great for  remove boring manual testing and allow QA focus on test strategy.
• Getting out of end-to-end testing jail by Konstantin Kudryashov
• It was cool presentation when Konstatin shows how to improve speed of end to end tests.
• UI and IO are 2 major factor of slowness in testing
• Removing these factors can reduce single test  from 1502ms to 2ms. After get rid of UI, our taste took 10ms instead of 1502ms. After mock database, test took 2ms instead of 10ms. If your test mix UI , DB and so on, then you will has serious problem. You should have chat with QAs and PO to improve it
• Don’t use float for money.(I know that, but it is always a good reminder).
• BDD in Action – a before and after case study by Cosmina Bradu
• This was an interesting talk by person who introduce BDD as way to improvement development cycle.
• What went well:
• Impact mapping seems be great tool for BA, PO and team to visualise need to be deliver and what impact it will have. However from what I understood it can be time consuming activity. User story mapping is useful when you have many requirement.
• Impact mapping definition. User story mapping it helps to split big features into simple task and improve invisibility.
• Three Amigos it helps share ownership of story.
• There were 2 main things that didn’t work for them:
• Gherkin scenarios as acceptance criteria is not a good solution. Dan and many other people has negative opinion about it. Main reasons are: 
• Gherkin Scenarios get  verbose very quickly. 
• Hard to maintain overtime. Too many scenarios can be overwhelming and  you lost ability to see big pictures and prevent you to share understanding.
• Another thing that didn't work too well is upfront analysis done by BA only  . Upfront analysis shared docs != Shared understand.
• Pair testing in Agile world by Raji Bhamidipati
• It talks about her experience with pair testing, but principles applied to most types of pair work in it like pair programming or pair testing
• There are many types of pair working
• Expect-Expert like Exploring tester with Security tester, where instead of going back with feedback and forwards . Time saved on loop
• Expert-Novice 
• Novice-Novice works because they have different strategies so while 
• Driver-Navigator 
• Ping-Pong Pairing swapping 
• Mob popular in testing. Group of people testing at the same time.
• Advantages
• Team building and collaboration
• Share knowledge
• Mix of skill set based on requirement
•  Disadvantages of pair testing
  • work overload
  • conflicts when paired incorrectly due personality incompatibility
  • do not let pair testing create favouritism or elitism within your teams. let's opportunities to everybody not only one person.
• When not to pair:
• Do not pair with people who are not fans of pairing or are incompatible 
• If task is not suitable for pairing
• and all others.