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.