Test-Driven Software Development

Loading...

Do curso por University of Virginia

Testing with Agile

197 ratings

University of Virginia

Testing with Agile

197 ratings

Curso 4 de 5 em Specialization Agile Development

To deliver agile outcomes, you have to do more than implement an agile process; you have to create a culture of experimentation. It's this commitment to experimenting that's at the heart of a high-functioning practice of agile. This course shows you how to integrate the practice of experimentation across concept/feature testing, usability testing, and testing the software itself. Basically, you’ll learn how to answer these four big questions with experiments: 1. Should we build it? 2. Did it matter? 3. Is it usable? 4. Did it break? More specifically, after completing this course, you’ll be able to: - Identify where and how to invest your team’s scarce time and energy into better testing for maximum impact on outcomes - Coach your team on the relationship between idea, usability, and software testing to get the buy-in you need for strong interdisciplinary collaboration - Test ideas before you build them to avoid waste and help your team focus on what will really drive outcomes - Test alternative interface patterns before you build them to maximize both product usability and purposeful implementation - Understand your delivery pipeline and how to prioritize process and infrastructure improvements so you can deliver faster and more often As a Project Management Institute (PMI®) Registered Education Provider, the University of Virginia Darden School of Business has been approved by PMI to issue 20 professional development units (PDUs) for this course, which focuses on core competencies recognized by PMI. (Provider #2122) This course is supported by the Batten Institute at UVA’s Darden School of Business. The Batten Institute’s mission is to improve the world through entrepreneurship and innovation: www.batteninstitute.org.

Na lição

Does it break?

You’ve learned how to test ideas and usability to reduce the amount of software your team needs to build and to focus its execution.Now you’re going to learn how high-functioning teams approach testing of the software itself. The practice of continuous delivery and the closely related Devops movement are changing the way we build and release software. It wasn’t that long ago where 2-3 releases a year was considered standard. Large firms like Facebook now release new code multiple times per day. In this module, we’ll look at the delivery pipeline and step through what successful practitioners do at each stage and how you can diagnose and apply the practices that will improve your implementation of agile.

Test-Driven Software Development5:54

The Team that Releases Together4:01

The Continuous Delivery Pipeline8:40

Getting Started with Continuous Delivery3:26

Anders Wallgren on the Advantages of Continuous Delivery3:27

Anders Wallgren on Getting Started4:14

Conheça os instrutores

Alex Cowan
Faculty & Batten Fellow
Darden School of Business

Here we are at the most exciting and

also the most expensive part of the development process.

We're going to build software.

And here, we're going to ask this question, does it break?

And we're going to answer it so that we can deliver software frequently and

learn quickly.

So we are confident that we can do a little bit, learn and

then figure out where we should invest our resources next.

And so that we can develop code and refactor it with confidence.

Now, at this point, we've narrowed our options because it

is very expensive to build software and

the worst thing you can do is just throw in the kitchen sink.

We want to be specifically right or specifically wrong,

testably wrong about what we're doing.

So we don't end up with some feature that one person uses and

we have to go to the expense of maintaining.

And our cost has escalated throughout this process.

This is the most expensive part, building and ultimately maintaining Software.

So how do we answer this question of, does it break successfully?

Basically the first step is to do everything we've already talked about,

surprise surprise.

We go through, make sure we know who is our user, what's on their A list?

Let's not solve problems that they either don't have or

where the alternatives are really great.

We find an alternative that is not so great.

Let's formulate a testable idea about what we might do that's better than that

alternative and let's actually test that before we go off and

over invest in software.

And then we have a nice, strong input into our usability process,

which is that we understand this value proposition.

Both whether or not the user is sufficiently motivated and also how it'll

be delivered to them in their natural environment so that we're able to ask

relevant questions and form good emphatic testable hypothesis about usability.

We do parallel prototyping, we A and B test our prototypes frequently and often.

And we don't do big design up front, but we do drive to specifics amongst

our team as a place to drive to something that is both economical and clear enough,

unambiguous enough at least at the get-go, to develop software against.

So that is where so much of the money is wasted.

And so much effort can go to complete waste on the software side if

we don't do at least a reasonable execution of these other questions.

Now our hypothesis in this area may look something like well if we make a certain

code change, the system won't fail, or we want to know whether or

not the system will fail.

So ideally, we have a lot of automation around building and

testing because that allows us to test often and test with confidence and avoid

the sort of drudgery and the time trap of investing in a lot of manual testing.

And we look at, does it fail?

This is an exciting time for the junction of delivery and testing and

operations or sys admin.

And those are some of the functions that are the most pivotal to this movement

of devops.

Which is a cultural movement that has to do with taking the SILO'ED IT and

rather the SILO'ED practice of development testing in operations.

And rather pushing towards interdisciplinary teams that work together

on their delivery pipeline.

And it's an exciting time I think because companies like Facebook are delivery code

to production multiple times a day, which I just think is so incredible.

And I think that those teams must benefit so

much from learning so quickly and being so quickly and

being able to execute with such confidence that they can deliver software this way.

The way that we get there is we look at our delivery pipeline.

If you're delivering continuously, which is this automated deploying of

code multiple times a day this might be called the continuous delivery pipeline.

The idea is that the pipeline begins whenever new code

is committed by a developer and the end of the pipeline is we're delivering software

out to users actual real users in production.

Even if we're not delivering it to all production we're delivering it

to some real life users.

And the things we do as we go through this are we do good unit test coverage.

And these are the atomic individual test that,

test very discreet functions in the software.

Integration test, test the way it functions interact with each other and

other sub-systems like databases.

And then the system tests are where our prior work is particularly important

because they help us understand what kind of happy past to task at the system level.

And allows us to prioritize that work so that this is probably, generally speaking,

the most expensive and most kind of breaky part of the testing.

And we really want to know, we don't have a lot of focus bout what we should test.

We may have some manual validation and then we release.

And really the key thing here is you want to avoid hand offs and

you want to maximize automation.

And it's great to say, hey, this is what teams do and it's exciting.

My advice, and this is what you'll learn how to do over the course of this module,

is just understand what practices are in place today.

And talk with your team about, hey, what does our process look like here?

Even if it's manual or not where we want it to be,

let's think about what it is right now.

And then let's make a top three list, for example,

of things that we could do that would make it even better.

And so regardless of where you are on your process of continuous delivery,

I think you'll get some valuable perspective and some specific ideas that

you can use to apply to this question of does it break, to both improve.

How reliably and how much it costs you to deliver software and

also just cultivate that culture of experimentation.

Explore nosso catálogo

Registre-se gratuitamente e obtenha recomendações, atualizações e ofertas personalizadas.

O Coursera proporciona acesso universal à melhor educação do mundo fazendo parcerias com as melhores universidades e organizações para oferecer cursos on-line.

© 2018 Coursera Inc. Todos os direitos reservados.

Baixar na App Store

Baixar no Google Play