Test-Driven Software Development

Loading...

Do curso por University of Virginia

Testing with Agile

255 classificações

Explore Related Videos

At Coursera, you will find the best lectures in the world. Here are some of our personalized recommendations for you

University of Virginia

Testing with Agile

255 classificações

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 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.

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

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 test-ably 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.

Our cost has escalated throughout this process.

This is the most expensive part,

building and ultimately maintaining software.

Now, 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 were 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 will be delivered to them in their natural environment,

so that we're able to ask relevant questions and form

good emphatic testable hypotheses about usability.

We do parallel prototyping,

we A&B test are prototype's 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 or ambiguous enough at least at the get-go to develop software against.

Once we're doing, 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 might 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 then we just look at does it fail.

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

operations or sysadmin and those are some

of the functions that are most pivotal to this movement of DevOps,

which is a cultural movement that has to do with taking the Silo'ed IT,

rather the Silo'ed practice of development testing and operations,

and rather pushing towards interdisciplinary teams,

that work together on their delivery pipeline.

It's an exciting time I think,

because companies like Facebook are delivering code to production multiple times a day,

which I just think is so incredible.

I think that those teams must benefit so much from learning so quickly,

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

The way 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 a new code is committed by a developer,

and the end of the pipeline is,

we're delivering software out to users,

actual real users and production.

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

we're delivering it to some real-life users.

The things that we do, as we go through this are,

we do good unit test coverage.

These are the atomic individual tests that test very discrete functions in

the software integration tests test the way functions interact with each other,

and other subsystems like databases.

Then the system tests are where our prior work is particularly important,

because they help us understand what kind of happy path to test

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.

We really want to know, we want a lot of focus about what we should test.

We may have some manual validation and then we release.

Really, the key thing here is you want to

avoid hand-offs and you want to maximize automation.

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 is our process look like here?"

Even if it's manual or not,

no where we want it to be.

Let's think about what it is right now and

then like let's make a top three lists for example,

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

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.

© 2019 Coursera Inc. Todos os direitos reservados.

Baixar na App Store

Baixar no Google Play