Podcasts about SDET

Welcome to another Testing Peers podcast episode.This time, join Chris, David, Richard Bradshaw and Al Goodall (whose surname Chris had some real issues remembering, sorry Al!)In this episode, the Peers talk about the role of the SDET. Is it SDEad?To break the ice, Al leads the group into a discussion about the best live albums, in our humble opinions. Shout-outs to Linkin Park, Sky, Raye, Live Aid, Iron Maiden, U2, Seal and Hoobastank!The main topic dives into the main topic - the role of the SDET.What does it mean? Is it a synonym for a test automation engineer? Are you a tester if you're an SDET? What does the role of an SDET look like where you work?Chris asks his favourite AI tool for a definition to stimulate the conversation."The main difference between a software development engineer in test and a test automation engineer is focus and responsibility. An SDET focuses on bridging the gap between development and testing processes. And a test automation engineer focuses on designing and implementing automated tests."The Peers talk about context, focus, tooling, frameworks, responsibility, problem-solving and quality!What do you think the future for the SDET is?The Testing Peers Conference is happening on the 13th March 2025.Tickets available here: https://testingpeerscon.com/ticket/If you wish to Sponsor the conference: https://testingpeerscon.com/partners/If you wish to volunteer for the event: https://testingpeerscon.com/volunpeer/contactUs@TestingPeers.comTwitter (https://twitter.com/testingpeers)LinkedIn (https://www.linkedin.com/company/testing-peers)Instagram (https://www.instagram.com/testingpeers/)Facebook (https://www.facebook.com/TestingPeers)We're also now on GoodPods, check it out via the mobile app storesIf you like what we do and are able to, please visit our Patreon to explore how you could support us going forwards: https://www.patreon.com/testingpeersThanks to our brand new sponsors - NFocus Testing.nFocus are a UK based software testing company. They've been supporting businesses for 24 years by providing services that include burst resource, accelerated test automation, performance testing and fully managed testing services. In 2021, they launched a Test Automation Academy to create amazing testers and they've now created jobs for 48 people in our industry in just under three years! nFocus were a big part of PeersCon in 2024, really grateful for all they do supporting the Testing Peers.www.nfocus.co.uk and info@nfocus.co.uk for anyone wanting to get in touch.Support the show

Standout SDETs leverage cutting-edge tools to amplify their skills. They're not intimidated by new technology because they know that when used appropriately, it's a developer's best partner. Sidharth (Sid) Shukla joins Nikolay Advolodkin to share how generative AI can make developers more productive. He'll not only explain how to customize LLM models with your data but also give real-world applications of this practice. Sid also shares his insider tips on landing a job at Amazon and how to be a great asset as an SDET. CONNECT WITH SIDHARTH SHUKLA          

With the Fourth of July week upon us in the United States, it would be fitting to showcase what represents the best of America. In this episode, we start with Kuzzat Altay's story of his arrival in the United States as a refugee in 2008, equipped with no knowledge of English and few contacts. He shares how he taught himself programming and automation testing, eventually founding a successful training company, Cydeo. We also explore the possibility of becoming an SDET without coding experience or a college degree. Discover how to set career goals to stay ahead and get inspired by a genuinely American story. Listen now. Kuzzat will join us at the TestGuild for a complimentary special training webinar on July 13th, which will cover 'How to Become a Java SDET, with ZERO Coding Experience or a College Degree.' Don't miss out – register now: https://testguild.com/webinar-learn-to-become-java-sdet/"  

Are you considering becoming an SDET (software developer in test) in 2023? Then join us as we dive deep into the world of software engineering testing with James Morin, a seasoned SDET. Get a glimpse into how James transitioned from a coding bootcamp grad to diving into the world of testing as a profession - something most coding bootcamp graduates are qualified for, yet don't even realize is an option for them.Previous episode:https://www.buzzsprout.com/948958/10834831James Morin (guest):Linkedin - https://www.linkedin.com/in/jamesmmorinWebsite - https://www.thewizard.tech---------------------------------------------------

Гость — Николай Пономарев, Principal Software Engineer в MasterCard.Впервые в нашем подкасте гость не из Тинькофф. Если ты тоже хочешь поделиться экспертизой в одном из наших выпусков — пиши на канал QA Tinkoff в Телеграме https://t.me/qa_tinkoffО чем болтаем?Обсуждаем эволюционную теорию, по которой разница между разработчиком и тестировщиком однажды исчезнет. Узнаем, чем роль SDET различается в разных компаниях. Рассуждаем, как привить культуру тестирования на начальных этапах разработки. Думаем, как мотивировать или заставить разработчиков покрывать свой код тестами.Ссылки:https://docs.pact.io/Таймкоды:00:00 Начало00:24 О чем будем болтать с нашим гостем — Колей Пономаревым1:56 Почему эпоха классического тестирования неизбежно закончится5:34 SDET — Software Development Engineer in Test6:14 Как приблизиться к точке соединения роли разработчика и роли тестировщика в одном инженере9:54 Как выглядит пирамида тестирования в команде, в которой нет тестировщиков, но есть SDET16:28 Нужно ли SDET разбираться в бизнес-логике17:25 Как мотивировать (заставить) разработчиков покрывать свой код тестами27:16 Как автоматизировать проверки начального уровня качества32:08 Какими инструментами автоматизации пользуются в команде Коли36:43 К кому идти, если с тестом что-то пошло не так41:59 Блиц42:32 ВыводыКанал IT's Tinkoff в Телеграме: https://t.me/itstinkoffБольше про карьеру в IT в Тинькофф: https://l.tinkoff.ru/about-it-career

