Hi there! I love the podcast! I'm discovering it today 😊 About the last topic, Quality Engineering as a culture, that's something I'm trying to improve in my team, still I'm not so convinced about not having a QE role.. What we do in our QE squad, is to have two hats: 1) be the maintainers of all test tools (test framework, IaC tools, GH workflows, Jenkins pipelines, and so on), enabling other squads to write their automated "happy path" tests, and we review and improve the coverage on top of that. 2) We try to be as much involved as possible during the design phase of features (we use RFCs as GH PR to comment them), so we can share with them some thoughts about corner cases, risks, if that will not fit with other features, usability aspect and so on. And then, we also perform exploratory testing when the feature is almost done, so we extract valuable information about it for our documentation squad, we give feedback, plus catch bugs. I think we still have a lot of room from improvement in our processes, so I'm trying to learn stuff from you guys 🤓 Thank you!
two examples where I have "shipped" regardless of weekday: 1) A system that implements a law that takes effect on a given day. 2) A system that is scheduled with an advertising campaign scheduled for a specific day. Not to forget Eurovision, Olympics and other "live" events - where there is a lot of rehearsal up front. But when the show starts - the show must go on.
things I never thought I'd hear @MatArmstrongbmx being mentioned in this context or @FriendlyTester @WhiteboardTesting consuming such infectious content
Haha, I love it mate, can't wait for the next videos to drop. Seems like a really genuine guy, and I love the idea of repairing stuff and giving everything a go. ^RB
This gentleman was an excellent episode and my head has been in the exact same place. I'd go as far to say...I'm not mad, just disappointed with people's hot takes 😂 Better yet, I can now point people to this if they ever bring up the topic in my presence again 😉
I'm not in the tech space, but a general geek who enjoys this content. Your explanation on Crowdstrike was really informative and helpful to understand how these things can go wrong. It also helped to identify the risk of leaving implementation to 3rd parties in our own systems. I think those of us not in tech over rely on those in tech and put blind faith in that their decisions and actions are always in the consumer's best interests. Not giving regard to the fact tech has its own politics and contracts to worry about.
The elephant in the room here is the responsibility - is it Crowdstrikes responsibility when consumers implement these SaaS tools in an inappropriate environment or the consumers havent taken their own steps to mitigate the risk? Handing control over to Crowdstrike to update your system is in itself a risk - so why has it been introduced into legacy systems that have no means of fallback? Seems the wrong product choice - probably pursuing security and not considering this operational risk imo
Hello Matt! I think we are about to find this out with Delta suing MS and Crowdstrike. If they win that case, a lot could change! Absolutely, I agree, I think the risk focus was clearly security and not a bigger picture ^Richard
Love this. I hear you Richard with the concept of Quality engineering the movement Vs Quality Engineer the role, and the mirror to DevOps. Context and maturity, just like I believe some teams and companies are still successfully having DevOps engineers, many companies are in need of quality engineers. Over time, as those QEs help change the engineering and product culture, that need may reduce. And as some of those quality engineers move to new teams, roles (engineering manager...) or onto new companies. Not all the teams will need to replace those QEa, some will have developed a strong enough culture, skill and discipline to continue without them. Other teams may continue to work for a long time, with QE as valuable members, and won't move on to operate without them. It's going to be down to the company, team and project when it works and when it doesn't. And as Vern mentioned, the support for QEs the role and QE the culture, from leadership.
Yeah, I do agree with this. My continued reflections on this is that to be a very effective QE is a unicorn set of skills. Especially to be very good at them all. I'm starting to feel that the role of QE is more of a conductor/Orchestration aka Technical Leadership. Then those specific roles, e.g. Exploratory Tester / Automater / Toolsmith / Test Lead and so for might make a return. But again it's a fine line between the activities that require actioning, and a role to specifically do that. So this QE Leader can influence that. But if push everyone to be a QE, some of those hats might not get the attention and industry improvements they require. I almost feel like it's going full circle back to QA Managers, but with a wider set of powers to influence outside of QA/Test. Still lots of pondering to do! ^ Richard
@@TheVernonRichardShow Just like quality is value that matter to someone, at a given point in time, so Quality Engineers are someone who is helpful, to some team, at a given point in time. And not all teams will need a QE, and some teams will succeed with people in fixed roles, while others will be a group of generalists. All models can work, if properly supported by management and company structure, culture and investment in people. All models can fail, with a lack of investment, poor culture and a void where leadership should have been.
I relate to Richard's 'army of checkers' mentality. I've always referred to them as an army of test-bots, which led me to adopt the moniker 'bot-whisperer.' 😆
Another great episode guys, and thanks very much for the podcast plug as well 🫶🏻 I'll forgive Vern for slightly misrepresentating my thoughts on how I describe quality engineering as it generated a really interesting conversation 😉
Learning outcomes is a great shout. One thing I hadnt thought of in my talk and abstract, puts a different light on my talk actually and how I should approach it! If that makes sense! Loving these videos! :) :)
Love it, great topics about confidence, onboarding, learning and getting unstuck. Could do without the football banter, I just don't relate. There, I said it.
On every assignment I have had, there has always been a heated argument about the difference between smoke, sanity, health, and a quick test. That is when I go outside doing a smoke test until they are done ;) Like the episode so keep it up!
I've always assumed it was named after the tests done by chimney maintenance....they burn a smoker to check that the air is flowing through ie is everything talking in your environment and data able to flow through
I truly enjoyed this and I am looking forward to hear more sessions.. I could relate a LOT about what you just talked and am glad you brought to the wider community how often testing have been underestimated and considered a robotic activity.. it is absolutely true also how the 'new' automation wave is actually a test case writing v.2.. so true! thank you!
Curious that there was no mention of Sanity tests, both smoke and sanity tests have been confused with each other in every industry i have been in. Either way love the show!! Subbed on here and Spotify!!
@Vernon please invest in better webcam brother. I recommend one of the 1080p units from logitech. (Say this with love) Thanks for all the awesome content!
