Breakfast… BREAKFAST… Okay okay okay. That was a delicious spread of bfast options. Y’all are missing out. Now, this first time live blogger needs to down some coffee if this is going to be full day of frantic typing.
WE.ARE.LIVE
Tristan is our host, and is welcoming us, encouraging fist bumps and meeting other members of this community right from the get go. Amazing. You have some serious competition Vern. Get your tutu for bonus points.
A quick shout out to Rosie and Richard as we run through the history of MoT, a sharing bit about the Club and the conference specifics, including the food truck party this evening. Okay… We are ready. You are ready. Let’s do this.
First up is Carlos Kidman.
Quick check of the crowd… how many developers? Whoa! That’s a lot of hands.
Simple opening statement: THE best way to get get test automation working in your org, get your devs excited and involved (YES). I have to agree with that one.
Every client wants test automation… but it always treated as a lower level objective. This sets unrealistic expectations: timing/quality/tech stack limitations. This is never asked of dev teams but needed consistently for test automation. Madness.
Let’s look at the breakdown of teams: FE, BE, UX/UI, Android, iOS, PM… oya and one QA. This really makes for a displaced capacity to match code with testing.
But what about the Testing Manifesto (@growingAgile) This seems like a great idea, but where is the time to do this?
Question to the audience: Should QA engineers know how to code? Super split responses from the audience. Take back those fist bumps.
Well, let’s visit Lisa Crispin’s DevTestOps Manifesto:
- Continuous Testing over testing at the end
- Embracing all testin activities over automating everthing
- testing what gives value, based on customer usage over testing everything
- a whole team approach to testing over testing in silos
- product coverage over code coverage
Approach for us to consider: Lead Up and Down
- Really (honestly) speak to your developers to ask them how confident are they with the work so far? They know where their uncertainty is. But they don’t actually know for sure where and how we are testing.
- Prioritize your coverage based on some of this conversation and measure progress against this uncertainty. How do we get the dev’s confidence from a 2/10 to a 4/10. Complete the feedback loop of the testing to the person working on the code
- Make all of this super visible to the team. Often people see our schedules and progress… not our strategy
Interesting narrative being shared from Carlos’ work experience. How they planned out their testing of leaving a review feature. Simple flow diagram, demonstrating where the selenium tests are. They dove into the customer data, and saw how customer used and viewed the flows and system. Then laid out the test approach to the developers… and looked for opportunities to potentially revisit how to test the flow using other approaches including API and code level testing that could bring down the complexity fo the Selenium testing. Overall, this led to a harmonized approach that gelled how they designed the project not as discrete pieces, but as a delivered system.
Test Automation IS a programming project (OMG thank you). We need to treat automation as a complex project. Often the test automation is the glue of the larger project and yet it is not treated that way.
Interesting concept being introduced that Pipelines should be treated as product too. This helps us consider all these pieces together. It is super important to then visualize how testing is designed to match the pipeline.
Test automation should make it easy for ANYONE to create, run and consume the tests and the test results. Again, another call to make tests accessible and visible. Developers are trained to code review… they know how to do this well, and can really help us up our game.
Btw, Carlos is a natural. Super funny, and really plays well with the audience. Just went on massive tangent on pikachu and pokemon. Pretty sure he is going somewhere with this. OMG… forget it you had to be here for pikachu on steroids.
- oooooohhhh… he just hit one of my biggest pet peeves. Adding retries to tests. If we do not trust our own tests, how can we expect our devs to trust them??
- Tests should be atomic and pragmatic. Hits up the testing pyramid. How do we move the big tests down as low as possible in the pyramid? Build out the top flows and then work down.
- Each test should run within 60 seconds. Basic reasoning here: easier to count and measure
- Tests should stay in the stack. I see this fail often. When the devs are not connected to the testing stack, it is super tough to get them involved.
- Technical designs should be reviewed by both Dev and QA
- Test failures should be actionable. OMG yes again. If nothing happens after a failed test, then what is the point?
- Tests should be easy to maintain.
- Dont let testing or process get in the way of Quality. When we confuse testing for process, it is the product that suffers
NOOOO no questions! We need to hit him online