Welcome to another episode of Automation Explanation, an Agile Thought Podcast, where you will learn about quality through automated testing and its place in modern software development.   This week, your hosts, Antwan Maddox and Greg Burdick, are exploring the myths in regard to the role of Test Automation Engineers. Nowadays, there is more collaboration than ever before in the automation arena and most is happening remotely; the challenge is to provide a high-quality customer experience. People are investing a lot in automation, but it is very unlikely that they are actually succeeding in it, resulting in the failure of most automation processes, and the root cause often begins with wrong perceptions about the engineering role. Today, Antwan and Greg do their part to stop perpetuating these Automation myths.   Key Takeaways Automation Engineers/QE/SDET are not magicians. The origins of the magician myth: No Automation Engineer can take care of everything, meaning the automation performance, low testing, data validation, and mobile testing. There is no single person who has the breadth and the experience to the depth to be able to succeed in all these areas. Myth: Automation will solve all your problems. Automation cannot replace manual testing or solve communication bottlenecks as well as other problems that are related to the overall organization. Myth: Let's automate 100% of the test cases. Why do you have manual testers in the first place? What is the intention behind using commercial tools? If the intention is to put a bandage around the lack of mature collaboration among the Teams utilizing Automation, it is wrong. Automation is better suited for Agile Development Teams that understand the mature process of leveraging automation. There often isn't a proper ratio between Developers and Automation Engineers. Without an appropriate scale, you can't expect positive results. Myth: Automation will eradicate all bugs and defects. Test Automation encourages repeatable testing and it happens to find bugs, but this is not the central point of Test Automation. Why do these myths even persist? Organizations look for an Automation Superhero as a result of Agile immaturity which is still a challenge for many organizations. The inertia of dysfunction and resistance to change are two of the reasons why these myths persist. The perception that testers are cheap also contributes to these myths remaining. Some organizations expect Automation Engineers to accommodate their dysfunction and not challenge it. Lack of education in regard to Test Automation motivates these myths to stick. Antwan talks about the criteria for continuing testing maturity which fall into five categories: They do not have enough foundation to support the appropriate level for continuing assessment. Testing is an afterthought but test automation is at the forefront (which is so unbalanced from the Development Teams perspective!). There is nothing on the frontend that supports automation. There is little to nothing on the backend that supports animation. Do they even know what the Automation Team needs are? The movement toward change is scary and delays progress. What can we do to move forward? Empathy among Teams in providing what is necessary; empathy can be a game-changer! Understanding the architecture around the application. Assessing your level of maturity as a Team and as an organization towards Automation. You can have better quality with fewer tests. Setting up the environment for collaboration. Antwan shares some real cases to exemplify how to tackle these myths in organizations.   Want to Learn More or Get in Touch? Visit the website and catch up with all the episodes on AgileThought.com! Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!

I invited on a software engineer in test to talk about both what his job is like and how to actually become one. We ended up diving into so much more - different types of testers, certifications, programming languages, testing frameworks, and of course who would even be good for this role. If you're interested in writing automated tests or are even an aspiring developer that wants to use this position as a stepping stone to becoming a traditional software engineer, this episode is for you.James Morin (guest):Linkedin - https://www.linkedin.com/in/jamesmmorin---------------------------------------------------

