Let's take a look at a typical intermediate developer workflow that includes a number of the techniques and technologies we'll examine in this course.
Dates | Topic | Task | Due |
---|---|---|---|
May 11th | What is quality? What is Assurance? | Lab 1 | |
May 18th | Ad Hoc Testing | Lab 2 | |
May 25th | Design Patterns & Methodologies | ASN1 | Lab 3 |
June 1st | Modern JavaScript | ASN1 (Part 1) Lab 4 | |
June 8th | Version Control & Code Reviews | ASN2 | ASN1 (Part 2) Lab 5 |
June 15th | NodeJS | Group Assignment | ASN2 |
June 22nd | Testing frameworks | Group Assignment | |
June 29th | Reading Week | ||
July 6th | Test Plans | Lab 6 | |
July 13th | How to get hacked | Lab 7 | |
July 20th | How to not get hacked | ASN3 | |
July 27th | Encryption & Hashing | ASN3 Lab 8 | |
August 3rd | Task runners | ASN4 Final Assignment | Lab 9 |
August 10th | Web Components | ASN4 | |
August 17th | Final Review | Final assignment |
June 29th | Reading Week |
July 6th | Test Plans | Lab 6 | |
July 13th | How to get hacked | Lab 7 | |
July 20th | How to not get hacked | Assignment 3 | |
July 27th | Encryption & Hashing | Assignment 3 Lab 8 | |
August 3rd | Task runners | Assignment 4 Final Assignment | Lab 9 |
August 10th | Web Components | Assignment 4 | |
August 17th | Final Review | Final assignment |
Disclaimer: This is a short story, not a documentary. In a team that followed all of the following quality assurance practices (and not every team does), this process would probably happen over a week, and many of the examples below (i.e. penetration testing) are only done on "special occasions". The purpose of this is to show as complete a workflow as one might encounter.
A developer sips their coffee. They lean back and look over their code.
It looks good. ES6 constants Opens in a new window means their variables can't be overwritten. BEM Opens in a new window makes sure their styles are targeting only the intended feature.
They're writing javascript in strict mode Opens in a new window, adding an extra layer of scrutiny, but creating javascript objects was a breeze due to a constructor Opens in a new window they'd used to set defaults. Variables and methods are safely scoped within a module pattern Opens in a new window.
They are confident. Linters Opens in a new window have been checking their code for errors and style while they worked, thanks to their task runner Opens in a new window (with the odd copy-paste into JSHint Opens in a new window to help debug). Unit tests Opens in a new window (some of which they wrote before they started coding Opens in a new window this feature) look at their individual functions. Pretty easy to read, thanks to their assertion library Opens in a new window. No need to worry about the API call thanks to their stubs Opens in a new window.
Before they push their code, it's time for a quick smoke test Opens in a new window of the pages they worked on. They run Lighthouse Opens in a new window to check performance and best practices, axe DevTools Opens in a new window for accessibility, device emulation Opens in a new window to check responsiveness, and a link checker Opens in a new window to, you know, check their links. They throw some weird text into their input fields to check validation. All good.
With a deep breath, they push their code to the git repo, where the automated tests will do a deep-dive on their code. They've added their unit tests to a suite of testing that makes sure nothing gnarly gets successfully built - more unit tests, integration tests Opens in a new window, maybe even browser automation Opens in a new window or visual regression Opens in a new window.
It passes! With 100% coverage! Opens in a new window Now it's time for code review Opens in a new window - the opportunity for another dev to say, "this is kinda overengineered, isn't it?", or simply, I love it! Opens in a new window
With the pull request approved, the branch is moved onto the testing server. Now it's on to the QA team for black-box Opens in a new window
functional testing Opens in a new window where the application gets used on a plethora of real devices.
If anything comes up, it will be logged in the bug tracker Opens in a new window, a ticket will be issued, and a developer assigned. But today is a good day - no bugs!
Next, it's on to the staging server. Load testing Opens in a new window checks for performance issues (and vulnerability to as DDoS Opens in a new window attack). UAT Opens in a new window gives the client a chance to change their mind about everything, before being reminded that it will cost them money to ignore the requirements they agreed to. Everything looks good to launch!
Or it would be, on a normal day...
This isn't a normal day, though - some big features are in the works! A new login process and a secure chat application are both in the pipeline. Since the stakes are high, a team of security experts has been engaged to pentest the application.
Is the SSL certificate Opens in a new window valid, thus enabling shared session keys and encrypted communication, thereby protecting against man-in-the-middle Opens in a new window
attacks? Have inputs been sanitized to prevent SQL injection Opens in a new window? Have the HTTP headers Opens in a new window been set properly to avoid XSS attacks Opens in a new window? Has OAuth Opens in a new window been implemented properly to securely log users in and out? Is the Crypto API Opens in a new window encrypting chat messages, with identities confirmed via HMAC Opens in a new window? Are JSON web tokens Opens in a new window used responsibly? Has the team rolled their own hashes with MD5 Opens in a new window or SHA-1 Opens in a new window? If so, do they know what they're doing?
The list keeps going, but they find no vulnerabilities! Finally, the team is able to launch to production, where the devOps managers will monitor performance in a live environment.
Users are now free to use the application until the following day when the user replies to a phishing Opens in a new window email, generously providing their username, password and date of birth.