QA-Quality Assurance -test preparation
What are Bug Report components?
#1) Bug Number/id. #2) Bug Title. #3) Priority. #4) Platform/Environment. #5) Description. #6) Steps to Reproduce. #7) Expected and Actual Result. #8) Screenshot.
Which tools are used to write Test Cases?
- Test Management Tools such as HP Quality Center, Zephyr, Rational TestManager - Many companies use spreadsheets (Excel) or word processors (Word)
What is API Testing?
- Testing of an API (Application Programming Interface), which is a collection of software functions and procedures. - API testing is mostly used for testing system software, application software or libraries. - It is a white box testing method. - API testing (done by QA Team) is different from Unit testing (done by developers). Тестирование API (интерфейс прикладного программирования), представляющего собой набор программных функций и процедур. -Тестирование API в основном используется для тестирования системного программного обеспечения, прикладного программного обеспечения или библиотек. -Это метод тестирования белого ящика. -Тестирование API (выполняемое командой контроля качества) отличается от модульного тестирования (выполняемого разработчиками).
How can a tester be sure that bug was fixed?
- execute the steps in the bug report - make sure the fixed bug does not result in new bugs in same area
What is gray box testing?
-Extension of BBT. --Testing a piece of software against its specification but using some knowledge of its internal workings. --Gray box testing is using structural, design, and environment information (complete or incomplete) to expand or focus black box testing and to enhance testing productivity --by using appropriate methods and tools. -- a lot of web testing is done in Gray BT. ------AVOID: Comb of BBT and WBT
What does test Plan Include?
-Personal allocation/Персональное распределение -Testing priorities and focus/Тестирование приоритетов и фокуса
API-Applic Progr Interface
-Programming language (Jara, C++) -3rd Party libraries -Google API (libraries) needs to be WBT/API tested by Google people) -Google Map API (libraries)
LEVELS of Testing
-UNIT (component, module) -WBT -done by programmer or WBTester -BBT/function/component -INTEGRATION -WBT/BBT/GBT -SYSTEM -ACCEPTANCE (быавет 2х видов) USER ACCEPTANCE-done by SME on behalf of user) 2) the last testing done by before shipment
What is WBT?
-done at the source code level -executed mostly by either developers or WBTesters -Unit Testing and API Testing
Regression Testing
-making sure nothing was broken as a result of modifying the code -неважно ручное-автоматизированное или Black/Gray/White Box -ЛЮБОЕ изменение в коде (BUILD), не сужаем определение до починки бага или написанию нового функционала - не смешиваем с проверкой ошибки на то, что она устранена (bug fix verification) - на практике об.ем тестирования ограничен в связи с нехваткой времени на других ресурсах.
Which documents would you refer to when creating?
1) BRD-Business REQ DOC 2) PRD-Product Req DOCumintation 3) Functional Specification (подробно -FB) 4) 3rd party publications (books, publications...) 5) Manuals and Help 6) Use Cases 7) Meeting Notes 8) All business and technical doc available
What are the most common documents written by tester?
1) Test cases 2) End-To-End Test 3) Bug report 4) test Matrices (for 4 OS) 5) TreaCEABILITY Matrices 6) Test PLAN
What is Test matrix?
Data collection mechanism. It provides a structure for testing the effect of combining two or more variables, circumstances, types of hardware, or events. Row and column headings identify the test conditions. Cells keep the results of test execution. Механизм сбора данных. Он обеспечивает структуру для проверки эффекта объединения двух или более переменных, обстоятельств, типов оборудования или событий. Заголовки строк и столбцов определяют условия тестирования. В ячейках хранятся результаты выполнения теста.
What is the test Matrix?
Data collection mechanism.******** It provides a structure for testing the effect of combining two or more variables, circumstances, types of hardware, or events. Row and column headings identify the test conditions. Cells keep the results of test execution.
What fields do you fill out in a Bug Report?
A bug report template should contain the following fields: Title, Severity/priority, Description, Environment, Steps to reproduce, Expected result, Actual result, Attachments (screenshots, videos, text)
What is a TEST Plan?
A document that describes the objectives, scope, approach, and focus of a software testing effort.
What is a test plan?
A document that describes the objectives, scope, approach, and focus of a software testing effort. The process of preparing a test plan is a useful way to think through the EFFORDS NEEDED to VALIDATE the ACCEPTABILITY of a software product. The COMPLETED DOCUMENT will help people outside the test group UNDESTAND the 'why' and 'how' of product testing. It should be thorough enough to be useful but not so thorough that no one outside the test group will read it.
If you find a bug and the developer says it is as-designed, what can you do?
If you thought you found a bug, but the program is actually functioning as designed, you may want to file an enhancement request. The process for doing this varies between companies, but these requests often go through the marketing department.
Smoke Testing
In computer programming and software testing, smoke testing is Preliminary testing to REVEal simple failures severe enough to, for example, reject a prospective software release. в тестировании программного обеспечения означает минимальный набор тестов на Явные Ошибки. Дымовой тест обычно выполняется программистом; не проходившую этот тест программу не имеет смысла отдавать на более глубокое тестирование. What is smoke testing? Smoke testing, also called BUILD Verification Testing or Build Acceptance testing, is nonexhaustive software analysis that ascertains that the most crucial functions of a program work but does not delve into finer details. Smoke testing is the preliminary check of the software after a build and before a release
Which type of testing results in highest number of bugs found?
Negative testing (versus Positive testing of same type: for example - negative regression versus positive regression)
What is Negative testing? Positive?
Positive testing aimed at showing software works as intended when user does correct actions. Предназначен для демонстрации того, что программное обеспечение работает должным образом, когда пользователь выполняет правильные действия. Negative testing aimed at showing that software handles properly situations in which user acts not as user is supposed to act (invalid inputs, unreasonable selections of settings, etc.)
Describe the QA Process
QA processes include: 1) Test Planning Process 2) Test Development Process 3) Test Execution Process 4) Defect Management Process 5) Test Reporting Process Процесс планирования тестирования Процесс разработки тестов Процесс выполнения теста Процесс управления дефектами Процесс отчета об испытаниях
How do you write a bug report?
Rule of WWW - What happened, Where it happened, under Which circumstances · Write one bug report for each fix to be verified · Bug report should be as complete as possible · Bug reports are as concise as possible · Report a bug immediately, do not postpone · Use technical terms, not "people off the street" language
What is TC?
Set of condition and/or variables under which a tester will determine if requirement upon an application is satisfied.
What is Software Quality Assurance
Software QA is the process of monitoring and improving all activities associated with software development, from requirements gathering, design and reviews to coding, testing and implementation.
What is Positive testing?
Testing performed to determine what the system is supposed to do. OR. Positive testing aimed at showing software works as intended when user does correct actions.
How do you determine when you have done enough testing?
Testing process comes to the point at which additional tests will not significantly change quality of the software.
If it is not possible to find/fix all the bugs in a software product before it goes to the customers, then Why test?
To establish and to enforce business systems of the QA Organization (Test planning, bug tracking, bug reporting, test automation, release certification, and others)
BUILD
a software build is a set of executable code that is ready for use by customers. The DevOps team compiles the source code, such as code in Java or C ... Build is a compiled version of a program. Compile means, convert (a program) into a machine-code or lower-level form in which the program can be executed.
If you find a bug and the developer says it is as-designed, what can you do?
find an exact requirement, which defines the way it should be designed if there is no specific requirement compare to same feature implemented in quality third party applications (ask your manager which applications to compare to)
Error Detection:
finding if things happen when they shouldn't or things don't happen when they should.
Validation is
is the process of making sure that what has been specified is what the user actually wanted. (Validation: Are we building the right system?)
Verification is
the process of establishing the truth, accuracy, or validity of something. looking for conformance and consistency by evaluating the results against pre-specified requirements. (Verification: Are we building the system right?)
What is software usability?
usability is the degree to which a software can be used by specified consumers to achieve quantified objectives with effectiveness, efficiency, and satisfaction in a quantified context of use.
Application Base state
you just run application and do nothing/запустили и не трогаем
What is the most important part of bug report?
· Steps to reproduce (Действия по воспроизведению) · Short Description · Severity (Строгость) · Priority · Status
What does Test Plan include? - list of possible items. Most common
Ниже приведены некоторые элементы, которые могут быть включены в план тестирования в зависимости от конкретного проекта: * Заголовок * Идентификация программного обеспечения, включая номера версии/выпуска * История изменений документа, включая авторов, даты, утверждения * Оглавление * Цель документа, целевая аудитория * Цель тестирования * Обзор программного продукта * Соответствующий список связанных документов, таких как требования, проектные документы, другие планы испытаний и т. д. * Соответствующие стандарты или законодательные требования * Требования к прослеживаемости * Соответствующие соглашения об именах и соглашениях об идентификаторах * Общая организация программного проекта и персонал/контактная информация/обязанности * Организация испытаний и персонал/контактная информация/обязанности * Допущения и зависимости * Анализ рисков проекта * Тестирование приоритетов и фокуса * Объем и ограничения тестирования * Схема тестирования — декомпозиция подхода к тестированию по типу теста, функции, функциональности, процессу, системе, модулю и т. д., если применимо. * Схема классов эквивалентности входных данных, анализ граничных значений, классы ошибок * Тестовая среда — аппаратное обеспечение, операционные системы, другое необходимое программное обеспечение, конфигурации данных, интерфейсы к другим системам. * Анализ валидности тестовой среды — различия между тестовой и производственной системами и их влияние на валидность тестов. * Проблемы с настройкой и конфигурацией тестовой среды * Процессы миграции программного обеспечения * Программные процессы CM * Требования к настройке тестовых данных * Требования к настройке базы данных * Краткое описание системного ведения журнала/регистрации ошибок/других возможностей и инструментов, таких как программное обеспечение для захвата экрана, которые будут использоваться для описания ошибок и сообщения об ошибках. * Обсуждение любых специализированных программных или аппаратных инструментов, которые будут использоваться тестировщиками для отслеживания причины или источника ошибок. * Автоматизация тестирования - обоснование и обзор * Используемые инструменты тестирования, включая версии, исправления и т. д. * Процессы обслуживания тестового сценария/тестового кода и контроль версий * Отслеживание и решение проблем - инструменты и процессы * Метрики тестирования проекта, которые будут использоваться * Требования к отчетности и результаты тестирования * Критерии входа и выхода программного обеспечения * Начальный период проверки работоспособности и критерии * Проверка критериев приостановки и перезапуска * Распределение персонала * Потребности в предварительном обучении персонала * Испытательный полигон/местоположение * Внешние испытательные организации, которые будут использоваться, и их цели, обязанности, результаты, контактные лица и вопросы координации. * Соответствующие вопросы собственности, секретности, безопасности и лицензирования * Открытые вопросы * Приложение - глоссарий, сокращения и т.д.
Ad-Hog Testing (Exploratory T)
Это не МАНКИ-ТЕСТ!!!! Это подмножество 3 видов действии кот совершаются одновременно. - 1) -Simultaneously planning and executing test, 2) -simultaneously executing test and learning the application 3) - Simplified form of Exploratory Testing Ad hoc testing sometimes referred to as 'random testing' or 'monkey testing', is defined as an informal testing type. The aim of this process is to break the system using unconventional methods. This type of software testing is generally unplanned and does not follow any specific test design techniques to create test cases. The main aim of ad hoc testing is to find any defects through random checking. The tester improvises the steps by arbitrarily executing them. Conclusion. Ad hoc testing does not require elaborate planning, documentation, and test-case designs. Instead, it saves time due to its ad hoc nature, and by selecting testers who are creative and have prior knowledge of the application's functionality. This testing can help find more defects than planned testing.
Traceability of Requirements
возможность отслеживать требование ВПЕРЕД и НАЗАД в жизненном цикле разработки. Требования отслеживаются через другие артефакты разработки, включая тестовые наборы, тестовые прогоны и проблемы.
На интервью: А вы действительно хотите TEST C или подход?
скорее всего подход потому что написание займет времени
HAPPY PATH (also, we have positive test, negative test but diff)
тест, расчитано на успешное прохождние. For example, "Как вы будете тестировать LOGIN & password?" -Для начало сделаем VALID LOGIN and VALID PASSWORD.
Testing boundary conditions? Why? How?
• Boundary value analysis is a methodology for designing test cases that concentrates software testing effort on cases near the limits of valid ranges. • Boundary value analysis is a method which refines equivalence partitioning. It generates test cases that highlight errors better than equivalence partitioning. The trick is to concentrate software testing efforts at the extreme ends of the equivalence classes. At those points when input values change from valid to invalid errors are most likely to occur. As well, boundary value analysis broadens the portions of the business requirement document used to generate tests. For example, if a valid range of quantity on hand is -9,999 through 9,999, write test cases that include: 1. the valid test case quantity on hand is -9,999, 2. the valid test case quantity on hand is 9,999, 3. the invalid test case quantity on hand is -10,000 and 4. the invalid test case quantity on hand is 10,000 Анализ граничных значений — это методология разработки тестовых случаев, которая концентрирует усилия по тестированию программного обеспечения на случаях, близких к границам допустимых диапазонов. Анализ граничных значений — это метод, который уточняет разбиение эквивалентности. Он генерирует тестовые случаи, которые выделяют ошибки лучше, чем секционирование эквивалентности. Хитрость заключается в том, чтобы сосредоточить усилия по тестированию программного обеспечения на крайних концах классов эквивалентности. В тех точках, когда входные значения изменяются с действительных на недопустимые, наиболее вероятно возникновение ошибок. Кроме того, анализ граничных значений расширяет части документа бизнес-требований, используемые для создания тестов. Например, если действительный диапазон количества в наличии составляет от -9 999 до 9 999, напишите тестовые наборы, которые включают: 1. действительное количество тестов в наличии -9 999, 2. допустимое количество тестов в наличии - 9 999, 3. количество недопустимых тестовых наборов в наличии равно -10 000 и 4. количество недопустимых тестовых наборов в наличии равно 10 000
What is Build?
•A build is a pre-released version of software. •It is given to the testing team by development to test it locally. In a programming context, a build is a version of a program. As a rule, a build is a pre-release version and as such is identified by a build number, rather than by a release number. Reiterative (repeated) builds are an important part of the development process. Throughout development, application components are collected and repeatedly compiled for testing purposes. Сборка — это предварительно выпущенная версия программного обеспечения. • Он предоставляется команде тестирования разработчиками для локального тестирования. В контексте программирования сборка — это версия программы. Как правило, сборка является предварительной версией и поэтому идентифицируется номером сборки, а не номером выпуска. Повторяющиеся (повторяющиеся) сборки являются важной частью процесса разработки. В ходе разработки компоненты приложения собираются и повторно компилируются для целей тестирования.
What is usability testing?
•A type of software testing where a small set of target end-users, "use" it to expose usability defects. •Focuses on the user's ease to use the application. Usability testing refers to evaluating a product or service by testing it with representative users. Typically, during a test, participants will try to complete typical tasks while observers watch, listen and takes notes.
High Level test case
A test case without concrete values for input data and expected results. System level test (End-to-End test)
What is Test Strategy?
A test strategy is an outline that describes the testing portion of the software development cycle. It is created to inform project managers, testers, and developers about some key issues of the testing process. What does Test Strategy include? This includes the testing objective, methods of testing new functions, total time and resources required for the project, and the testing environment. Стратегия тестирования — это план, описывающий этап тестирования в цикле разработки программного обеспечения. Он создан для информирования руководителей проектов, тестировщиков и разработчиков о некоторых ключевых проблемах процесса тестирования. Что включает в себя стратегия тестирования? Сюда входят цель тестирования, методы тестирования новых функций, общее время и ресурсы, необходимые для проекта, а также среда тестирования.
What is an Acceptance Testing?
Acceptance testing is black-box testing performed on a software prior to its delivery. Acceptance testing by the system provider is distinguished from acceptance testing by the customer (user acceptance testing - UAT). Facilitated by QA team, but performed by Subject Matter Experts (SMEs) on behalf of users Acceptance testing by the customer in today's world is called User Acceptance Testing - UAT Приемочное тестирование — это тестирование программного обеспечения методом «черного ящика» перед его поставкой. Приемочное тестирование поставщиком системы отличается от приемочного тестирования заказчиком (пользовательское приемочное тестирование - UAT). При содействии группы обеспечения качества, но выполняется профильными экспертами (SME) от имени пользователей. Приемочное тестирование заказчиком в современном мире называется пользовательским приемочным тестированием — UAT.
Describe Risk Analysis
Actions taken to avoid things going wrong on a software development project, things that might negatively impact the scope, quality, timeliness, or cost of a project. 2) This is, of course, a shared responsibility among everyone involved in a project. However, there needs to be a 'buck stops here' person who can consider the relevant tradeoffs when decisions are required, and who can ensure that everyone is handling their risk management responsibilities.
Which documents would you refer to when creating Test Cases?
All business and technical documentation available: PRD - Product Requirements Document BRD - Business Requirements Document Functional Specifications Manuals and Help Use Cases Test Design Third party publications (books, published by independent authors)
What is included into the TC at the time of planning test?
An instruction on how to get from the application base state to a variable application output or Expected results. 2) test case ID 3) Expected result
What is Business Requirements Document (BRD)?
BRD is written by the Business Analysts. It details the business solution for a project including the documentation of customer needs and expectations. The most common objectives of the BRD are: To gain agreement with stakeholders To provide a foundation to communicate to a technology service provider what the solution needs to do to satisfy the customer's and business' needs To provide input into the next phase for this project To describe what not how the customer/business needs will be met by the solution BRD написан бизнес-аналитиками. В нем подробно описывается бизнес-решение для проекта, включая документацию потребностей и ожиданий клиентов. Наиболее распространенными целями BRD являются: Для достижения согласия с заинтересованными сторонами Обеспечить основу для информирования поставщика технологических услуг о том, что должно делать решение, чтобы удовлетворить потребности клиента и бизнеса. Внести вклад в следующую фазу этого проекта Чтобы описать, что не так, как потребности клиента / бизнеса будут удовлетворены решением
What is black testing?
Black box software testing is done without using access to the source code, from user standpoint. Bugs are reported at the behavioral level.
What is black/white/gray box testing?
Black box software testing is done without using access to the source code, from user standpoint. Bugs are reported at the behavioral level. White box testing is done using access to the source code. Bugs are reported at the source code level, not behavioral. Gray box testing is using structural, design, and environment information (complete or incomplete) to expand or focus black box testing and to enhance testing productivity by using appropriate methods and tools.
Types of Ad Hoc Testing Method?
Buddy Testing. This type of ad hoc testing is conducted with a minimum of two people. Monkey Testing. Due to the random nature of the testing, this method has earned the name 'monkey testing'. Pair Testing. Similar to 'buddy testing' in some ways, 'pair testing' involves a pair of testers working together on the modules for testing. The two testers will share ideas, knowledge, and opinions over the same machine in order to identify defects or errors.
Build Acceptance Tests
Build acceptance tests are a type of regression testing that is done every time a new build is taken. Build acceptance tests are important because they let developers know right away if there is a serious problem with the build, and they save the test team wasted time and frustration.
Beside test case & test plan, what documents are required to write?
Check Lists Test matrices Test design specs End-to-end tests Test summary reports Bug reports Контрольные списки Тестовые матрицы Спецификации тестового дизайна Сквозные тесты Сводные отчеты о тестировании Отчеты об ошибках
What is Quality?
Customer satisfaction. Subjective term. It will depend on who the 'customer' is. Each type of customer will have their own view on 'quality'
What is the software development life cycle?
The systems (or software) development life cycle (SDLC) is a CONCEPTUAL MODEL used in project management (PM) that describes the STAGES INVOLVED in an information system development project, from an initial feasibility study THROUGH maintenance of the completed application. It includes the following different stages: 1. Requirement phase 2. Design phase 3. Coding (programming) 4. Testing 5. Release (Production) 6. Maintenance (Support)
Bug Reporting Rules:
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 6). Report a bug immediately, do not postpone 7). Make sure the bug is reproducible before reporting 8). Minimize number of steps-to-reproduce 9). Write one bug report for each fix to be verified 10). The difference between actual and expected results should be clear 11). Do not quote the violated rules or requirements (developers know them) - just talk about the problem itself 12). Do not assume developer knows less than you do about the application 13). Bug reports should be as concise as possible 14). Bug report should be as complete as possible 15). Attach screen shots, data files, logs to clarify the bug description 16). Each "problem" has a story (each decision is a compromise) research before reporting 17). Use technical terms, not "people off the street" language
What are the typical GUI problems you look for on a web page?
5 Signs That Indicate Website Usability Problems 1) Bad First Impression. For obvious reasons, one of the most critical aspects of web site usability is how your website loads and the way you structure your front page. ... 2)Poorly Structured Links. ... 3)Excessive Website Text. ... 4)Lack of Consistency. (If the colors, fonts, graphics and information are not consistent throughout your website, users will think they have gone to a different site. Create a page template that will allow you to give a consistent presentation and let users know they are on your website.) 5)Complicated Navigation (Your website pages should be able to explain themselves and visitors should be able to access any main directory page in three website clicks or less.) https://usabilitygeek.com/5-signs-that-indicate-website-usability-problems/
Write test cases for a text field?
5 test cases for capacity including 2 for each boundary and one for the class between boundaries 3 test cases for valid/invalid input of letters, digits, special characters One test cases for each allowed special character (email field as an example) Functionality testing if there is any functionality (validation of input as an example, case sensitivity, required field, etc.) Написать тестовые примеры для текстового поля? 5 тестов на пропускную способность, в том числе 2 для каждой границы и один для класса между границами 3 теста на корректный/неверный ввод букв, цифр, специальных символов 1 тестовый пример для каждого разрешенного специального символа (например, поле электронной почты) Тестирование функциональности, если есть какая-либо функциональность (проверка ввода в качестве примера, чувствительность к РЕГИСТРУ, обязательное поле и т. д.)
What is a Test Case? What does it include?
A Test Case is a document that describes step by step process how to test the application. A Test Case includes: 1)Test Case ID, 2) Title /Description, Expected Output, Actual Output, Pass/Fail, Remarks... Набор условий и переменных при которых тестировщик определяет выполнено ли требование к приложению.
What is GUI testing?
Graphical User Interface Testing is to test the interface between the application and the end user. 1) Label comes with a COLON (:) at the END 2)Disable if NOT in USE 3) Use Ellipses to indicate that there will be a dialog box coming (... )(больше для Windows)
What is Software Quality?
Measurement of how close is actual software product to the expected (intended) product Customer satisfaction (to who?) Not to be confused with Quality Software, which is reasonably bug-free, delivered on time and within budget, meets requirements and/or expectations, and is maintainable
Describe a bug?
Mismatch between actual behavior of a software application and its intended (expected) behavior. We learn about expected behavior from requirements, specifications, other technical documentation.
Where the GUI standards are coming from?
One can derive basis GUI standards from basic human factors, however. These standards are the presentation of information, the grouping of information, and information sequencing. The amount of information to present is the most basic of GUI design considerations.
Advantages Of Ad Hoc Testing
One of the main advantages of ad hoc testing is that it is able to identify any errors that would usually go unnoticed during formal testing methods. This can save a lot of time as it requires none of the planning that structured testing does. 2) Another advantage is that testers get to explore the application freely, according to their own knowledge and understanding of the application. They can then execute various tests as they go along, helping identify errors throughout the process. 3) Thirdly, testers and developers of the application can easily test the app themselves, as it does not require test cases. This allows the developers to create more efficient and bug-free code easily. 4) Ad hoc testing can also be combined with other testing techniques and executed thereafter to produce more effective and informative results overall.
Disadvantages Of Ad Hoc Testing
One of the main disadvantages of ad hoc testing is that the actual testing process is not documented since it does not follow a particular test case. This makes it more difficult for the tests to regenerate an error. Because, in order to get that error, the tester will need to remember the exact steps he/she took to get there, which is not always possible.
What is a Regression Testing?
Regression testing involves repeating previously run tests to ensure that known failures of prior versions do not appear in new versions of the software. OR Retesting of a modified program to make sure that no errors were introduced (nothing was broken) while making changes to the code (either developing new or fixing existing one) Регрессионное тестирование включает в себя повторение ранее проведенных тестов, чтобы гарантировать, что известные сбои предыдущих версий не появятся в новых версиях программного обеспечения.
What are Bug Report components? / What fields do you fill out in a Bug Report? / Describe to me the basic elements you put in a defect/bug report?
Report number: Unique number given to the report Application / Module being tested Version & release number Problem Summary / Short Description / Synopsis Steps to reproduce Severity (Critical, Serious, Minor, Suggestion) Priority (High, Medium, Low) Environment (Software and/or hardware configuration) Reported by Assigned to Status (Open, Pending, Fixed, Closed, cannot reproduce, etc.) Resolution / Notes Keywords Номер отчета: Уникальный номер, присвоенный отчету. Тестируемое приложение/модуль Номер версии и выпуска Резюме проблемы/краткое описание/краткий обзор Действия по воспроизведению Серьезность (Критическая, Серьезная, Незначительная, Предложение) Приоритет (высокий, средний, низкий) Среда (конфигурация программного и/или аппаратного обеспечения) Сообщает Назначен Статус (Открыто, В ожидании, Исправлено, Закрыто, невозможно воспроизвести и т. д.) Разрешение / Примечания Ключевые слова
Traceability of Requirements
Requirements traceability (Отслеживаемость) is the ability to trace a requirement FORWARD and BACKWORDS in the development lifecycle. Requirements are traced forward through other development artifacts, including test cases, test runs, and issues. The Four Types of Derived Requirements Traceability Forward to Requirements. When customer needs evolve, requirements may have to be adjusted in response. ... Backward From Requirements. ... Forward From Requirements. ... Backward to Requirements. ... Certification. ... Impact analysis. ... Maintenance. ... Project tracking.
Describe risk analysis
Risk analysis means the ACTION TAKEN to AVOID things going WRONG on a software development project, things that might negatively impact the scope, quality, timeliness, or cost of a project. This is, of course, a shared responsibility among everyone involved in a project. However, there needs to be a 'buck stops here' person who can consider the relevant trade offs when decisions are required, and who can ensure that everyone is handling their risk management responsibilities. Анализ риска означает ДЕЙСТВИЕ, ПРЕДПРИНЯТОЕ ДЛЯ ИЗБЕЖАНИЯ НЕПРАВИЛЬНОГО развития событий в проекте разработки программного обеспечения, вещей, которые могут негативно повлиять на объем, качество, своевременность или стоимость проекта. Это, конечно, общая ответственность всех участников проекта. Тем не менее, здесь должен быть ответственный человек, который может рассмотреть соответствующие компромиссы, когда требуются решения, и кто может гарантировать, что каждый выполняет свои обязанности по управлению рисками.
What do you prefer: white or black box testing?
Stick to the objective stated in your resume (Portnov School graduates normally apply for black box testing positions) I mostly was focused on black box (Functional, GUI testing) and grey-box (SQL, API, Chrome DevTools) testing. Black box and Grey box is what I do. Would love to learn white box testing. I'm actually starting automation classes with python soon.
Structured Vs. Unstructured Testing
Structured Testing This approach ensures that every activity that takes place during the testing procedure is scripted, from the creation of test cases to sequential execution. The tester will follow the script in order to successfully conduct the tests. Unstructured Testing This approach involves testing through error guessing. The tester will create test cases during the testing process.
What is the different between a TC and T plan?
TC are about meeting requirements. T Plan is about test strategy, schedule, resources.
If there are so many settings/options to choose, how to write test cases?
Test cases should be developed for all most common POTENTIAL SCENARIOUS They should cover most of the Positive Input Тестовые случаи должны быть разработаны для всех наиболее распространенных ПОТЕНЦИАЛЬНЫХ СЦЕНАРИЙ. Они должны охватывать большую часть положительного ввода
What is the difference between a test case and a test plan?
Test plan is the most comprehensive Software Testing document that describes the objectives, scope, approach, and focus of a software testing effort Test case is the smallest Software Testing document that describes both typical and atypical situation that may occur in the use of an application План тестирования — это наиболее полный документ по тестированию программного обеспечения, в котором описываются цели, объем, подход и направленность усилий по тестированию программного обеспечения. Тестовый пример — это наименьший документ по тестированию программного обеспечения, описывающий как типичные, так и нетипичные ситуации, которые могут возникнуть при использовании приложения.
testable condition and pre-condition?
Testable C-определяет Build Acceptance Test (DevOPs) Pre-condition-есть ли вообще аккаутн
What is the difference between Software Testing and Software QA?
Testing is mainly focused on the source code (black, gray, white box) "Quality Assurance" measures the quality of processes used to create a quality product
What is Negative testing?
Testing the system or application using negative data is called negative testing, for example, testing password entering 6 characters where it should be 8 characters should display a message. When we test an application by putting negative values (instead of actual values), then the system should not allow the other values rather than the actual value. The system should give an message that the value is not correct. This is called negative testing. Another example is, if a user tries to type a letter in a numeric field, the correct behavior in this case would be to display the "Incorrect data type, please enter a number" message. The purpose of negative testing is to detect such situations and prevent applications from crashing. Also, negative testing helps you improve the quality of your application and find its weak points.
What is Stress Testing?
Testing to gauge performance during abnormal/extreme conditions. Stress test puts a emphasis on robustness, availability, and error handling under a heavy load, rather than on what would be considered correct behavior under normal circumstances. The goal may be to ensure the software doesn't crash in conditions of insufficient computational resources (such as memory or disk space), unusually high concurrency, or denial of service attacks. Тестирование для оценки производительности в ненормальных/экстремальных условиях. Стресс-тест делает упор на надежность, доступность и обработку ошибок при большой нагрузке, а не на то, что считается правильным поведением в обычных условиях. Цель может состоять в том, чтобы гарантировать, что программное обеспечение не выйдет из строя в условиях нехватки вычислительных ресурсов (например, памяти или места на диске), необычно высокого параллелизма или атак типа «отказ в обслуживании».
What is the Performance Testing?
Testing to measure performance under a particular workload (includes stress and load testing) Performance testing is to determine how fast some aspect of a system performs under a particular workload. It can also serve to validate and verify other quality attributes of the system, such as scalability, reliability and resource usage. Тестирование производительности предназначено для определения того, насколько быстро некоторые аспекты системы работают при определенной рабочей нагрузке. Он также может служить для проверки и подтверждения других качественных характеристик системы, таких как масштабируемость, надежность и использование ресурсов.
What is Software Testing?
The purpose of testing is verification, validation and error detection (in order to find and fix the problems) - Verification is looking for conformance and consistency by evaluating the results against pre-specified requirements. (Verification: Are we building the system right?) - Validation is the process of making sure that what has been specified is what the user actually wanted. (Validation: Are we building the right system?) - Error Detection: finding if things happen when they shouldn't or things don't happen when they should.
What does Test Plan include? - list of possible items. Most common items are in bold.
The following are some of the items that might be included in a test plan, depending on the particular project: * Title * Identification of software including version/release numbers * Revision history of document including authors, dates, approvals * Table of Contents * Purpose of document, intended audience * Objective of testing effort * Software product overview * Relevant related document list, such as requirements, design documents, other test plans, etc. * Relevant standards or legal requirements * Traceability requirements * Relevant naming conventions and identifier conventions * Overall software project organization and personnel/contact-info/responsibilities * Test organization and personnel/contact-info/responsibilities * Assumptions and dependencies * Project risk analysis * Testing priorities and focus * Scope and limitations of testing * Test outline - a decomposition of the test approach by test type, feature, functionality, process, system, module, etc. as applicable * Outline of data input equivalence classes, boundary value analysis, error classes * Test environment - hardware, operating systems, other required software, data configurations, interfaces to other systems * Test environment validity analysis - differences between the test and production systems and their impact on test validity. * Test environment setup and configuration issues * Software migration processes * Software CM processes * Test data setup requirements * Database setup requirements * Outline of system-logging/error-logging/other capabilities, and tools such as screen capture software, that will be used to help describe and report bugs * Discussion of any specialized software or hardware tools that will be used by testers to help track the cause or source of bugs * Test automation - justification and overview * Test tools to be used, including versions, patches, etc. * Test script/test code maintenance processes and version control * Problem tracking and resolution - tools and processes * Project test metrics to be used * Reporting requirements and testing deliverables * Software entrance and exit criteria * Initial sanity testing period and criteria * Test suspension and restart criteria * Personnel allocation * Personnel pre-training needs * Test site/location * Outside test organizations to be utilized and their purpose, responsibilities, deliverables, contact persons, and coordination issues * Relevant proprietary, classified, security, and licensing issues * Open issues * Appendix - glossary, acronyms, etc.
What is the bug life cycle?
The life cycle the bug goes through from when it is found until when it is closed. bug found bug reported bug assigned to developer along with Priority bug fixed by developer fix verified by tester bug closed
Buddy vs. Pair Testing
The main difference between buddy testing and pair testing is that buddy testing is a combination of unit and system testing. Another key difference is that buddy testing is executed by developers and testers together. Pair testing, however, is done only by testers who have different levels of knowledge.
What is Unit Testing?
Unit testing is way to test individual unit for their functionality instead of testing whole application The goal of unit testing is to isolate each part of the program and show that the individual parts (units) are correct. A unit is the smallest testable part of an application. It may be an individual function or procedure. Unit testing is provided by developers, not testers. Цель модульного тестирования состоит в том, чтобы изолировать каждую часть программы и показать, что отдельные части (модули) верны. Модуль — это наименьшая тестируемая часть приложения. Это может быть отдельная функция или процедура. Модульное тестирование предоставляется разработчиками, а не тестировщиками.
What is a use case?
Use case is a format used by Business Analysts for specifying system requirements. Each use case normally represents completed business operation performed by user. From the QA prospective we will execute corresponding End-To-End test to make sure the requirement is implemented.
What is walk-through meeting?
Walk-through meeting is a form of software peer review in which a designer or programmer leads members of the development team and other interested parties through a software product, and the participants ask questions and make comments about possible errors, violation of development standards, and other problems. Проходное совещание — это форма экспертной оценки программного обеспечения, в которой дизайнер или программист знакомит членов команды разработчиков и других заинтересованных сторон с программным продуктом, а участники задают вопросы и комментируют возможные ошибки, нарушения стандартов разработки и другие проблемы.
What does Test Case include?
When planning for testing the test case: Planning Stage: (1-4): 1.Test case ID 2.The purpose (Title, Description) of the test case 3.An instruction ( on how to get from the application base state to a verifiable application output or expected result) 4.Expected result When execute test cases we need two more columns: 1.Actual result 2.PASS/FAIL indication
How will you write test cases for testing fields LOGIN & PASSOWRD, Positive and Negative testing?
Whenever you will be asked to write the test cases for the 'Form with some controls', you need to follow the list of rules for writing test cases as mentioned below: 1. Write a test case on each form object. 2. Written test cases should be a combination of both negative and positive test cases. Also, test cases should always be a combination of functional, performance, UI, usability, and compatibility test cases.
What is white testing?
White box testing is done using access to the source code. Bugs are reported at the source code level, not behavioral.