About SeanSean is a senior software engineer at TheZebra, working to build developer experience tooling with a focus on application stability and scalability. Over the past seven years, they have helped create software and proprietary platforms that help teams understand and better their own work.Links: TheZebra: https://www.thezebra.com/ Twitter: https://twitter.com/sc_codeUM LinkedIn: https://www.linkedin.com/in/sean-corbett-574a5321/ Email: scorbett@thezebra.com TranscriptSean: Hello, and welcome to Screaming in the Cloud with your host, Chief cloud economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: Today's episode is brought to you in part by our friends at MinIO the high-performance Kubernetes native object store that's built for the multi-cloud, creating a consistent data storage layer for your public cloud instances, your private cloud instances, and even your edge instances, depending upon what the heck you're defining those as, which depends probably on where you work. It's getting that unified is one of the greatest challenges facing developers and architects today. It requires S3 compatibility, enterprise-grade security and resiliency, the speed to run any workload, and the footprint to run anywhere, and that's exactly what MinIO offers. With superb read speeds in excess of 360 gigs and 100 megabyte binary that doesn't eat all the data you've gotten on the system, it's exactly what you've been looking for. Check it out today at min.io/download, and see for yourself. That's min.io/download, and be sure to tell them that I sent you.Corey: This episode is sponsored in part by our friends at Sysdig. Sysdig is the solution for securing DevOps. They have a blog post that went up recently about how an insecure AWS Lambda function could be used as a pivot point to get access into your environment. They've also gone deep in-depth with a bunch of other approaches to how DevOps and security are inextricably linked. To learn more, visit sysdig.com and tell them I sent you. That's S-Y-S-D-I-G dot com. My thanks to them for their continued support of this ridiculous nonsense.Corey: Welcome to Screaming in the Cloud, I'm Corey Quinn. An awful lot of companies out they're calling themselves unicorns, which is odd because if you look at the root ‘uni,' it means one, but they're sure a lot of them out there. Conversely, my guest today works at a company called TheZebra with the singular definite article being the key differentiator here, and frankly, I'm a big fan of being that specific. My guest is Senior Software Development Engineer in Test, Sean Corbett. Sean, thank you for taking the time to join me today, and more or less suffer the slings and arrows, I will no doubt be hurling your direction.Sean: Thank you very much for having me here.Corey: So, you've been a great Twitter follow for a while: You're clearly deeply technically skilled; you also have a soul, you're strong on the empathy point, and that is an embarrassing lack in large swaths of our industry. I'm going to talk about that right now because I'm sure it comes through the way it does when you talk about virtually anything else. Instead, you are a Software Development Engineer in Test or SDET. I believe you are the only person I'm aware of in my orbit who uses that title, so I have to ask—and please don't view this as me in any way criticizing you; it's mostly my own ignorance speaking—what is that?Sean: So, what is a Software Development Engineer in Test? If you look back—I believe it was Microsoft originally came up with the title, and what it stems from was they needed software development engineers who particularly specialized in creating automation frameworks for testing stuff at scale. And that was over a decade ago, I believe. Microsoft has since stopped using the term, but it persists in areas in the industry.And what is an SDET today? Well, I think we're going to find out it's a strange mixture of things. SDET today is not just someone that creates automated frameworks or writes tests, or any of those things. An SDET is the strange amalgamation of everything from full-stack to DevOps to even some product management to even a little bit machine-learning engineer; it's a truly strange field that, at least for me, has allowed me to basically embrace almost every other discipline and area of the current modern engineering around, to some degree. So, it's fun, is what it is. [laugh].Corey: This sounds similar in some respects to oh, I think back to a role that I had in 2008, 2009, where there was an entire department that was termed QA or Quality Assurance, and they were sort of the next step. You know, development would build something and start, and then deploy it to a test environment or staging environment, and then QA would climb all over this, sometimes with automation—which was still in the early days, back in that era—and sometimes by clicking the button, and going through scripts, and making sure that the website looked okay. Is that aligned with what you're doing, or is that a bit of a different branch?Sean: That is a little bit of a different branch from me. The way I would put it is QA and QA departments are an interesting artifact that I think, in particular, newer orgs still feel like they might need one, and what you quickly realize today, particularly with modern development and this, kind of, DevOps focus is that having that centralized QA department doesn't really work. So, SDETs absolutely can do all those things: They can climb over a test environment with automation, they can click the buttons, they can tell you everything's good, they can check the boxes for you if you want, but if that is what you're using your SDETs for you are, frankly, missing out because I guarantee you, the people that you've hired as SDETs have a lot more skills than that, and not utilizing those to your advantage is missing out on a lot of potential benefit, both in terms of not just quality—which is this fantastic concept that dates all the way back to—gives people a lot of weird feelings [laugh] to be frank, and product.Corey: So, one of the challenges I've always had is people talk about test-driven development, which sounds like a beautiful idea in theory, and in practice is something people—you know, just like using the AWS console, and then lying about it forms this heart and soul of ClickOps—we claim to be using test-driven development but we don't seem to be the reality of software development. And again, no judgment on these; things are hard. I built out a, more or less, piecing together a whole bunch of toothpicks and string to come up with my newsletter production pipeline. And that's about 29 Lambdas Function, behind about 5 APIs Gateway, and that was all kinds of ridiculous nonsense.And I can deploy each of the six or so microservices that do this, independently. And I sometimes even do continuous build or slash continuous deploy to it because integration would imply I have tests, which is why I bring the topic up. And more often than not—because I'm very bad at computers—I will even have syntax errors, make it into this thing, and I push the button and suddenly it doesn't work. It's the iterative guess-and-check model that goes on here. So, I introduced regressions, a fair bit at the time, and the reason that I'm being so blase about this is that I am the only customer of this system, which means that I'm not out there making people's lives harder, no one is paying me money to use this thing, no one else is being put out by it. It's just me smacking into a wall and feeling dumb all the time.And when I talk to people about the idea of building tests. And it's like, “Oh, you should have unit tests and integration tests and all the rest.” And I did some research into the topics, and a lot of it sounds like what people were talking about 10 to 15 years ago in the world of tests. And again, to be clear, I've implemented none of these things because I am irresponsible and bad at computers. But what has changed over the last five or ten years? Because it feels like the overall high level as I understood it from intro to testing 101 in the world of Python, the first 18 chapters are about dependency manager—because of course they are; it's Python—then the rest of it just seems to be the concepts that we've never really gotten away from. What's new, what's exciting, what's emerging in your space?Sean: There's definitely some emerging and exciting stuff in the space. There's everything from, like, what Applitools does with using machine learning to do visual regressions—that's a huge advantage, a huge time saver, so you don't have to look pixel by pixel, and waste your time doing it—to things like our team at TheZebra is working on, which is, for example, a framework that utilizes Directed Acrylic Graph workflows that's written GoLang—the prototype is—and it allows you to work with these tests, rather than just as kind of these blasé scripts that you either keep in a monorepo, or maybe possibly in each individual services' repo, and just run them all together clumsily in this, kind of, packaged product, into this distributed resource that lets you think about tests as these, kind of, user flows and experiences and to dip between things like API layer, where you might, for example, say introduce regression [unintelligible 00:07:48] calling to a third-party resource, and something goes wrong, you can orchestrate that workflow as a whole. Rather than just having to write a script after script after script after script to cover all these test cases, you can focus on well, I'm going to create this block that represents this general action, can accept a general payload that conforms to this spec, and I'm going to orchestrate these general actions, maybe modify the payload of it, but I can recall those actions with a slightly different payload and not have to write script after script after script after script.But the problem is that, like you've noticed, a lot of test tooling doesn't embrace those, kind of, modern practices and ideas. It's still very much the, your tests, you—particularly integration tests do this—will exist in one place, a monorepo, they will have all the resources there, they'll be packaged together, you will run them after the fact, after a deploy, on an environment. And it makes it so that all these testing tools are very reactive, they don't encourage a lot of experimentation, and they make it at times very difficult to experiment, in particular because the more tests you add, the more chaotic that code and that framework gets, and the harder it gets to run in a CI/CD environment, the longer it takes. Whereas if you have something like this graph tool that we're building, these things just become data. You can store them in a database, for the love of God. You can apply modern DevOps practices, you can implement things like Jaeger.Corey: I don't think it's ever used or anything in the database. Great, then you can use anything itself as a database, which is my entire schtick, so great.Sean: Exactly.Corey: That's right, that means the entire world can indeed be reduced to TXT records in DNS, which I maintain is the… the holiest of all databases. I'm sorry, please, continue.Sean: No, nonono, that's true. The thing that has always driven me is this idea that why are we still just, kind of, spitting out code to test things in a way that is very prescriptive and very reactive? And so, the exciting things in test come from places like Applitools and places like the—oh, I forget. It was at a Test Days conference, where they talked about—they developed this test framework that was able to auto generate the models, and then it was so good at auto generating those models for test, they'd actually ended up auto generating the models for the actual product. [laugh]. I think it used a degree of machine learning to do so. It was for a flashcard site. A friend of mine, Jacob Evans on Twitter always likes to talk about it.These are where the exciting things lay is where people are starting to break out of that very reactive, prescriptive, kind of, test philosophy of, like I like to say, checking the boxes to, “Let's stop checking boxes and let's create, like insight tooling. Let's get ahead of the curve. What is the system actively doing? Let's check in. What data do we have? What is the system doing right at this moment? How ahead of the curve can we get with what we're actually using to test?”Corey: One question I have is the cultural changes because back in those early days where things were handed off from the developers to the QA team, and then ideally to where I was sitting over in operations—lots of handoffs; not a lot of integrations there—QA was not popular on the development side of the world, specifically because their entire perception was that of, “Oh, they're just the critics. They're going to wind up doing the thing I just worked hard on and telling me what's wrong with it.” And it becomes a ‘Department of No,' on some level. One of the, I think, benefits of test automation is that suddenly you're blaming a computer for things, which is, “Yep. You are a developer. Good work.” But the idea of putting people almost in the line of fire of being either actually or perceived as the person who's the blocker, how has that evolved? And I'm really hoping the answer is that it has.Sean: In some places, yes, in some places, no. I think it's always, there's a little bit more nuance than just yes, it's all changed, it's all better, or just no, we're still back in QA are quote-unquote, “The bad guys,” and all that stuff. The perception that QA are the critics and are there to block a great idea from seeing fruition and to block you from that promotion definitely still persists. And it also persists a lot in terms of a number of other attitudes that get directed towards QA folks, in terms of the fact that our skill sets are limited to writing stuff like automation tooling for test frameworks and stuff like that, or that we only know how to use things like—okay, well, they know how to use Selenium and all this other stuff, but they don't know how to work a database, they don't know how an app [unintelligible 00:12:07] up, they don't all the work that I put in. That's really not the case. More and more so, folks I'm seeing in test have actually a lot of other engineers experience to back that up.And so the places where I do see it moving forward is actually like TheZebra, it's much more of a collaborative environment where the engineers are working together with the teams that they're embedded in or with the SDETs to build things and help things that help engineers get ahead of the curve. So, the way I propose it to folks is, “We're going to make sure you know and see exactly what you wrote in terms of the code, and that you can take full [confidence 00:12:44] on that so when you walk up to your manager for your one-on-one, you can go like, ‘I did this. And it's great. And here's what I know what it does, and this is where it goes, and this is how it affects everything else, and my test person helped me see all this, and that's awesome.'” It's this transition of QA and product as these adversarial relationships to recognizing that there's no real differentiator at all there when you stop with that reactive mindset in test. Instead of trying to just catch things you're trying to get ahead of the curve and focus on insight and that sort of thing.Corey: This episode is sponsored in part by our friends at Vultr. Spelled V-U-L-T-R because they're all about helping save money, including on things like, you know, vowels. So, what they do is they are a cloud provider that provides surprisingly high performance cloud compute at a price that—while sure they claim its better than AWS pricing—and when they say that they mean it is less money. Sure, I don't dispute that but what I find interesting is that it's predictable. They tell you in advance on a monthly basis what it's going to going to cost. They have a bunch of advanced networking features. They have nineteen global locations and scale things elastically. Not to be confused with openly, because apparently elastic and open can mean the same thing sometimes. They have had over a million users. Deployments take less that sixty seconds across twelve pre-selected operating systems. Or, if you're one of those nutters like me, you can bring your own ISO and install basically any operating system you want. Starting with pricing as low as $2.50 a month for Vultr cloud compute they have plans for developers and businesses of all sizes, except maybe Amazon, who stubbornly insists on having something to scale all on their own. Try Vultr today for free by visiting: vultr.com/screaming, and you'll receive a $100 in credit. Thats V-U-L-T-R.com slash screaming.Corey: One of my questions is, I guess, the terminology around a lot of this. If you tell me you're an SDE, I know that oh, you're a Software Development Engineer. If you tell me you're a DBA, I know oh, great, you're a Database Administrator. If you told me you're an SRE, I know oh, okay, great. You worked at Google.But what I'm trying to figure out is I don't see SDET, at least in the waters that I tend to swim in, as a title, really, other than you. Is that a relatively new emerging title? Is it one that has historically been very industry or segment-specific, or you're doing what I did, which is, “I don't know what to call myself, so I described myself as a Cloud Economist,” two words no one can define. Cloud being a bunch of other people's computers, and economist meaning claiming to know everything about money, but dresses like a flood victim. So, no one knows what I am when I make it up, and then people start giving actual job titles to people that are Cloud Economists now, and I'm starting to wonder, oh dear Lord, have I started the thing? What is, I guess, the history and positioning of SDET as a job title slash acronym?Sean: So SDET, like I was saying, it came from Microsoft, I believe, back in the double-ohs.Corey: Mmm.Sean: And other companies caught on. I think Google actually [unintelligible 00:14:33] as well. And it's hung on certain places, particularly places that feel like they need a concentrated quality department. That's where you usually will see places that have that title of SDET. It is increasingly less common because the idea of having centralized quality—like I said before, particularly with the modern, kind of, DevOps-focused development, Agile, and all that sort of thing, it becomes much, much more difficult.If you have a waterfall type of development cycle, it's a lot easier to have a central singular quality department, and then you can have SDET stuff [unintelligible 00:15:08], that gets a lot easier when you have Agile and you have that, kind of, regular integration and you have, particularly, DevOps [unintelligible 00:15:14] cycle, it becomes increasingly difficult, so a lot of places that have been moving away from that. It is definitely a strange title, but it is not entirely rare. If you want to peek, put a SDET on your LinkedIn for about two weeks and see how many offers come in, or how many folks in your inbox you get. It is absolutely in demand. People want engineers to write these test frameworks, but that's an entirely different point; that gets down to the point of the fact that people want people in these roles because a lot of test tooling, frankly, sucks.Corey: It's interesting you talk about that as a validation of it. I get remarkably few outreaches on LinkedIn, either for recruiting, which almost never happens or for trying to sell me something which happens once every week or so. My business partner has a CEO title, and he winds up getting people trying to sell him things four times a day by lunchtime, and occasionally people reaching out of, “Hey, I don't know much about your company, but if it's not going well, do you want to come work on something completely unrelated?” Great. And it's odd because both he and I have similar settings where neither of us have the ‘looking for work' box checked on LinkedIn because it turns out that does send a message to your staff who are depending on their job still being here next month, and that isn't overly positive because we're not on the market.But changing just titles and how we describe what we do and how we do it absolutely has a bearing as to how that is perceived by others. And increasingly, I'm spending more of my time focusing less on the technical substance of things and more about how what they do is being communicated. Because increasingly, what I'm finding about the world of enterprise technology and enterprise cloud and all of this murky industry in which we swim, is that the technology is great—anything can be made to work; mostly—but so few companies are doing an effective job of telling the story. And we see it with not just an engineering-land; in most in all parts of the business. People are not storytelling about what they do, about the outcomes they drive, and we're falling back to labels and buzzwords and acronyms and the rest.Where do you stand on this? I know we've spoken briefly before about how this is one of those things that you're paying attention to as well, so I know that we're not—I'm not completely off base here. What's your take on it?Sean: I definitely look at the labels and things of that sort. It's one of those things where humans like to group and aggregate things. Our brains like that degree of organization, and I'm going to say something that is very stereotypical here: This is helped a lot by social media which depends on things like hashtags and ability to group massive amounts of information is largely facilitated. And I don't know if it's caused by it, but it certainly aggravates the situation.We like being able to group things with few words. But as you said before, that doesn't help us. So, in a particular case, with something like a SDET title, yeah, that does absolutely send a signal, and it doesn't necessarily send the right one in terms of the person that you're talking to, you might have vastly different capabilities from the next SDET that you talk to. And it's were putting up a story of impact-driven, kind of, that classic way of focusing on not just the labels, but what was actually done and who had helped and who had enabled and the impact of it, that is key. The trick is trying to balance that with this increasing focus on the cut-down presentation.You and I've talked about this before, too, where you can only say so much on something like a LinkedIn profile before people just turn off their brains and they walk away to the next person. Or you can only put so much on your resume before people go, “Okay, ten pages, I'm done.” And it's just one of those things where… the trick I find that test people increasingly have is there was a very certain label applied to us that was rooted in one particular company's needs, and we have spent the better part of over a decade trying to escape and redefine that, and it's incredibly challenging. And a lot of it comes down to folks like, for example, Angie Jones, who simply, just through pure action and being very open about exactly what they're doing, change that narrative just by showing. That form of storytelling is show it, don't say it, you know? Rather than saying, “Oh, well, I bring into all this,” they just show it, and they bring it forward that way.Corey: I think you hit on something there with the idea of social media, where there is validity to the idea of being able to describe something concisely. “What's your elevator pitch?” Is a common question in business. “What is the problem you solve? What would someone use you for?”And if your answer to that requires you sabotage the elevator for 45 minutes in order to deliver your message, it's not going to work. With some products, especially very early-stage products where the only people who are working on them are the technical people building them, they have a lot of passion for the space, but they aren't—haven't quite gotten the messaging down to be able to articulate it. People's attention spans aren't great, by and large, so there's a, if it doesn't fit in a tweet, it's boring and crappy is sort of the takeaway here. And yeah, you're never going to encapsulate volume and nuance and shading into a tweet, but the baseline description of, “So, what do you do?” If it doesn't fit in a tweet, keep workshopping it, to some extent.And it's odd because I do think you're right, it leads to very yes or no, binary decisions about almost anything, someone is good or trash. There's no, people are complicated, depending upon what aspect we're talking about. And same story with companies. Companies are incredibly complex, but that tends to distill down in the Twitter ecosystem to, “Engineers are smart and executives are buffoons.” And anytime a company does something, clearly, it's a giant mistake.Well, contrary to popular opinion, Global Fortune 2000 companies do not tend to hire people who are not highly capable at the thing they're doing. They have context and nuance and constraints that are not visible from the outside. So, that is one of the frustrating parts to me. So, labels are helpful as far as explaining what someone is and where they fit in the ecosystem. For example, yeah, if you describe yourself as an SDET, I know that we're talking about testing to some extent; you're not about to show up and start talking to me extensively about, oh, I don't know, how you market observability products.It at least gives a direction and bounding to the context. The challenge I always had, why I picked a title that no one else had, was that what I do is complicated, and if once people have a label that they think encompasses where you start and where you stop, they stop listening, in some cases. What's been your experience, given that you do have a title that is not as widely traveled as a number of the more commonly used ones?Sean: Definitely that experience. I think that I've absolutely worked at places where—the thing is, though, and I do want to cite this, that when folks do end up just turning off once they have that nice little snippet that they think encompasses who you are—because increasingly nowadays, we like to attach what you do to who you are—and it makes a certain degree of sense, absolutely, but it's very hard to encompass those sorts of things, and let alone, kind of, closely nestle them together when you have, you know, 280 characters.Yes, folks like to do that to folks like SDETs. There's a definite mindset of, ‘stay in your lane,' in certain shops. I will say that it's not to the benefit of those shops, and it creates and often aggravates an adversarial relationship that is to the detriment of both, particularly today where the ability to spin up a rival product of reasonable quality and scale has never been easier, slowing yourself down with arbitrary delineations that are meant to relegate and overly-define folks, not necessarily for the actual convenience of your business, but for the convenience of your person, that is a very dangerous move. A previous company that I worked at almost lost a significant amount of their market share because they actively antagonized the SDET team to the point where several key members left. And it left them completely unable to cover areas of product with scalable automation tooling and other things. And it's a very complex product.And it almost cost them their position in the industry, potentially, the entire company as a whole got very close to that point. And that's one of the things we have to be careful of when it comes to applying these labels, is that when you apply a label to encompass someone, yes, you affect them, but it also we'll come back and affect you because when you apply that label to someone, you are immediately confining your relationship with that person. And that relationship is a two-way street. If you apply a label that closes off other roads of communication or potential collaboration or work or creativity or those sorts of things, that is your decision and you will have to accept those consequences.Corey: I've gotten the sense that a lot of folks, as they describe what they do and how they do it, they are often thinking longer-term; their careers often trend toward the thing that happens to them rather than a thing that winds up being actively managed. And… like, one of my favorite interview questions whenever I'm looking to bring someone in, it's always, “Yeah, ignore this job we're talking about. Magically you get it or you don't; whatever. That's not relevant right now. What's your next job? What's the one after that? What is the trajectory here?”And it's always fun to me to see people's responses to it. Often it's, “I have no idea,” versus the, “Oh, I want to do this, and this is the thing I'm interested in working with you for because I think it'll shore up this, this, and this.” And like, those are two extreme ends of the spectrum. There's no wrong answer, but it's helpful, I find, just to ask the question in the final round interview that I'm a part of, just to, I guess sort of like, boost them a bit into a longer-term picture view, as opposed to next week, next month, next year. Because if what you're doing doesn't bring you closer to what you want to be doing in the job after the next one, then I think you're looking at it wrong, in some cases.And I guess I'll turn the question on to you. If you look at what you're doing now, ignore whatever you do next, what's your role after that? Like, where are you aiming at?Sean: Ignoring the next position… which is interesting because I always—part of how I learned to operate, kind of in my earlier years was focus on the next two weeks because the longer you go out from that window, the more things you can't control, [laugh] and the harder it is to actually make an effective plan. But for me, the real goal is I want to be in any position that enables the hard work we do in building these things to make people's lives easier, better, give them access to additional information, maybe it's joy in terms of, like, a content platform, maybe it's something that helps other developers do what they do, something like Honeycomb, for example, just that little bit of extra insight to help them work a little bit better. And that's, for me, where I want to be, is building things that make the hard work we do to create these tools, these products easier. So, for me, that would look a lot like an internal tooling team of some sort, something that helps with developer efficiency, with workflow.One of the reasons—and it's funny because I got to asked this recently: “Why are you still even in test? You know what reputation this field has”—wrongly deserved, maybe so—“Why are you still in test?” My response was, “Because”—and maybe with a degree of hubris, stubbornly so—“I want to make things better for test.” There are a lot of issues we're facing, not just in terms of tooling, but in terms of processes, and how we think about solving problems, and like I said before, that kind of reactive nature, it sort of ends up kind of being an ouroboros, eating its own tail. Reactive tools generate reactive engineers, that then create more reactive tools, and it becomes this ouroboros eating itself.Where I want to be in terms of this is creating things that change that, push us forward in that direction. So, I think that internal tooling team is a fantastic place to do that, but frankly, any place where I could do that at any level would be fantastic.Corey: It's nice to see the things that you care about involve a lot more about around things like impact, as opposed to raw technologies and the rest. And again, I'm not passing judgment on anyone who chooses to focus on technology or different areas of these things. It's just, it's nice to see folks who are deeply technical themselves, raising their head a little bit above it and saying, “All right, here's the impact I want to have.” It's great, and lots of folks do, but I'm always frustrated when I find myself talking to folks who think that the code ultimately speaks; code is the arbiter. Like, you see this with some of the smart contract stuff, too.It's the, “All right, if you believe that's going to solve all the problems, I have a simple challenge to you, and then I will never criticize you again: Go to small claims court for a morning, four hours and watch all the disputes that wind up going through there, and ask yourselves how many of those a smart contract would have solved?”Every time I bring that point up to someone, they never come back and say, “This is still a good idea.” Maybe I'm a little too anti-computer, a little bit too human these days. But again, most of cloud economics, in my experience, is psychology more than it is math.Sean: I think it's really the truth. And I think that [unintelligible 00:29:06] that I really want to seize on for a second because code and technology as this ultimate arbiter, we've become fascinated with it, not necessarily to our benefit. One of the things you will often see me—to take a line from Game of Thrones—whinging about [laugh] is we are overly focused on utilizing technology, whether code or anything else, to solve what are fundamentally human problems. These are problems that are rooted in human tendencies, habits, characters, psychology—as you were saying—that require human interaction and influence, as uncomfortable as that may be to quote-unquote, “Solve.”And the reality of it is, is that the more that we insist upon, trying to use technology to solve those problems—things like cases of equity in terms of generational wealth and things of that sort, things like helping people communicate issues with one another within a software development engineering team—the more we will create complexity and additional problems, and the more we will fracture people's focus and ability to stay focused on what the underlying cause of the problem is, which is something human. And just as a side note, the fundamental idea that code is this ultimate arbiter of truth is terrible because if code was the ultimate arbiter of truth, I wouldn't have a job, Corey. [laugh]. I would be out of business so fast.Corey: Oh, yeah, it's great. It's—ugh, I—it feels like that's a naive perspective that people tend to have early in their career, and Lord knows I did. Everything was so straightforward and simple, back when I was in that era, whereas the older I get, the more the world is shades of nuance.Sean: There are cases where technology can help, but I tend to find those a very specific class of solutions, and even then they can only assist a human with maybe providing some additional context. This is an idea from a Seeking SRE book that I love to reference—I think it's, like, the first chapter—the Chief of Netflix SRE, I think it is, he talks about this is this, solving problems is this thing of relaying context, establishing context—and he focused a lot less on the technology side, a lot more of the human side, and brings in, like, “The technology can help this because it can give you a little bit better insight of how to communicate context, but context is valuable, but you're still going to have to do some talking at the end of the day and establish these human relationships.” And I think that technology can help with a very specific class of insight or context issues, but I would like to reemphasize that is a very specific class, and very specific sort, and most of the human problems we're trying to solve the technology don't fall in there.Corey: I think that's probably a great place for us to call it an episode. I really appreciate the way you view these things. I think that you are one of the most empathetic people that I find myself talking to on an ongoing basis. If people want to learn more, where's the best place to find you?Sean: You can find me on Twitter at S-C—underscore—code, capital U, capital M. That's probably the best place to find me. I'm most frequently on there.Corey: We will, of course, include links to that in the [show notes 00:32:37].Sean: And then, of course, my LinkedIn is not a bad place to reach out. So, you can probably find me there, Sean Corbett, working at TheZebra. And as always, you can reach me at scorbett@thezebra.com. That is my work email; feel free to email me there if you have any questions.Corey: And we will, of course, put links to all of that in the [show notes 00:33:00]. Sean, thank you so much for taking the time to speak with me today. I really appreciate it.Sean: Thank you.Corey: Sean Corbett, Senior Software Development Engineer in Test at TheZebra—because there's only one. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice along with an angry ranting comment about how absolutely code speaks, and it is the ultimate arbiter of truth, and oh wait, what's that the FBI is at the door make some inquiries about your recent online behavior.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

