PLEASE NO: THANKS/SMILES/SPAM/TRASH IN OUR CHATS

Class Registration      - https://online.portnov.net/register
Class Login:		- http://online.portnov.net/login/ 
Your class page 	- https://online.portnov.net/september-6-2022/
Previous class page	- https://online.portnov.net/may-9-2022/
SU-1 class page		- https://online.portnov.net/su-1/ - Russian language support
Video Archive:		- https://online.portnov.net/video/

mportnov      - Mikhail's Private - DO NOT USE for class related things
portnovonline - school related

===============================QUIZ=================================================
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:
	- Verification (making sure requirements are properly implemented)
	- Validation (making sure requirements are benefiting the customers/are good)
	* Looking for bugs (defects)


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

What are the most important fields of a bug report?
- Short Description     - done by tester - to the attn of a Manager
- Steps to reproduce    - done by tester - to the attn of a Developer
- 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 QA
- bug closed   (status = closed) by QA


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

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 (..Github..)
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 - build/release acceptance)
5. Upon successful completion of test the scheduler uploads the release to the Production server

- QA Server
- Development Server
- Production Server



=========================RULES OF BUG REPORTING==============================
1. Do not assume all the companies have same approach to writing bug reports
2. Rule of WWW – What happened, Where it happened, under Which circumstances
3. “Problem” bug report versus “Solution” bug report
4. Bug report is not about perfect English
5. Before reporting a bug, make sure that you are using the latest version of the AUT 
5. Report a bug immediately, do not postpone
6. Make sure the bug is reproducible before reporting
7. Minimize number of steps-to-reproduce
8. Write one bug report for each fix to be verified
9. The difference between actual and expected results should be clear
10. Do not quote the violated rules or requirements (developers know them) – just talk about the problem itself
11. Do not assume developer knows less than you do about the application
12. Bug reports should be as concise as possible
13. Bug report should be as complete as possible
14. Attach screen shots, data files, logs to clarify the bug description
15. Each “problem” has a story (each decision is a compromise) research before reporting
16. Use technical terms, not “people off the street” language

AUT - Application Under Test




- Tester finds a bug 
- reports a bug
- bug is assigned to a developer by ....
- bug is fixed (fix is reported) 
- the Tester verifies the bug is fixed
- tester closes the bug