TL;DR
This post is about my takeaways from TestBash Brighton 2017 conference day.
The testers survival guide to joining a continuous delivery project by Amy Phillips.
Amy suggested us to read two books:
- Project Phoenix
- Continuous Delivery.
Tester must now continuous semantics: dead canary, walking skeleton and dark lunch are some of them. In first week tester should know his project role, project deadlines and establish code review procedure.
Another book was mentioned: What is trunk based development.
Be aware of all communication channels: recurring meetings, trello, slack, github, jira,…
Catalog information that you do not know (need answers), ask same question to different people, be alert on information changes. Think about support staff as one persona that is using your application. Read bug reports!
Assess your environment and note HOW THEY DIFFER!
When you think about bug that is not resolved, think about a cost if this bug would be shipped in deploy.
Read code if you can. Even better, ask developer to explain to you part of his code. Doing that, maybe some issues would pop up!
AI language and the net by prof. Harry Collins
Oh, this was a goodie!
We have two elements for computers: the clockwork and computers as social prostheses. Every computer IS DOING LESS THAT REAL STUFF. The goal is that this become equal!
Some programs have passed the Turing test just because it was not hard enough.
We have tacit and explicit knowledge. Every knowledge has author (producer) and critic (consumer). Objective experts should be somewhere in the middle.
There is no deep learning, there is VAST amount of data to which computes have access and they represent social machines. Complete knowledge has not yet been achieved.
Testers have important role in creating AI.
Rediscovering Test Strategy by Mike Talks
On Thursday meetup, I played with Mike and his friends Monty Python’s Flux card game (at that time I did know that this was Mike). This was my first play of Flux, before that I just read the instructions. I learned that there can be several RULE cards at the table, the only rule is that RULE cards must no be exclude (logically) each other.
Testers usually create their test plan based on previous work (experience). Mike noted that strategy is different than plan.
Testers have a lot of test ideas. We should capture them (e.g. post it), cluster them and discard ones not relevant for the project scope. With all test ideas in front of you, it is easier to find gaps in your test strategy.
Mike created Oblique Testing cards that can help you with your test ideas. He also mentioned Ministry of Testing TestSphere cards.
Testers usually have test ideas related with keyboard and mouse because those inputs are most available!
How to turn 403 into 202 at the API party by Gwen Diagram and Ash Winter
I learned about BINMEN acronym that is useful for API testing:
Boundary
Input
Null
Method
Empty
Negative
Always put less logic in User Interface!
Building customer happiness with a tiny team by Paul Campbell
Following technology stack enables them to do that with tiny team:
- AWS
- Stripe for payments
- aurora database
- happroxy
- webmon
- neustar/loader.io
- opsworks
- intercom
- pivotal tracker
- slack