Chatbot sudah banyak digunakan di berbagai lini bisnis digital saat ini. Bahkan menurut Forbes, ada sekitar 80% pebisnis di dunia yang berencana untuk mulai mengandalkan chatbot demi meningkatkan customer experience dalam bisnis mereka. Salah satu engineer yang hobby membuat chatbot adalah Fauzan Faturahman. SDET (software engineering in test) Mekari ini sudah beberapa kali membuat chatbot untuk berbagai perusahaan di Indonesia. Penasaran soal project chatbot apa aja yang udah dibikin sama Fauzan? Dengarin selengkapnya di Ceritanya Developer kali ini.

Are you thinking of moving from an SDET to SRE? In this episode Evan Niedojadlo, an SRE and former SDET, will share his journey implementing a site reliability engineering process at his company. Discover what went wrong, what you should avoid, key areas to focus on to overcome technical debt, getting executive buy-in, and more. Listen up!

S02E08: ПиSDET не мешки ворочать Hosts: Sergey Pirogov, Yaroslav Pernerovsky Guests: Alexander Romanov, Maxim

Shift left. Continuous integration and continuous delivery (CI/CD). Continuous deployment. DevOps. What is all this stuff and what does it mean for you as the tester? In this keynote, Rex Black will explain these concepts and their test implications. He’ll then describe the emerging role of the SDET (Software Development Engineering in Test, also called SET) and what SDETs do. Yes, being an SDET is about test automation, but it’s about a lot more than that, and Rex will give you some examples of things you can expect to do as an SDET in a shift left world over the coming decade. Don’t worry. Life as a tester in the SDET reality is gonna be fun and exciting, and Rex will give you some ideas how.

