Bummer! This is just a preview. You need to be signed in with a Basic account to view the entire video.
Bringing Quality Upstream5:05 with Ryan Saul
QA is usually seen as being the very last piece of the development puzzle, something you do right before releasing the product to the public. But it doesn’t need to be! Putting QA earlier in development can save you time and money by finding defects before they’re even written.
Coverage Report example
Version 1.0.0 Release Coverage Report
- Login - 100% automated tests
- 2 tests
- 2 automated
- 2 tests
- Creating Cards - 60%% manual tests | 20% automated tests | 20% untested
- 5 tests
- 3 manual tests
- 1 automated test
- 1 untested feature
- 5 tests
- Printing Cards - 100% untested
- 0 tests
Escaped Bug Report example
Version 1.0.0 Escaped Bug Report
|Bugs found in Regression Testing||10|
|Bugs fixed before Release||9|
|New bugs found by customers||3|
User Feedback Report example
Version 1.0.0 User Feedback
Positive feedback: 90
Negative feedback: 10
Other feedback: 3
- "Great UI!"
- "Why can't I send a link to my friend?"
- Test Driven Development: The process of writing unit tests before writing the code.
- Code Reviews: Developers reviewing each other's code before merging it.
- Continuous Integration: The practice of always running all automated tests each time new code is checked in. Can be further expanded by only deploying software through this system after all checks pass.
Travis CI: https://travis-ci.org/ (works great with GitHub!)
This is our final video, we made it.
And it happens to be one of my favorite topics in the world of QA.
This is a subject called bringing quality upstream.
The main idea here is that QA is usually seen as being the very last
piece of the development puzzle.
Something you do right before releasing the product to the public.
But it doesn't need to be.
I believe that putting QA earlier in the development process can save you
a lot of time and money by finding defects before they're even written.
Okay, so lets demonstrate what I mean here.
In a typical development process we have planning, followed by development,
then testing, and finally release.
In our example the people in charge of planning decide that we need to add
a button that appears over the screen to ask the user if they would like to
subscribe to a newsletter.
Development takes this idea and implements it.
It gets down to testing and we discover that the button squashes everything
on the webpage to the bottom of the page, which just looks terrible.
Development works on a fix and it gets back to testing.
Everything looks good from the QA side.
There's a button at the top of the page and nothing is getting squashed.
But the people who planned this feature take a look and
realize that it's also not what they wanted.
They wanted a button to go over everything else on the site.
We push this feature back to development.
They work on a totally new way to show the button and
it finally shows up in testing a couple days later.
QA approves it and it gets released.
Wow, that was a lot of wasted time though.
What would have been good is if we talked about what the button should look like
up at the planning stage.
And then maybe have some people recheck it along the way.
There are some pretty simple ways we can solve these issues
by bringing quality assurance up stream.
First is putting everyone involved in the planning session.
QA and developers get a chance to ask technical and design related questions.
Is the button just at the top of the screen or
is it going to be over all of the other buttons.
This saves us a lot of time spent reworking the entire feature.
Then when development is ready, they should review the code with other
developers and testers to look for problems with it.
It turns out that there was a simple issue with the code that another developer
spotted during the review.
Sure, we are involving more people in the early stages of development.
But when we look at both the amount of time spent between a bunch of
people versus the amount of time it took to release a simple feature,
the time saved is huge.
Of course, not every situation is going to be solved this way.
But the point is to lower the amount of backtracking that we typically do.
To me, this also feels like a much more agile software development experience.
Let's go over some simple tricks you can do to bring quality upstream.
Join planning and design discussions.
This will help expose potential technical problems early and
help smooth out user experience problems.
QA engineers have a great sense of how the app gets used so
why not be a resource when planning the next features.
You can also bring existing user data and feedback to provide more
insight into how users might actually interact with these features.
Make code reviews mandatory.
Before a developer checks in code they should be required to have at least one
other developer review the code.
This catches a lot of simple problems before they ever get introduced.
Encourage more testing within the development process.
Get developers to write unit tests alongside their code.
Set up a continuous integration server to run before the code gets to QA.
This will run automated tests before they ever get to manual testing.
This will prevent bad builds from being tested and wasting time in QA.
See our notes for links to Jenkins and Travis CI,
which are popular tools for doing continuous integration.
Test driven development is also a great way of bringing quality upstream.
This is a way of making sure that your developers are always
trying to build unit tests as part of the development process.
It often takes more work and a little practice, but
it's a wonderful tool to ensure quality code is getting deployed.
Treehouse offers a course in unit testing and
test driven development for more on this topic.
Well, that's it for our QA engineering course.
I hope you've enjoyed this topic as much as I have teaching it.
Quality is a very broad category with many different ways of getting the job done.
But it's also essential to making sure that our customers and
users are happy with the software.
Testing is not just a nice thing to do, it's required.
Thanks for watching.
You need to sign up for Treehouse in order to download course files.Sign up