1. SOFTWARE DEVELOPMENT LIFECYCLE
1.1. Requirement Analysis
1.2. Design
1.3. Implementation/Coding
1.4. Testing
1.5. Deployment
1.6. Maintenance
2. Verification
2.1. Are we building the product right?
2.2. This is static procces of testing(documentation)
2.3. Errors detected during the Verification phase require lower cost edits
2.4. To ensure that work products meet their specified requirements.
3. SOFTWARE TESTING TYPES
3.1. Functional
3.1.1. Functional
3.1.1.1. Installation testing
3.1.1.1.1. Installation testing, intended to check the successful installation and upgrade or remove the program.
3.1.1.2. Smoke testing
3.1.1.2.1. Smoke testing is performed in order to show that the most necessary functionality of the program (which requires the product). This testing is done by developers or testers.
3.1.1.3. Functionality Testing
3.1.1.3.1. Functionality testing is done to check that the software operates correctly in accordance with design specifications.
3.1.1.4. Compatibility testing
3.1.1.4.1. Checks whether the application or software compatible with the hardware, operating system, database or other software systems.
3.2. NON - Functional
3.2.1. Non - Functional
3.2.1.1. UX testing
3.2.1.1.1. Usability testing - is the testing that is necessary to verify that the user interface is easy to use and understand
3.2.1.2. Security testing
3.2.1.2.1. Security testing - the process of determining what information system protects data and maintains functionality as intended. Security testing, in general, this type of test that checks whether a program or product is protected or not. This is a test whether the system is vulnerable to attack if anyone can break the system or enter without any permission.
3.2.1.3. Localization testing
3.2.1.3.1. Localization (L10N) testing checks how well the application under test has been Localized into a particular target language.
3.2.1.4. Internationalization testing
3.2.1.4.1. Internationalization (I18N) testing checks if all data/time/number/currency formats are displayed according to selected locale and if all language specific characters are displayed.
3.2.1.5. Performance Testing
3.2.1.5.1. Testing with the intent of determining how efficiently a product handles a variety of events.
3.2.1.6. Load Testing
3.2.1.6.1. Load testing generally refers to the practice of modeling the expected usage of a software program by simulating multiple users accessing the program's services concurrently.
3.2.1.7. Stress testing
3.2.1.7.1. Stress testing is a form of testing that is used to determine the stability of a given system or entity. The idea is to stress a system to the breaking point in order to find bugs that will make that break potentially harmful.
3.2.1.8. UI Testing
3.2.1.8.1. User Interface testing is done to verify that the application interface to defined standards.
3.3. Regression testing
3.3.1. Regression testing is to verify that the changes made in the software (if corrected old bugs) have not led to the emergence of new bugs.
3.3.2. Such errors - when you make changes to the program stops working that would work - called regressive errors.
3.4. Confirmation testing (re-testing)
3.4.1. Confirmation testing - retesting, which confirms that the bug has been sent. There are words synonymous with re-testing.
3.4.1.1. It is important to ensure that the test is executed in exactly the same way it was the first time using the same inputs, data and environments
4. REQUIREMENTS TYPES
4.1. Functional
4.1.1. Business requrements
4.1.2. User requirements
4.1.3. Functional requirements
4.2. Nonfunctional
4.2.1. Physical environment
4.2.2. Perfomance
4.2.3. Documentation
4.2.4. Quality attributes
5. API
5.1. An application programing interface (API) is a set of routines, protocols, and tools for building software applications applications. Basically, an API specifies how software components should interact.
5.2. HTTP(HyperText Transfer Protocol) - protocol for the application layer of data transfer, initially - in the form of hypertext documents
5.2.1. GET - The GET method is used to retrieve information from the given server using a given URI. Requests using GET should only retrieve data and should have no other effect on the data.
5.2.2. POST - A POST request is used to send data to the server, for example, customer information, file upload, etc.
5.2.3. PUT - PUT Replaces all current representations of the target resource with the uploaded content.
5.2.4. DELETE -Removes all current representations of the target resource given by a URI.
5.3. HTTP STATUS CODES
5.3.1. 1xx Informational responce
5.3.2. 2xx Success
5.3.3. 3xx Redirection
5.3.3.1. Сообщает клиенту, что для успешного выполнения операции необходимо сделать другой запрос
5.3.4. 4xx Client error
5.3.4.1. 400 - Bad request
5.3.4.2. 401 - Unauthorized
5.3.4.3. 402 - Payment Required
5.3.4.4. 403 - Forbidden
5.3.4.5. 404 - Not Found
5.3.4.6. 405 - Method Not Allowed
5.3.5. 5xx Server error
5.3.5.1. 500 Internal Server Error
5.3.5.2. 501 Not Implemented
5.3.5.3. 502 Bad Gateway
5.3.5.4. 503 Service Unavailable
5.3.5.5. 504 Gateway Timeout
6. 7 принципів тестування
6.1. Тестування показує наявність дефектів
6.1.1. Тестування може показати наявність дефектів в програмі, але не довести їх відсутність.
6.2. Кластеризація дефектів
6.2.1. Різні модулі системи можуть містити різну кількість дефектів – тобто, щільність скупчення дефектів в різних елементах програми може відрізнятися. Зусилля по тестуванню повинні розподілятися пропорційно фактичної щільності дефектів. В основному, більшу частину дефектів знаходять в обмеженій кількості модулів. Це прояв принципу Парето: 80% проблем містяться в 20% модулів.
6.3. Парадокс пестицидів
6.3.1. Проганяючи одні й ті ж тести знову та знову, Ви зіткнетеся з тим, що вони знаходять все менше нових помилок. Оскільки система еволюціонує, багато із раніше знайдених дефектів виправляють і старі тест-кейси більше не спрацьовують.
6.4. Вичерпне тестування неможливе
6.4.1. Неможливо провести вичерпне тестування, яке би покривало всі комбінації користувацького вводу та станів системи, за виключенням найбільш примітивних випадків. Замість цього необхідно використовувати аналіз ризиків та розташування пріоритетів, що дозволить більш ефективно розподілити зусилля по забезпеченню якості ПЗ.
6.5. Відсутність помилки - помилка
6.5.1. Той факт, що тестування не виявило дефектів, ще не значить, що програма готова до релізу. Знаходження та виправлення дефектів будуть не важливі, якщо система виявиться незручною у використанні, та не буде задовольняти очікуванням та вимогам користувача.
6.6. Дострокове тестування
6.6.1. естування повинне починатися якомога раніше в життєвому циклі розробки програмного забезпечення, і його зусилля повинні бути сконцентровані на визначених цілях.
6.7. Тестування залежить від контексту
6.7.1. Вибір методології, техніки та типу тестування буде напряму залежати від природи самої програми. Наприклад, програмне забезпечення для медичних цілей потребує більш строгої та ретельної перевірки, ніж, скажімо, комп’ютерна гра. З тих же міркувань, сайт із великою відвідуваністю повинен пройти через серйозне тестування продуктивності, щоб показати можливості роботи в умовах великого навантаження.
7. Основная разница между Scrum и Канбан -- в длине итераций. В Scrum итерации -- 2 недели, в Kanban задачи программисту можно «подсовывать» хоть каждый день.
7.1. Velocity -- это производительность команды за один спринт. Этот параметр позволяет Scrum менеджеру предсказать, где команда будет через 2 недели.
8. Validation
8.1. Are we building the right product?
8.2. To ensure that the product actually meets the user's needs, and that the specifications were correct in the first place
8.3. Provides dynamic testing of the software product by running it and various checks.
8.4. Errors detected during the Validation phase require more cost / resources / time.
9. Authentication and authorization
9.1. Authentication - An authentication procedure, such as authenticating a user by comparing the password they enter with a password stored in a database.
9.1.1. Popular Authentication Methods
9.1.1.1. Password-based authentication
9.1.1.2. Passwordless authentication is when a user is verified with a one-time pin code or magic link
9.1.1.3. Two-factor authentication { login and password + verification code that was received on mobile phone}
9.1.1.4. Single sign-on (SSO) allows users to access multiple applications with a single set of credentials;
9.1.1.5. Social authentication
9.1.1.6. Biometric Authentication
9.2. Authorization - granting a certain person or group of persons the rights to perform certain actions in the database.
9.2.1. Popular authorization methods
9.2.1.1. Role-based access controls (RBAC)
9.2.1.2. JSON web token is an open standard for the secure transfer of data between parties, and users are authorized using a public/private key pair.
9.2.1.3. SAML is a standard single sign-on (SSO) format in which authentication information is passed through digitally signed XML documents.
9.2.1.4. OpenID authorization- verifies the user's identity based on authorization server authentication;
9.2.1.5. OAuth allows an API to authenticate and access the requested system or resource.
10. TEST DESIGN TECHNIQUES
10.1. Static
10.1.1. Static analysis
10.1.1.1. Called prevent errors. They do not require direct use software.
10.1.2. Informal review
10.1.2.1. This is one of the type of review which doesn't follow any process to find errors in the document. Under this technique, you just review the document and give informal comments on it.
10.1.3. Walkthrough
10.1.3.1. The author of the work product explains the product to his team. Participants can ask questions if any. Meeting is led by the author. Scribe makes note of review comments.
10.1.4. Technical review
10.1.4.1. This review concentrates mainly on the technical document related to the software such as Test Strategy, Test Plan and requirement specification documents.
10.1.5. Inspection
10.1.5.1. The main purpose is to find defects and meeting is led by trained moderator. This review is a formal type of review where it follows strict process to find the defects. Reviewers have checklist to review the work products .They record the defect and inform the participants to rectify those errors.
10.2. Dynamic
10.2.1. Structure - Based These are also called white-box or structural techniques
10.2.1.1. Statement Testing
10.2.1.2. Decision Testing
10.2.2. Experience - Based (Procedure to derive and/or select test cases based on the tester's experience, knowledge and intuition.)
10.2.2.1. Error Guessing
10.2.2.2. Exploratory Testing
10.2.3. Specification - Based
10.2.3.1. Equivalence Partitioning(всі значення в допустимому відрізку)
10.2.3.1.1. A black box test design technique in wich test cases are designed to execute representatives from equivalence partitions
10.2.3.2. Boundary Values Analysis (граничні значення)
10.2.3.2.1. A black box test design technique in which test cases based on boundary values
10.2.3.3. Decision Table Testing
10.2.3.3.1. A table showing combinations inputs or causes with their associated outputs or actions wich can be used to designed test cases
10.2.3.4. State Transition Testing
10.2.3.4.1. A black box test design technique in which test cases are designed to execute valid and invalid state transitions. State transitions - a transitions between two states of a component or system
10.2.3.5. Use Case Testing
10.2.3.5.1. Is a technique that helps us identify test cases that exercise the whole system on a transaction by transaction basis from start to finish
11. Тестування програмного забезпечення -- це процес оцінки та перевірки певної системи Програмного Забезпечення. Виявлення відмінностей між фактичним станом системи, бізнес вимогами та очікуваною поведінкою.
12. Testing artifacts-- це продукти праці тестувальника, які створюються і породжуються у процесі тестування програм і використовуються ним.
12.1. Test Plan-це документ який описує весь обсяг робіт з тестування, починаючи з опису об'єкта, стратегії, розкладу, критеріїв початку і закінчення тестування, необхідного в процесі роботи обладнання, спеціальних знань, а також оцінки ризиків з варіантами їх вирішення.
12.1.1. Test plan dicribes the product that will be tested.
12.1.2. The purpose of testing and its scope
12.1.3. Test strategy
12.1.4. Project priorities and the role of testing for it;
12.1.5. Process of testing
12.1.6. description of the test environment
12.1.7. Test Scenario
12.1.8. Test cases
12.2. Test Case -- це послідовність дій, за якою можна перевірити чи відповідає тестована функція встановленим вимогам.
12.3. Check List-це документ, який описує те що повинно бути протестовано. Потрібен щоб контролювати хід процесу тестування. І зручний артефакт для поділу обов'язків.
12.4. Cheat Sheet-- це список перевірок, який повторюється.
12.5. Bug Reports-- це заключний документ, що описує ситуацію або послідовність дій, яка призвела до некоректної роботи об'єкта тестування, із зазначенням статистичних даних, обгрунтування причин і очікуваного результату.
13. Software Testing Life Cycle ( these are all actions that are performed during software product testing.)
13.1. Requirement Analysis & Clarification questions -на цьому етапі аналізуються вимоги, задаються уточнюючі запитання та затверджуються документи вимог, визначаються обсяги тестування.
13.2. Test planning -- цьому етапі визначається стратегія тест-плану, робиться попередня оцінка часу тестових дій, здійснюється вибір тестових інструментів, обговорюються можливості застосування автоматизованого тестування.
13.3. Test Design -- тестовий дизайн та аналіз. На цьому етапі розробляються тестова архітектура тест-кейсів, підготовуються вхідні дані для тестів і автоматизовані скрипти імплементуються.
13.4. Test execution -- на цьому етапі виконуються тест-кейси, рапортується про баги та про помилки шляхом вносу у баг-трекінгові системи, відбувається повторне тестування після їх фіксення.
13.5. Test closure and reporting -- відбувається підбиття підсумків, складається тест-репорт з остаточних результатів тестування, формуються тестові метрики.
14. MongoDB
14.1. Create):
14.1.1. insertOne(document): Додає один документ до колекції.
14.1.1.1. db.getCollection("Hydrants").insertOne({ "customerSlug": "aaaaaa", "_id":"42ab3e33-3939-48b9-a69b-4580965445fd", "batchNo":"2", "createdBy":"f69314c2-b7f9-42ac-98ad-bb5c967b949b", "createdOn":"2021-12-20T11:33:13.714Z", "customerId":"2cdd590d-fa92-4ce4-9e47-0e822892e25a", "flowRange":{"label":"Unknown","pinColor":"YELLOW"} })
14.1.2. insertMany(documents): Додає багато документів до колекції одразу.
14.1.2.1. db.getCollection("Hydrants").insertMany([ { "customerSlug": "aaaaaa", "_id": "42ab3e33-3939-48b9-a69b-4580965445fd", "batchNo": "2", "createdBy": "f69314c2-b7f9-42ac-98ad-bb5c967b949b", "createdOn": "2021-12-20T11:33:13.714Z", "customerId": "2cdd590d-fa92-4ce4-9e47-0e822892e25a", "flowRange": {"label": "Unknown", "pinColor": "YELLOW"} }, { "customerSlug": "bbbbbb", "_id": "64e8ff6e-3d4e-4a1b-8f0a-987e81c01f2a", "batchNo": "3", "createdBy": "d7e628a9-9c3a-4926-8c69-1f9a3be880d8", "createdOn": "2022-01-15T09:45:20.512Z", "customerId": "f9d38102-3b4f-4d80-8ec1-6c0f93f235a3", "flowRange": {"label": "High Flow", "pinColor": "RED"} } // Додайте інші документи за потребою ]);
14.2. Read:
14.2.1. find(filter): Знаходить документи, які відповідають заданому фільтру.
14.2.1.1. db.getCollection("Hydrants").find({"customerSlug":"aaaaaa"}) це простий запит
14.2.1.2. db.getCollection("Hydrants").find({ $and: [{"customerSlug":"aaaaaa"}, { "flowRange.label": "Unknown" }, { "flowRange.pinColor": "YELLOW" } ] }) це на випадок коли в одному полі flowRange є два підполя label та pinColor
14.2.1.3. db.getCollection("Hydrants").find({ "customerSlug": "aaaaaa", "hydrantId": { $exists: true, $ne: null } }) цим запиом ми повертаємо всі документи дже департамент є аааааа, а hydrantId заповнене
14.2.2. findOne(filter): Знаходить перший документ, який відповідає заданому
14.3. Updating
14.3.1. updateOne(filter, update): Оновлює перший документ, який відповідає заданому фільтру.
14.3.1.1. db.getCollection("Locations").updateOne( { "customerSlug": "aaaaaa" }, // Фільтр для визначення документа(-ів) для оновлення { $set: { "locationName": "Нова назва" } } // Оновлення: встановлює нове значення для поля "locationName" )
14.3.2. updateMany(filter, update): Оновлює всі документи, які відповідають заданому фільтру.
14.3.3. replaceOne(filter, replacement):Замінює перший документ, який відповідає заданому фільтру, на новий документ.
14.4. Delete
14.4.1. deleteOne(filter): Видаляє перший документ, який відповідає заданому фільтру.
14.4.1.1. db.getCollection("Hydrants").deleteOne ({customerSlug:"aaaaaa", batchNo:"2" })
14.4.2. deleteMany(filter): Видаляє всі документи, які відповідають заданому фільтру.
14.4.2.1. db.getCollection("Hydrants").deleteMany({ { "parameter1": "значення1", "parameter2": "значення2" }, { "parameter3": "значення1", "parameter4": "значення2" } })
14.5. Агрегаційні операції в MongoDB
14.5.1. $match: Використовується для фільтрації документів на основі певних умов.
14.5.1.1. db.getCollection("Hydrants").aggregate([ { $match: { flow: { $gt: 7000 } // Відібрати документи, де flowrate більше 7000 } } ])
14.5.1.2. db.getCollection("Hydrants").aggregate([ { $match: { flow: { $lt: 7000 } // Відібрати документи, де flowrate менше 7000 } } ])