filmov
tv
Do you Need UAT in Agile?
Показать описание
Do you Need UAT in Agile?
From: Agile Podcast 30 - User Acceptance Testing in Agile
Watch the full Podcast here:
= = = = = = = = = = = =
Please Subscribe to our YouTube Channel:
= = = = = = = = = = = =
Apple Podcasts:
Google Podcasts:
Spotify:
Amazon Music:
Stitcher:
= = = = = = = = = = = =
UAT in the agile space, is it even needed?
Well I think if you're looking at software deliverables, they tend to be complex in nature for the most part. and if you're, developing these things over time, or multiple teams are contributing to a solution and you don't do a UAT,
A, you're not testing things at the integration level and the bigger part of this, because we're talking about U a T, right. You're not involving the users who ultimately will be accepting your system. Yeah. I was in a small company and they didn't do UAT. at all was a small company. So obviously the rules are a little bit different.
Cause in the small company, , we would either have, , people who directly represented the user, which can be dangerous. Cause then you get people getting in front of, , requests, , or, , you just bring the user directly to the sprint review and they get the, see the feature. And if you let the user drive, they get to play with it right then and there. ,
now you're right. They're testing a very small subset of functionality. They're not inside of the entire ecosystem.
yeah, but, but at least you're involving the user, which is great because it drives engagement, but I'm just starting to think, how would Boeing do a UAT when they come out with a new aircraft?
It isn't a one shot deal in that kind of, example because. You don't know how many systems go into building a plane so there's integration testing going on throughout. And of course every level is backward compatible. So you have to do an integration test every time, a variable changes.
I would imagine in the example of Boeing, it's easy to also apply that example to like, , the car manufacturing, if you're just changing one thing, if you're just changing the steering, you'll get their car, change the steering, give them their car back and say,
Hey, come down to my shop or my warehouse or whatever, and drive around a lot, make sure you like it try it out before we put the hubcaps back on. I don't know. Yeah.
So yeah, if you're just changing one thing, but are you, are you changing one thing in isolation or are you affecting something else by virtue of you haven't changed that? Yeah. So you're changing the, changing the wheel of the steering or whatever, but maybe you have an impact. There's something else that's going on.
Right. So fly by wire steering. Let's say, but yeah, by changing one variable and kind of saying test this it's very tricky.
From: Agile Podcast 30 - User Acceptance Testing in Agile
Watch the full Podcast here:
= = = = = = = = = = = =
Please Subscribe to our YouTube Channel:
= = = = = = = = = = = =
Apple Podcasts:
Google Podcasts:
Spotify:
Amazon Music:
Stitcher:
= = = = = = = = = = = =
UAT in the agile space, is it even needed?
Well I think if you're looking at software deliverables, they tend to be complex in nature for the most part. and if you're, developing these things over time, or multiple teams are contributing to a solution and you don't do a UAT,
A, you're not testing things at the integration level and the bigger part of this, because we're talking about U a T, right. You're not involving the users who ultimately will be accepting your system. Yeah. I was in a small company and they didn't do UAT. at all was a small company. So obviously the rules are a little bit different.
Cause in the small company, , we would either have, , people who directly represented the user, which can be dangerous. Cause then you get people getting in front of, , requests, , or, , you just bring the user directly to the sprint review and they get the, see the feature. And if you let the user drive, they get to play with it right then and there. ,
now you're right. They're testing a very small subset of functionality. They're not inside of the entire ecosystem.
yeah, but, but at least you're involving the user, which is great because it drives engagement, but I'm just starting to think, how would Boeing do a UAT when they come out with a new aircraft?
It isn't a one shot deal in that kind of, example because. You don't know how many systems go into building a plane so there's integration testing going on throughout. And of course every level is backward compatible. So you have to do an integration test every time, a variable changes.
I would imagine in the example of Boeing, it's easy to also apply that example to like, , the car manufacturing, if you're just changing one thing, if you're just changing the steering, you'll get their car, change the steering, give them their car back and say,
Hey, come down to my shop or my warehouse or whatever, and drive around a lot, make sure you like it try it out before we put the hubcaps back on. I don't know. Yeah.
So yeah, if you're just changing one thing, but are you, are you changing one thing in isolation or are you affecting something else by virtue of you haven't changed that? Yeah. So you're changing the, changing the wheel of the steering or whatever, but maybe you have an impact. There's something else that's going on.
Right. So fly by wire steering. Let's say, but yeah, by changing one variable and kind of saying test this it's very tricky.