Want a way to accelerate your test coverage and eliminate test maintenance? In this episode, Paul Grossman, an SDET at Utopia solutions, and Artem Golubev, Co-founder at testRigor, share a tool that allows you to easily create automation using a behavior-driven plain English approach to writing tests. Learn the benefits of this approach and hear real-world implementation stories of how it has helped others with their test automation.

Pax has been in a QA role for about 6 years. She is a mother of 3 toddlers and majored in art in college. She doesn't consider herself a technical person by nature but worked her way up from the billing department at a web hosting company. Pax explains how she transitioned into tech from an art background, and has proven that there is certainly a place for creative thinkers in this world. Her self-directed journey is inspiring and motivating!This episode is a great follow up to episode 7 (creativity translates to computers) and really started shifting Amber's thinking towards working in a not traditionally creative field. Check out Pax's blog:www.yourcodeisnotgoingouttoday.dev_______________________________________________________Connect with us on Instagram and LinkedIn@hairtotech Episodes filmed and edited by Black Ops AVhttps://www.blackopsav.com/IG @blackopsav

Radim Daniel Pánek je na poli testingu výrazná osobnost. SDET & Performance Tester, zakladatel komunity TEST STACK a CEO start-upu Canarytrace. Pozval jsem si ho, aby sdílel nějakou jeho technickou chybku a taky aby pojednal o tom, co ho třeba štve a chce změnit. Proto Radim mluvil o tom, jak automatizovaně vystřílel do JIRY 300 ticketů pro vývojáře a všechny špatně, dále jak je podle něj testing 8 let za vývojem a proč je obecně testing dnes taková dojná kráva na peníze. No.. Příjemný poslech!

