- [Instructor] One of the most important decisions
you'll have to make for your project
is how to handle testing.
In this section, we'll explore some of the options
that work best with Agile development.
The first and I think the best way
to test a software project,
especially in an Agile environment,
is of course to use test-driven development.
We talked about this earlier,
and I always default to this because automating your code
and interface testing will save you boatloads of time
down the road.
If you're able to go with this route,
you just need to adjust your sprint workloads
to account for the extra test suite development time.
You don't necessarily have to create user stories
for testing, just adjust the sprint expectation.
That being said, time, platform and resource constraints
are going to make that option difficult or impossible
for some teams.
On the flip side of the testing coin is manual testing.
Now this can be done by your client, by your stakeholders,
a dedicated quality assurance team,
or more than likely by the developers themselves.
With Agile iterations though, things can get tricky.
For one thing, if you're manually testing,
you need to have dedicated testers
and/or a testing time set aside during each sprint.
This means less time for development,
and sometimes because of that, I see Agile teams
leaving manual testing until the last minute
or after the application is mostly finished.
If you're used to doing things waterfall style,
you'll know that this racks up a ton of technical debt
and usually leads to missed deadlines
and/or lots of overtime before release.
Technical debt just refers to how much time
you'll eventually have to put in because of deferred tasks.
Whichever testing regimen you choose,
it's important to get into the mindset
of thinking about testing as a sprint priority.
"Agile Testing: A Practical Guide for Testers
and Agile Teams" is wonderful
if you're looking for a good resource on this topic.