- Your class page      - https://online.portnov.net/su6/
- Previous class page  - https://online.portnov.net/su5/


SEVERITY (done by QA)
-Critical(Fatal) (point of no return - crash, it hangs, data corruption) - NO WORKAROUND
-Serious                            - bad, but there is a workaround
-Minor                              - easy to ignore (cosmetic, UI)
-Suggestion -(not a bug)-validation - looking at features and their definition

Software Testing
	1. Verification = making sure the requirements are properly implemented
	2. Validation   = making sure the requirements benefit the customer
	3. Error detection (sub-product of verification)

Requirements could be:
- Ambiguous
- Conradictory
- Incomplete


PRIORITY - in which order the problem should be fixed. Set by Manager (Dev/Project).
	- high
	- medium
	- low

Bug report field written for who?
1. Short Description		- assigning manager
2. Steps to reproduce           - developer

Bug report Status			Status
- Tester submits the bug report		- Open
- Dev. Manager assigns the bug		- Assigned
- Developer fixes the bug		- Fixed  (Postponed/Deferred, Cannot reproduce)
- Tester verifies the bug fixed		- Closed

What are the most important fields of a bug report?
- Short Description     - done by tester
- Steps to reproduce    - done by tester
- Severity              - done by tester
- Priority		- NOT done by tester
- Status		- done by the team

Describe the bug's life cycle?
- bug found
- bug reported 					(status = open)
- bug assigned 					(status = assigned) by manager... to developer
- bug is fixed 					(status = fixed) by developer
- bug is verified fixed by tester
- bug closed 					(status = closed) by tester


Q: How would you decide if software is good enough to be released?
A: To make sure the most severe problems are not present in released software

Changes to requirements are the MAJOR reason for code being REWRITTEN


The bug was fixed - what is next?
- tester verifies that bug was fixed and closes the bug report
- do we have things BROKEN IN THE NEAR PROXIMITY of that specific area of the code change? = regression

Release process
1. Developers keep developing the code (new features, fixing bugs)
2. At the end of the day (cycle) they submit the code to the repository
3. Devops configures a scheduler (Jenkins), which automatically start compiling the code
	- any time there is new code submitted
	- 11 pm once a day
4. After the product is compiled the scheduler runs automated tests (for ex - release/build acceptance)
5. Upon successful completion of test the scheduler uploads the release to the production server

SERVERS
- Development Server - used by developers
- QA Server - used by QA team
- Production Server - used by software users/customers


Showstopper Bug
	- critical bug
	- the one, which prevents software from release

Mikhail's Skype     - mportnov