Have you heard of ScalaTest? In this episode, Zubair Haque, a senior SDET, will share what ScalaTest is and how it can help you with your API microservices automation testing. Discover a way to create clear tests and executable specifications to improve your code and communication. Listen up!

Do you need a plan to performance test your microservices? In this episode, Zubair Haque, a senior SDET, will share his approach to adding performance tests to his team's software delivery pipeline. Listen in for real-world examples of using Scalatest & Gatling to test and measure the performance of REST services. Check it out!

Ведущий: @kalashnikovisme ( vk.com/kalashnikovisme ) Гость выпуска: @sweet_staisy ( https://vk.com/sweet_staisy ) ************* Темы выпуска: ************* Распрашиваем гостя * Кто такая и как до такой жизни докатилась? * Кто такой QA-специалист? * Сертификация ISTQB * Как получают сертификаты? * Что такое тест-дизайн? * Что делать, если требований нет? * Про предметные области программных продуктов * Как выглядит документация в QA? * Как аргументировать заказчику, что тестирование нужно? * Из чего состоит рабочий день QA специалиста? * Что такое автотесты? * Что такое SDET? * Какие особенности тестирования разных типов программных продуктов? * Зачем идти работать в QA? **************** Ссылки от гостя: **************** * https://software-testing.ru/ - олдскульное базовое тестирование * ISTQB ( https://www.istqb.org/downloads/syllabi/foundation-level-syllabus.html ) * Статья Насти Карасёвой про аудит ( https://www.simbirsoft.com/blog/kak-gramotno-i-effektivno-razvivat-programmnyy-produkt/ ) * К сожалению, Паша смотрел курсы IT Place SimbirSoft прошлого года. В данный момент сайт IT Place Simbirsoft не доступен, а анонсов курсов нет ------------------------ Подписывайтесь на IT Way ------------------------ * ВКонтакте ( https://redcircle.com/shows/5a51ca0b-c930-480a-85f4-94a5f2190530/episodes/vk.com/it_way ) * Чат в Telegram ( https://redcircle.com/shows/5a51ca0b-c930-480a-85f4-94a5f2190530/episodes/teleg.run/it_way_chat ) * Twitter ( https://redcircle.com/shows/5a51ca0b-c930-480a-85f4-94a5f2190530/episodes/twitter.com/it_way_pro ) * Instagram ( https://redcircle.com/shows/5a51ca0b-c930-480a-85f4-94a5f2190530/episodes/instagram.com/it_way.pro ) * Youtube ( https://www.youtube.com/channel/UClMIzLwthrV-ph1sktlxu_A )  Музыка: инструментал песни M.G. - Абсурд, студия Alpha Records ( https://vk.com/alpharecords73 )

How does "shift-left" actually work in real life? What kind of role can and should developers play in the testing process? In this episode, we learn about the role software developers can play in the QA process with Arun Kumar, Vice President of QA at JPMorgan Chase & Co.

Are you looking to work on your tech skills to make you more employable? Or think an SRE role might be the perfect fit for your next career move? In this episode, Evan Niedojadlo shares how he transformed his career from an SDET to an SRE. Discover tips, tools, and inspiration to help you make the move to an SRE role.

What can performance engineers learn from the principles of functional test automation? In this episode James Walker, an SDET at Curiosity Software will share modeling and data tips that most might associate with functional testing, but can be applied to performance testing as well. Listen to discover why test data is so critical for creating more realistic performance tests.

Гости: - Александр Романов - главный SDET - Андрей Закордонец - заморский SDET Темы: - 00:00:39 - Начало - 00:01:51 - Про подход в целом - 00:34:15 - Про тулы - 00:42:17 - Контракты в GraphQL - 00:47:43 - Про плюсы - 00:57:02 - Про сложности внедрения - 01:00:32 - Про минусы - 01:22:23 - Патроны - 01:24:57 - Прощание Telegram: t.me/automation_remarks Стать патроном: www.patreon.com/automation_remarks Доп инфо: https://docs.pact.io/ https://spring.io/projects/spring-cloud-contract Спасибо патронам: Mykola Podolianiuk, Miguel Suddya, Tetiana Hrybok, Marat Reymers, Nikita Verbitsky, Ирина Юрчук, Valentin Buryakov, Roman Marinsky, Anastasiya Mazheika, Evgenii Gritsai, Перетятько Игорь, Nikolay Georgievskiy, Serge Soloshchenko, Igor Gruziev, Maryna Kolesnik, Alisa Markova, Volodymyr Stankov, Olena Kulik,Kuptsov Ivan, SIvanov, Арина Аригри, Maxim Denisov, Oleksandr Shapovalov, Alex Hramovich, Vitalii

Гости: - Александр Романов - паленый SDET - Максим Колотилкин - просто SDET Темы: - 00:00:22 - Интро - 00:02:07 - О гостях - 00:04:38 - Кто такой Automation QA - 00:13:48 - Кто такой SDET - 01:28:59 - Как стать Сдедтом - 01:39:52 - Патроны - 01:41:47 - Финал Telegram: t.me/automation_remarks Стать патроном: www.patreon.com/automation_remarks Спасибо патронам: Tetiana Hrybok, Marat Reymers, Nikita Verbitsky, Natalka Sokurenko, Ирина Юрчук, Valentin Buryakov, Roman Marinsky, Anastasiya Mazheika, Перетятько Игорь, Nikolay Georgievskiy, Serge Soloshchenko, Katya Kravchenka, Igor Gruziev, Maryna Kolesnik, Dmytro, Alisa Markova, Roman Pobotin, Volodymyr Stankov, Арина Аригри, Miguel Suddya, Maxim Denisov, Oleksandr Shapovalov, Evgenii Gritcai

.NET 5 has been announced and brings a new unified future to the platform. We dig in to Microsoft's plans and speculate about what they might mean for F#. Plus the value of manual testing, Visual Studio Code Remote, and Conway's Game of Life in Rust.

Záznam z epického !!! livestreamu je venku ;-) Co znamená SDET a co Test Architekt? Co každá z rolí znamená a není to náhodou to samé? Dost zajímavé téma a na konci rozuzlení pod přísnou mentorskou hůlkou Tomáše přináší tento díl. Bavte se :-) Líbí se vám naše práce a chcete nás podpořit? https://www.patreon.com/teststack Zřídili jsme veřejný Slack pro #ProTest_cz komunitu https://protestcz.slack.com YouTube https://www.youtube.com/playlist?list=PLZaZq-LUymhx3Lip30OGmsMPdAVoNl45i iTunes https://itunes.apple.com/cz/podcast/test-stack/id1344559184?l=cs&mt=2 Instagram www.instagram.com/rdpanek/ Twitter twitter.com/RDPanek LinkedIn www.linkedin.com/in/rdpanek

