Lecture 4 - The Software Development Life Cycle -> Quick Intro -> Idea -> Product Design -> Coding: Part 1 -> Coding: Part 2 -> Testing And Bug Fixes -> Release
We are going to cover a lot about this stage during the rest of our Course. So, for now, let’s be as laconic as Spartans.
After the developers have finished writing the code, the release engineers make it available for the testers in the test environment (https://main.sharelane.com). The testers perform a quick smoke test (also called a sanity test or confidence test) to check if the software is testable.
Example
If we cannot log into the account on main.sharelane.com, we simply cannot proceed with test execution, i.e., the software is not testable.
As a rule, a smoke test doesn’t take more than half an hour, and it usually doesn’t require any special test cases.
If the smoke test fails, we communicate this to the programmers and release engineers (there can be an error on the release engineering side), and they work to fix the problem. Once the problem is fixed, we perform the smoke test again. This mini cycle takes place until the smoke test passes. Once the smoke test passes, the release engineers freeze the code and push it to the test environment (main.sharelane.com), and the testers start the new feature testing by executing test cases written for this release.
Brain positioning
“Feature” is a much wider term than “functionality” which we’ve been using so far. Functionality is the ability to accomplish some task. For example, the functionality (ability) of a bottle opener is to open bottles.
Depending on the context, the term “feature” means
– the ability to accomplish some task or
– some characteristic of the software.
For example,
– the Shopping Cart can be called both a “feature” and “functionality”, because it is an ability that allows users to store items they want to buy.
– the color of the Shopping Cart link can be called only a “feature”, because the color of that link
>is a characteristic of the software and
>it does not have functional (i.e., task-solving) aspects.
When in doubt, use the term “feature.”
BTW
A favorite developer’s expression, “It’s not a bug, it’s a feature”, in human language sounds like, “That something is not a problem with my code. It works (and/or looks) exactly as I want.”
After the new feature testing is finished, the testers start to test the old features. This type of testing is called regression testing. Regression testing is performed to check if code modifications made for this release have broken something in the old features. After we are finished with new feature testing for our release 2.0, we are going to use our test cases written for release 1.0 for regression testing.
BTW
Does this mean that during regression testing for release 25.0, we have to execute all test cases from releases 1.0 to 24.0 inclusively?
Well, this is one of the most difficult questions in testing, and we’ll address it later.
Found bugs are filed into the bug tracking system, the programmers fix them, and the testers verify those fixes.
Once the regression testing is finished (there is usually a concrete deadline), testers perform an acceptance testing (also called a certification testing). During acceptance testing, the testers:
– execute a special set of P1 test cases (often in form of checklists)
– do ad hoc testing (undocumented testing based on intuition and inspiration)
Sometimes, when a young start-up has an important release (e.g., its first release), the whole company stays overnight to do acceptance testing.
Once the acceptance testing is finished, a gang of brothers and sisters (PMs, testers, developers, release engineers, managers) get together for a Go/No-Go meeting. At this Go/No-Go meeting the group decides if the code is ready to be released to the production environment (also called “production,” “prod,” or “live“) so the users can enjoy the results of the team’s efforts. If it’s a “Go,” the release engineers release the code to prod. If it’s a “No-Go,” the responsible parties stop eating and sleeping until the issues are resolved. Once all the issues are resolved, there is another Go/No-Go meeting, and so on … until release to prod takes place. Next ->
Lecture 4 - The Software Development Life Cycle -> Quick Intro -> Idea -> Product Design -> Coding: Part 1 -> Coding: Part 2 -> Testing And Bug Fixes -> Release