Гости: - Сергей Пирогов - заводила подкаста - Дмитрий Гуменюк - главный в Репорт портале - Артем Никитин - видит забугорное IT - Рома Маринский - львовский IT пан Темы: - Conventional Commits[https://www.conventionalcommits.org/] - Тренды в тестировании 2019[https://medium.com/@sarahelson81/testing-trends-to-look-out-for-in-2019-df938a6eba49] - Validate your Jenkinsfile from within VS Code[https://jenkins.io/blog/2018/11/07/Validate-Jenkinsfile/?utm_source=feedburner&utm_medium=twitter&utm_campaign=Feed%3A+ContinuousBlog+%28Jenkins%29] - Selenium to Rest-assured adapter[https://www.mwtestconsultancy.co.uk//selenium-to-rest-assured-adapter] - Kafkacat[https://github.com/edenhill/kafkacat] - SDET vs Tester[https://www.joecolantonio.com/sdet/] Релизы: - allure 2.8.0[https://github.com/allure-framework/allure-java/releases/tag/2.8.0] - junit 5.3.2[https://junit.org/junit5/docs/5.3.2/release-notes/] - selenide 5.0.1[https://ru.selenide.org/2018/11/07/selenide-5.0.1/] Поддержите нас на патреоне www.patreon.com/automation_remarks

Гости: - Сергей Пирогов - заводила подкаста - Ярослав Пернеровский - бог звука в подкасте - Артем Задорожный - работает в германии, занимается развитием людей Темы: - Зачем вообще расти? -Кто такой QA это процесс или человек? - Почему вдруг QA - это плохо и надо расти в какие-то AQA, SDET и прочую чепуху? - Как развиваться? - ПДП формы и план на пол года. Работает оно вообще? - Платформа MTDV, чем она поможет?

A great discussion highlighting a phenomenal journey. From Oklahoma good 'ol boy to an SDET at one of the biggest gaming companies in the world, Wizards of the Coast. The subtitle, "You Don't Really Know", comes from how much Janson and I talk about taking risks, changing directions and taking opportunities. An amazing session and I really look forward to talking with Janson again; hopefully you do to! Intro & Outro Music provided by Brian Woods. Check him out on Instagram at https://www.instagram.com/over.and.out_/ Drop by his band's bandcamp as well: https://ymditd.bandcamp.com/releases --- Support this podcast: https://anchor.fm/thesummoninghour/support

This episode's question: Someone on my team just got offered a promotion to a different job title; currently he is an QA analyst but has been operating as an SDET. He interviewed for and was accepted for an SDE position (not SDET) on our mobile team. The offer they gave him is roughly 20k below industry average but since he already works here he seems to be in a harder place to negotiate, any ideas? Links from this episode: Titles Are Important by Dawn

We continue our conversation with Angie Jones about ways that automation can be put first in stories (yes, really) and ways that she has been able to get team buy in and cooperation to make that process effective. Also, we have a mailbag question that we answer in depth, or as much as we can… is it possible to be paid as much as a developer or an SDET if you are just a manual tester? The answer is “it depends”, but we go into a lot more about why that is the case. Resource by QualiTest Group

Agile tester extraordinaire Lisa Crispin is back for another round with Agile Amped. This time she's talking about her presentation at Mile High Agile "Agile Testing to Build the Right Thing" (co-presented with JoEllen Carter). She also touches on some trends that she sees, some positive (e.g., people in the Agile field are recognizing testers as really valuable), others not so much (companies expecting that hiring an SDET will solve all their code quality problems).  Lisa Crispin is the co-author of More Agile Testing: Learning Journeys for the Whole Team (2014, with Janet Gregory), Agile Testing: A Practical Guide for Testers and Agile Teams (2009, also with Janet Gregory), co-author of Testing Extreme Programming (2002, with Tip House). Lisa enjoys working as a tester and sharing her experiences in the agile and testing communities. See our last podcast with Lisa here: http://www.solutionsiq.com/resources/... SolutionsIQ's Howard Sublett hosts. About Agile Amped The Agile Amped podcast series engages with industry thought leaders at Agile events across the country to bring valuable content to subscribers anytime, anywhere. To receive real-time updates, subscribe at YouTube, iTunes or SolutionsIQ.com. Subscribe: http://bit.ly/SIQYouTube, http://bit.ly/SIQiTunes, http://www.solutionsiq.com/agile-amped/ Follow: http://bit.ly/SIQTwitter Like: http://bit.ly/SIQFacebook

We chatted with Bioware's Allan Schumacher on what SDET actually means, diversity in the industry, what life is like on the QA side of the house and interacting with fans.