Bug error failure fault это

Ошибка, дефект и сбой Чем же они отличаются? Почитайте веселую историю и вспомнить отличие будет легко без подсматривания в гугл! В летней школе тестировщиков Алексей Баранцев вел тренинг для продвинутых, как искать баги и исследовать приложение. Он задал простой вопрос → «Чем отличаются ошибка, дефект и сбой?». Предположения были самыми разнообразными, но уловить тонкую […]

Содержание

  1. Ошибка, дефект и сбой
  2. Software Testing – Bug vs Defect vs Error vs Fault vs Failure
  3. Bug vs Defect vs Error vs Fault vs Failure:
  4. Difference Between Error Mistake Fault Bug Failure Defect
  5. What is an Error or Mistake?
  6. What is a Bug?
  7. What is a Defect or Fault?
  8. What is a Failure?
  9. Conclusion:
  10. Difference Between Bug, Defect, Error, Failure, and Fault in Software Testing
  11. What Is a Bug?
  12. What Is A Defect?
  13. Arithmetic Defect
  14. Syntax Defects
  15. Logical Defects
  16. Performance Defects
  17. Multithreading Defects
  18. Interface Defects
  19. What Is an Error?
  20. What Is a Failure?
  21. What Is a Fault?
  22. Why Do People Confuse Between These Terms?
  23. Bug vs. Defect vs. Error vs. Failure vs. Fault: Differences
  24. #1. Definition
  25. #2. Different Types
  26. #3. Raised By
  27. #4. Reasons
  28. #5 How to Prevent Them
  29. Conclusion

Ошибка, дефект и сбой

Чем же они отличаются? Почитайте веселую историю и вспомнить отличие будет легко без подсматривания в гугл!

В летней школе тестировщиков Алексей Баранцев вел тренинг для продвинутых, как искать баги и исследовать приложение. Он задал простой вопрос → «Чем отличаются ошибка, дефект и сбой?». Предположения были самыми разнообразными, но уловить тонкую грань отличий никто не смог. Алексей мог зачитать умные слова из справочника ISTQB, но предпочел рассказать историю. Три года прошло! Я помню историю до сих пор и могу назвать отличия без подглядывания в гугл

Вступление от Алексея — придумал историю не сам. На одном из тренингов я задал этот вопрос. Девочки посовещались между собой и сказали: «Мы не можем объяснить это с точки зрения ПО, но можем на примере шитья». Я удивился и сказал: «Давайте!».

Жил-был мастер. Он шил платья на заказ. Однажды он допустил ошибку — забыл прошить нижний край у кармана платья.

Результатом ошибки стал дефект. Платье висело на вешалке и выглядело абсолютно нормально, но оно было с дефектом.

Маленькая девочка увидела платье и сразу влюбилась. Она купила платье и носила его повсюду. И все было хорошо, платье сидело замечательно, дефект никак не проявлялся. Пока новая хозяйка не решила положить в карман ключ.

Девочка опустила руку в карман, отпустила ключ… У-у-у-упс, ключ выпал на пол! Произошелсбой в системе — проявился ранее скрытый дефект.

Точно также бывает и в ПО → разработчики допускают ошибки при написании кода и в программе затаивается дефект. И даже если дефект не нашли и о нем никто не знает, он все равно есть! Сидит и ждет своего часа. И когда пользователь натыкается на ошибочный код, происходит сбой.

Официальное определение

А под конец немножко официоза — версия из ISTQB:

A human being can make an error (mistake), which produces a defect (fault, bug) in the code, in software or a system, or in a document. If a defect in code is executed, the system will fail to do what it should do (or do something it souldn’t), causing a failure. Defects in software, systems or documents may result in failures, but not all defects do so.

Человек может допустить ошибку, которая приводит к дефекту (к неисправности, багу) в коде, в софте или системе, или документе. Если дефект в коде исполняется, система не сможет сделать то, что должна (или то, что не должна), что вызовет сбой. Дефекты в программном обеспечении, системах или документах, могут вызвать неисправности, но не все дефекты вызывают их.

Источник

Software Testing – Bug vs Defect vs Error vs Fault vs Failure

Software Testing defines a set of procedures and methods that check whether the actual software product matches with expected requirements, thereby ensuring that the product is Defect free. There are a set of procedures that needs to be in mind while testing the software manually or by using automated procedures. The main purpose of software testing is to identify errors, deficiencies, or missing requirements with respect to actual requirements.

Software Testing is Important because if there are any bugs or errors in the software, they can be identified early and can be solved before the delivery of the software product.

Here we will discuss 5 terms related to SDLC:

  1. Bug: A bug refers to defects which means that the software product or the application is not working as per the adhered requirements set. When we have any type of logical error, it causes our code to break, which results in a bug. It is now that the Automation/ Manual Test Engineers describe this situation as a bug.
    A bug once detected can be reproduced with the help of standard bug reporting templates.
  2. Defect: A defect refers to the situation when the application is not working as per the requirement and the actual and expected result of the application or software are not in sync with each other.
  3. Fault: Sometimes due to certain factors such as Lack of resources or not following proper steps Fault occurs in software which means that the logic was not incorporated to handle the errors in the application. This is an undesirable situation, but it mainly happens due to invalid documented steps or a lack of data definitions.
  4. Failure: Failure is the accumulation of several defects that ultimately lead to Software failure and results in the loss of information in critical modules thereby making the system unresponsive. Generally, such situations happen very rarely because before releasing a product all possible scenarios and test cases for the code are simulated. Failure is detected by end-users once they face a particular issue in the software.
  5. Error: Error is a situation that happens when the Development team or the developer fails to understand a requirement definition and hence that misunderstanding gets translated to buggy code. This situation is referred to as an Error and is mainly a term coined by the developers.

A simple diagram depicting Bug vs Defect vs Fault vs Failure:

Bug vs Defect vs Error vs Fault vs Failure:

Some of the vital differences between bug, defect, fault, error, and failure are listed in the below table:

Defects are classified as follows:
Based on Priority:

Источник

Difference Between Error Mistake Fault Bug Failure Defect

Why is it that software system sometimes don’t work correctly? We know that people make mistakes — we are fallible.

If someone makes an error or mistake in using the software, this may lead directly to a problem — the software is used incorrectly and so does not behave as we expected. However, people also design and build the software and they can make mistakes during the design and build. These mistakes mean that there are flaws in the software itself. These are called defects or sometimes bugs or faults.

When the software code has been built, it is executed and then any defects may cause the system to fail to do what it should do (or do something it shouldn’t), causing a failure. Not all defects result in failures; some stay dormant in the code and we may never notice them.

What is an Error or Mistake?

Error is a human action that produces an incorrect result. It is deviation from actual and expected value. The mistakes made by programmer is known as an ‘Error’. This could happen because of the following reasons

  • Some confusion in understanding the requirement of the software
  • Some miscalculation of the values
  • Or/And Misinterpretation of any value, etc.

It represents mistake made by people and Mistake in the program leads to error.

What is a Bug?

A Bug is the result of a coding Error or Fault in the program which causes the program to behave in an unintended or unanticipated manner. It is an evidence of fault in the program. Bugs arise from mistakes and errors, made by people, in either a program’s source code or its design. Normally, there are bugs in all useful computer programs, but well-written programs contain relatively few bugs, and these bugs typically do not prevent the program from performing its task.

What is a Defect or Fault?

A Defect is a deviation from the Requirements. A Software Defect is a condition in a software product which does not meet a software requirement (as stated in the requirement specifications) or end-user expectations. In other words, a defect is an error in coding or logic that causes a program to malfunction or to produce incorrect/unexpected result. This could be hardware, software, network, performance, format, or functionality.

What is a Failure?

Failure is a deviation of the software from its intended purpose. It is the inability of a system or a component to perform its required functions within specified performance requirements. Failure occurs when fault executes.

Conclusion:

A Bug is the result of a coding Error and A Defect is a deviation from the Requirements. A defect does not necessarily mean there is a bug in the code, it could be a function that was not implemented but defined in the requirements of the software.

Источник

Difference Between Bug, Defect, Error, Failure, and Fault in Software Testing

Software testing is a process to spot bugs, errors, defects, faults, and failures which are the variance between expected and actual results.

Whether you test your software manually or with automated procedures, these terms surface when identifying the issues in your coding.

And by identifying deficiencies, missing requirements, or errors in the software, you are making your software flawless and of high quality for the users.

This way, you can cater to a better user experience as they can easily use the software without any issues and performance or functionality deteriorations.

In this article, I’ll explain what bugs, errors, defects, faults, and failures are and the differences between these terms based on their definitions, types, examples, reasons, focus, and other parameters.

What Is a Bug?

The bug is a widely used term in software development. But, it’s not a welcoming one. It is described as an issue or error that can cause the software to behave in other ways that are not expected by the user or intended by the developer.

Bugs have a vast range of impacts on software performance, from small issues that can easily be managed to the big ones that can make your application impossible to use. But, in both cases, bugs need to be addressed and fixed immediately in order to deliver a quality experience to the users and build trust.

Major bugs are generally treated as prioritized and urgent, especially when there is a risk of user dissatisfaction. There are many bugs that can affect functionality and performance, but the most common type of bug is crash. This means the software stops working as expected by the users and shuts downs automatically in the middle of use.

For example, when a user writes a report or article in a word processing software, and it crashes suddenly, the user will lose all the work if they don’t press the save button before. This will have a negative impact on the productivity of the user.

Typos are also bugs that seem to be tiny issues but are capable of creating disastrous results. Even an incorrect number or a misplaced letter can cause a drastic change to a program’s intended functions.

In addition, a software bug disrupts an organization’s ability to interact with users, generate leads, facilitate purchases, and more. Thus, it must be eradicated as soon as possible.

What Is A Defect?

A defect in software testing refers to the deviation or variation of the software from the users or business requirements. It is an issue in application coding that can affect the whole program. Testing teams, while executing different test cases, come across defects.

Defects in a product represent the inefficiency and inability of the application to meet the criteria and prevent the software from performing the desired work. These happen during the software development cycle by developers. A defect can form when a programmer or developer makes some minor or major mistake during the development phase.

Well, bugs and defects have very thin differences. In the software industry, both are considered faults that need to be fixed immediately before deployment. There are many types of defects that you can come across during the software development cycle. They are as follows:

Arithmetic Defect

An arithmetic defect includes defects in the arithmetic expression or finding solutions to some arithmetic expression in the program. These mistakes are caused mainly by the developers working on the software due to less knowledge or excess work. Code congestion is also a reason for arithmetic defects when developers are unable to watch the code correctly.

Syntax Defects

Syntax defects are the common types of mistakes made while writing code. It shows even a minor error in the syntax. This occurs when a developer or programmer mistakenly escapes a symbol in the program, such as a semicolon (;), while writing code in C++.

Logical Defects

Logical defects come into the picture during the implementation of the code. When a programmer thinks incorrectly about the solution or doesn’t understand the requirement clearly, these defects happen. It also occurs when a developer forgets about the corner cases. It is related to the core of the application.

Performance Defects

When the software application or system is unable to meet the expected results, it’s referred to as a performance defect. It includes the response of the application during use with varying loads.

Multithreading Defects

Multithreading defects happen when executing or running multiple tasks at the same time. This can lead to the possibility of complex debugging. During the multithreading process, there is a chance of deadlock and starvation that results in the system’s failure.

Interface Defects

Interface defects are the defects that occur during the interaction of users and software. It includes complicated interfaces, platform-based interfaces, or unclear interfaces. These defects prevent users from utilizing the software effortlessly.

What Is an Error?

An error is a misconception, misunderstanding, or mistake on the part of the application developer. A programmer or developer can sometimes misunderstand the sign notation or might type a wrong spell, resulting in an error in the programming code.

It is generated due to wrong logic, syntax, or loop that can impact the end-user experience significantly. In basic terms, an error is calculated by differentiating between the expected results and actual results. Inside a program, when such a scenario comes, it changes the application’s functionality, leading to customer dissatisfaction.

An error raises due to several reasons but leads to an issue in the application code. It can be design issues, coding issues, or system specification issues. It is slightly different from defects.

Functionality is a major criterion of software, but sometimes, the software leads to functionality errors when something is awkward, impossible, confusing, or harder. Types are errors are:

  • Communication errors can occur during communication from the application to the user. For example, no menu provided in the software, no help instructions, no save button, etc.
  • Missing command error is another common error among programmers due to low typing speed, short deadlines, or more. The output of the program deviates if some commands are missing.
  • Grammatical incorrect sentences and misspelled words are common errors found in every application code. When the error is handled in a meaningful and transparent manner, it can be reduced during testing.
  • Calculation errors occur due to coding errors, bad logic, incorrect formulae, function call issues, data type mismatch, and more.

What Is a Failure?

Sometimes during the execution of the program, the system will produce unexpected results that can lead to application failure. Under certain situations or environments, defects can be the reason for failure, and sometimes the reasons may vary.

Not every defect results in failures. For example, defects in the dead code will not result in failures. It can also be caused due to other reasons. Furthermore, many a time, environmental conditions, including a strong magnetic field, pollution, electronic fields, radiation burst, etc., can cause failure in the firmware or hardware.

Failure can also happen due to human errors while interacting with software. For example, a software failure can occur if a human puts a wrong input value. However, a failure can also be caused intentionally in the system by an individual.

When it comes to software failures, there are a few points that are essential for you to understand:

  • During software testing, if a tester is not sure whether a given situation is a failure or not, it can be referred to as an incident. The incident then requires further testing to confirm whether the defect is the cause of the failure or some other reasons like invalid input, unfavorable environment, and lack of knowledge on its functionality.

These incidents are reported and sent to developers so that they can analyze the incident to confirm the reason for failure.

  • Failure is a term that comes after the production stage of the software. To judge the quality of the software, it needs to be checked properly before deployment since quality holds the utmost importance in increasing customer confidence, resulting in enhanced business.

However, failure can only be identified in the application when the defective part is executed. If the defective parts have not been executed at all, that part can’t cause any failure.

What Is a Fault?

A fault is an unintended or incorrect behavior by an application program. It causes a warning in the program. If it is left untreated, it may lead to failures in the working of the deployed code. If various components of the application code rely on each other, a fault is the one that may cause problems in multiple components.

A minor fault can result in a high-end error. The fault can be prevented by adopting programming techniques, development methodologies, peer review, and code analysis.

Here are various types of faults in software testing, such as:

  • Algorithm fault: It occurs when a component logic or algorithm is unable to provide a clear result for the given input because of wrong processing steps. But, it can be easily prevented by disk checking.
  • Syntax fault: It occurs when using the wrong syntax in the code. A single syntax error can result in zero output or failure.
  • Computational fault: It occurs when a disk implementation is wrong or is unable to calculate the desired result. For example, combining floating point and integer variables may produce an unexpected result.

  • Timing fault: When the application is not responding after the program fails, it is called a timing fault.
  • Documentation fault: Proper documentation tells what the program actually does. Documentation fault occurs when the program doesn’t match with documentation.
  • Overload fault: Developers use data structures like a queue, stack, and array for memory purposes in the programs. When the user fills the memory and uses it beyond its capacity, it will lead to an overload fault.
  • Hardware fault: When the specified hardware doesn’t work properly for the desired software, this type of fault occurs.
  • Software fault: When the specified software is unable to work or support the platform or operating system, this type of fault occurs.
  • Omission fault: When the key aspect is misplaced or missing in the program, omission fault occurs. For example, initialization of the variable is not done at the starting point.
  • Commission fault: When an expression statement is wrong, commission fault occurs. For example, an integer is initialized with float.

However, implementing suitable techniques can easily avoid a fault in the program. These techniques and procedures are needed to be aligned with intended software and hardware specifications, programming languages, algorithms, etc.

Why Do People Confuse Between These Terms?

Bug, defect, error, failure, and fault are often used as synonyms in general terms. But software testing has differences according to their behavior.

An error is a mistake that is done by a developer. A defect is called an error that is found during the development cycle. A bug is a defect that is found during the testing cycle. A failure is termed when the program doesn’t meet the criteria. A fault is the cause of failure.

However, these terms are used differently to define the issues in the code.

Let’s understand these terms by using a real-life example:

Imagine your car that is not working, and you take it to a mechanic. You complain that the car is not running (the user reports a failure). The mechanic inspects the car and figures out the issue (defect). The issue (error) was that the driver put diesel in the gasoline engine (the tester identified the failure) – it was the user’s fault.

Bug vs. Defect vs. Error vs. Failure vs. Fault: Differences

Now that you have some ideas about these terms, let’s understand some key differences between them in software testing:

#1. Definition

A bug refers to defects, telling the software is not working as expected. A defect is a deviation between the expected and actual output. An error is an issue or mistake made by the developer during writing the code due to which compilation and execution fail.

Failure is the combination of various defects that leads to hardware and software failure resulting in an unresponsive system. A fault is the one causing the software to fail and preventing it from performing the intended tasks.

#2. Different Types

Types of bugs are logical bugs, resource bugs, and algorithmic bugs. The defect is classified as critical, minor, major, and trivial. Types of errors are syntactic error, UI screen error, flow control error, hardware error, calculation error, and more. Types of faults are business logic faults, logical faults, functional faults, GUI faults, security faults, hardware faults, and more.

#3. Raised By

A bug is raised by test engineers. The defect is identified by test engineers and is resolved by programmers or developers. Automation test engineers and developers raise errors. The testers find the failure during the development phase. Users find the faults.

#4. Reasons

The bug is caused due to missing logic, redundant codes, and erroneous logic. The defect is caused due to providing incorrect input, errors in coping, and more. The error is caused due to code error, inability to execute, ambiguity in code logic, faulty design, logical error, etc. The failure is caused due to system errors, human errors, and environmental variables. The fault is caused due to wrong design, irregular logic, and more.

#5 How to Prevent Them

To prevent bugs, you need to implement test-driven development, adjust enhanced code development practices, and more. To prevent defects, you need to implement out-of-the-box programming methods and use correct and primary software coding practices.

To prevent errors, you need to conduct peer reviews, validate bug fixes, enhance the overall quality of the application, and more. To prevent failure, you need to confirm the re-testing of the process, review the requirements, categorize the issues, and evaluate the errors.

To prevent faults, you need to review the documents and verify the application design and coding correctness.

Conclusion

Bugs, defects, errors, failures, and faults affect different parts of an application and impact its usage massively. These slow down the performance and excellence of the software, resulting in customer dissatisfaction.

Hence, these issues must be prevented in any software project immediately, so your software performs optimally and its demand remains at the top of the market.

You may also look at some of the Software testing tools.

Источник

Adblock
detector

Basis Bug Defect Fault Error Failure
Definition A bug refers to defects which means that the software product or the application is not working as per the adhered requirements set A Defect is a deviation between the actual and expected output A Fault is a state that causes the software to fail and therefore it does not achieve its necessary function. An Error is a mistake made in the code due to which compilation or execution fails, Failure is the accumulation of several defects that ultimately lead to Software failure and results in the loss of information in critical modules thereby making the system unresponsive.
Raised by Test Engineers The defect is identified by The Testers And is resolved by developers in the development phase of SDLC. Human mistakes lead to fault. Developers and automation test engineers The failure is found by the test engineer during the development cycle of SDLC
Different types
  • Logical bugs
  • Algorithmic bugs
  • Resource bugs

Теория тестирования

Тестирование

Тестирование ПО (Software Testing) — проверка соответствия между реальным и ожидаемым поведением программы, осуществляемая на конечном наборе тестов, выбранном определенным образом.

Пирамида тестирования

IMG

Зачем тестировать ПО

Цели тестирования:

  • Повысить вероятность того, что приложение, будет работать правильно при любых обстоятельствах.
  • Повысить вероятность того, что приложение, будет соответствовать всем описанным требованиям.
  • Предоставление актуальной информации о состоянии продукта на данный момент.

Этапы тестирования

Этапы:

  1. Анализ продукта
  2. Работа с требованиями
  3. Разработка стратегии тестирования
    и планирование процедур контроля качества
  4. Создание тестовой документации
  5. Тестирование прототипа
  6. Основное тестирование
  7. Стабилизация
  8. Эксплуатация

Типы тестирования

По целям:

  • Безопасности
  • Функциональное
  • Нефункциональное
    • UI
    • Совместимости
    • Производительности
      • Нагрузочное
      • Стабильности
      • Стресс

По знанию системы:

  • Белый ящик
  • Серый ящик
  • Чёрный ящик

По хронологии выполнения:

  • Входное (Smoke/intake)
  • Повторное
  • Регрессионное

По степени автомтизации

По исполнению кода

Уровни тестирования

  • Модульное/Компонентное (unit/component testing)* — тестирование наименьших элементов ПО, которые могут быть протестированы по-отдельности (модули, объекты, классы, функции).
    Задача модульного тестирования — выявление локализованных в модуле ошибок реализации алгоритмов, а также определение степени готовности системы к переходу на следующий уровень разработки и тестирования.

  • Интеграционное (integration testing) — тестирование части системы, состоящей из двух и более модулей.
    Задача интеграционного тестирования — поиск дефектов, связанных с ошибками реализации и интерпретации интерфейсного взаимодействия между модулями, а также ошибок взаимодействия с другими частями системы (ОС, оборудованием).

  • Системное (system testing) — процесс тестирования системы в целом с целью проверки того, что она соответствует установленным требованиям.
    Задача системного тестирования — выявление дефектов, связанных с общей работой системы, таких как неверное использование ресурсов системы, непредусмотренные комбинации данных пользовательского уровня, несовместимость с окружением, непредусмотренные сценарии использования, отсутствующая или неверная функциональность, неудобство в применении и т.д.

  • Приёмочное (acceptance testing) — формальный процесс тестирования, который проверяет соответствие системы потребностям, требованиям и бизнес процессам пользователя, и проводится для вынесения решения заказчиком (внутренним или внешним) или другим уполномоченным лицом принимается приложение или нет.

Техники тест-дизайна

  • Эквивалентное Разделение/Классы эквивалентности (Equivalence Partitioning — EP). Как пример, у вас есть диапазон допустимых значений от 1 до 10, вы должны выбрать одно верное значение внутри интервала, скажем, 5, и одно неверное значение вне интервала — 0, получив таким образом два значения относящиеся к разным классам.

  • Анализ Граничных Значений (Boundary Value Analysis — BVA). Если взять пример выше, в качестве значений для позитивного тестирования выберем минимальную и максимальную границы (1 и 10), и значения больше и меньше границ (0 и 11). Анализ Граничный значений может быть применен к полям, записям, файлам, или к любого рода сущностям имеющим ограничения.
    Ценность: ошибки часто встречаются как раз на границах разных групп значений.

  • Попарное тестирование (Pairwise Testing) — техника формирования наборов тестовых данных. Сформулировать суть можно так: формирование таких наборов данных, в которых каждое тестируемое значение каждого из проверяемых параметров хотя бы единожды сочетается с каждым тестируемым значением всех остальных проверяемых параметров.

  • Причина/Следствие (Cause/Effect — CE). Это, как правило, ввод комбинаций условий (Причин), для получения ответа от системы (Следствие). Например, вы проверяете возможность добавлять клиента, используя определенную экранную форму. Для этого вам необходимо будет ввести несколько полей, таких как «Имя», «Адрес», «Номер Телефона» а затем, нажать кнопку «Добавить» — это «Причина». После нажатия кнопки «Добавить», система добавляет клиента в базу данных и показывает его номер на экране — это «Следствие».

  • Предугадывание ошибки (Error Guessing — EG). Это когда тестировщик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы «предугадать» при каких входных условиях система может выдать ошибку. Например, спецификация говорит: «пользователь должен ввести код». Тестировщик будет думать: «Что, если я не введу код?», «Что, если я введу неправильный код? », и так далее. Это и есть предугадывание ошибки.

  • Исчерпывающее тестирование (Exhaustive Testing — ET) — крайний случай. В пределах этой техники вы должны проверить все возможные комбинации входных значений, и в принципе, это должно найти все проблемы. На практике применение этого метода не представляется возможным, из-за огромного количества входных значений.

Что такое Regression и Confirmation тестирование, какая между ними разница

Повторное/Подтверждающее тестирование (re-testing/confirmation testing) — тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время последнего запуска, для подтверждения успешности исправления этих ошибок.

Регрессионное тестирование (regression testing) — тестирование уже протестированной программы после модификации для уверенности в том, что процесс модификации не внес или не активизировал ошибки в областях, не подвергавшихся изменениям. Проводится после изменений в коде ПО или его окружения.

Частота регрессионного тестирования

Стоит делать по возможности и в зависимости от частоты вмешательства в релизы.

Виды интеграционного тестирования

  • Снизу вверх (Bottom Up Integration). Все низкоуровневые модули, процедуры или функции собираются воедино и затем тестируются. После чего собирается следующий уровень модулей для проведения интеграционного тестирования. Данный подход считается полезным, если все или практически все модули, разрабатываемого уровня, готовы. Также данный подход помогает определить по результатам тестирования уровень готовности приложения.

  • Сверху вниз (Top Down Integration). Вначале тестируются все высокоуровневые модули, и постепенно один за другим добавляются низкоуровневые. Все модули более низкого уровня симулируются заглушками с аналогичной функциональностью, затем по мере готовности они заменяются реальными активными компонентами. Таким образом мы проводим тестирование сверху вниз.

  • Большой взрыв («Big Bang» Integration). Все или практически все разработанные модули собираются вместе в виде законченной системы или ее основной части, и затем проводится интеграционное тестирование. Такой подход очень хорош для сохранения времени. Однако если тест кейсы и их результаты записаны не верно, то сам процесс интеграции сильно осложнится, что станет преградой для команды тестирования при достижении основной цели интеграционного тестирования.

Configuration Testing

Конфигурационное тестирование (configuration testing) — тестирование, направленное на проверку работы ПО при различных конфигурациях системы (заявленных платформах, поддерживаемых драйверах, при различных конфигурациях компьютеров и системного ПО и т.д.).

Exploratory Testing

Исследовательское тестирование (exploratory testing) — неформальный метод, при котором тестировщик активно контролирует проектирование тестов, в то время как эти тесты выполняются, и использует полученную информацию для проектирования новых улучшенных тестов. Такое тестирование определяется как одновременное обучение, проектирование теста и его исполнение.

Black/Grey/White Box Testing

  • Тестирование белого ящика (white box testing) — тестирование, основанное на анализе внутренней структуры компонента или системы и на знании исходного кода, к которому тестировщик (как правило, это программист) имеет полный доступ.

  • Тестирование серого ящика (gray box testing) — тестирование, ориентированное на имитацию работы пользователей, в условиях, когда часть внутренней структуры программы известна.

  • Тестирование чёрного ящика (black box testing) — тестирование, основанное на анализе функциональной или нефункциональной спецификации системы, при котором программа рассматривается как объект, внутренняя структура которого неизвестна.

Performance Testing

Тестирование производительности (performance testing) — определение степени, с которой система выполняет заложенные в нее функции в установленных рамках на время обработки и пропускную способность. Достаточно часто при тестировании производительности проверяется сразу несколько его подвидов.

Smoke и Sanity тестирование и какая между ними разница

Санитарное тестирование или проверка согласованности/исправности (sanity testing) — узконаправленное тестирование достаточное для доказательства того, что конкретная функция работает согласно заявленным в спецификации требованиям. Является подмножеством регрессионного тестирования. Используется для определения работоспособности определенной части приложения после изменений произведенных в ней или окружении. Обычно выполняется вручную.

Дымовое/входное тестировние (smoke/intake test) — специальный тест (короткий цикл тестов) для принятия решения, готов ли компонент или система для дальнейшего детального тестирования. Выполняется для подтверждения того, что после сборки кода (нового или исправленного) приложение, стартует и выполняет основные функции.

Traceability Matrix

Матрица соответствия требований (traceability matrix) — двумерная таблица, содержащая соответсвие функциональных требований (functional requirements) продукта и подготовленных тестовых сценариев (test cases).
В заголовках колонок таблицы расположены требования, а в заголовках строк — тестовые сценарии. На пересечении — отметка, означающая, что требование текущей колонки покрыто тестовым сценарием текущей строки.
Матрица соответсвия требований используется QA-инженерами для валидации покрытия продукта тестами. МСТ является неотъемлемой частью тест-плана.

End-to-End тест

End-to-End тесты — такие интеграционные тесты, которые воздействуют на систему через ее самые внешние интерфейсы и проверяют ожидаемую реакцию системы через эти же интерфейсы.
Почему именно интеграционные? Потому, что это единственное, что можно о них сказать наверняка: они по определению не могут быть модульными тестами. А все остальное: являются ли они одновременно приемочными, нагрузочными или еще какими — зависит только от общих плана/стратегии тестирования и той роли, которые эти тесты в них играют.

Тестирование безопасности

Тестирование безопасноcти/защищённости (security testing) – тестирование ПО с целью определить его защищённость.
Основные понятия, которые должны быть охвачены тестированием: конфиденциальность, целостность и сохранность данных, аутентификация, авторизация и невозможность отказа от авторства.

Испытание на основе рисков

Тестирование на основе рисков/Риск-тестирование (risk-based testing) — метод тестирования ПО, который базируется на вероятности рисков. Их вероятность определяется путем анализа, в котором учитываются сложность программы, критичность функции для бизнеса, частота ее использования и количество возможных дефектов. При тестировании на основе рисков наибольший приоритет получает проверка самых важных и потенциально имеющих недостатки функций.

Динамическое тестирование

Динамическое тестирование (dynamic testing) — тестирование, проводимое во время выполнения ПО, компонента или системы.

«Парадокс пестицида»

Парадокс пестицида — эффект, при котором при регулярном прогоне тестовых сценариев ошибки перестают находиться. Происходит из-за того, что ошибки которые ловились данными тестами уже пойманы, а остальные оказываются не попадающими в тестовые сценариями.

Основные фазы STLC? Дайте определение Entry и Exit Criteria.

Жизненный цикл тестирования ПО(STLC) определяет, какие действия выполнять при тестировании и когда их выполнять.

Фазы:

  1. Анализ требований
  2. Планирование тестирования
  3. Дизайн теста
  4. Настройка тестовой среды
  5. Выполнение теста
  6. Завершение теста

Критерии входа (Entry Criteria) — содержат обязательные элементы, которые необходимо выполнить, прежде чем можно будет начать тестирование.

Критерии выхода (Exit Criteria) — определяют элементы, которые должны быть выполнены до завершения тестирования.

Что такое Bug, Error, Failure, Fault

Bug (defect/fault) — ошибка программиста (или дизайнера или ещё кого, кто принимает участие в разработке), то есть когда в программе, что-то идёт не так как планировалось и программа выходит из-под контроля. Например, когда никак не контроллируется ввод пользователя, в результате неверные данные вызывают краши или иные «радости» в работе программы. Либо внутри программа построена так, что изначально не соответствует тому, что от неё ожидается.

Error — ошибка пользователя, то есть он пытается использовать программу иным способом.
Пример — вводит буквы в поля, где требуется вводить цифры (возраст, количество товара и т.п.).
В качественной программе предусмотрены такие ситуации и выдаются сообщение об ошибке (error message).

Failure — сбой (причём не обязательно аппаратный) в работе компонента, всей программы или системы. То есть, существуют такие дефекты, которые приводят к сбоям (A defect caused the failure) и существуют такие, которые не приводят. UI-дефекты например. Но аппаратный сбой, никак не связанный с software, тоже является failure.

Атрибуты баг-репорта? Какие основные поля для заполнения

Баг Репорт (Bug Report) — документ, описывающий ситуацию или последовательность действий приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата.

Атрибуты:

  • Короткое описание (Summary/Title) — выжимка информации явно указывающая на причину и тип проблемы.
  • Номер версии (Version) — версия на которой была найдена ошибка
  • Серьезность (Severity):
    • S1 Блокирующий (Blocker)
    • S2 Критический (Critical)
    • S3 Значительный (Major)
    • S4 Незначительный (Minor)
    • S5 Тривиальный (Trivial)
  • Приоритет (Priority):
    • P1 Высокий (High)
    • P2 Средний (Medium)
    • P3 Низкий (Low)
  • Статус (Status) — текущий статус бага. Зависит от используемой процедуры и жизненного цикла бага (bug workflow and life cycle)
  • Окружение (Environment) — ОС / Браузер + версия и т.п. Информация об окружении, на котором был найден баг.
  • Шаги воспроизведения (Steps to Reproduce) — действия, по которым можно легко воспроизвести ситуацию, приведшую к ошибке.
  • Фактический Результат (Actual Result) — результат, полученный после прохождения шагов к воспроизведению
  • Ожидаемый результат (Expected Result) — ожидаемый правильный результат

Разница между приоритетом и серьезностью

Серьезность (Severity) — атрибут, характеризующий влияние дефекта на работоспособность приложения.

Приоритет (Priority) — атрибут, указывающий на очередность выполнения задачи или устранения дефекта. Больше инструмент менеджера по планированию работ. Чем выше приоритет, тем быстрее нужно исправить дефект

Обычно Severity выставляется тестировщиком, а Priority — менеджером, тимлидом или заказчиком.

Приведите примеры серьезного, но не приоритетного бага.

На Андроиде 4.4 приложение при первом запуске падает. В последующие запуски работает нормально. Т.к. пользователей с этой версией ОС у нас около 0,5%, то приоретет можно поставить низкий или вообще проигнорировать.

В чем разница между валидацией и верификацией

Верификация (verification) — это процесс оценки системы или её компонентов с целью определения удовлетворяют ли результаты текущего этапа разработки условиям, сформированным в начале этого этапа. Т.е. выполняются ли наши цели, сроки, задачи по разработке проекта, определенные в начале текущей фазы.

Валидация (validation) — это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, требованиям к системе.

Validation — ’is this the right specification?’.
Verification — ’is the system correct to specification?’.

Зачем нужна тестовая документация? Какие её виды

https://habr.com/ru/company/otus/blog/588923/

Тестовая документация — набор документов, создаваемых перед началом процесса тестирования и непосредственно в процессе. Эти документы описывают покрытие тестами и процесс выполнения тестов, в них указываются необходимые для тестирования вещи, приводится основная терминология и т. д. В тестовой документации любой член команды может найти полную информацию обо всех действиях, связанных с тестированием (и об уже выполненных, и о запланированных). Тестовая документация определяет, что для нас важно и почему, какие действия мы должны выполнить и сколько времени у нас есть. Наконец, в документации обозначено, чего должна достичь команда и что сигнализирует об окончании процесса.

Виды:

  • План тестирования (test plan)
  • Чеклист (checklist)
  • Тестовый сценарий (Test Case)
  • Баг-репорт (Bug Report)
  • Отчёт о тестировании (Test Report)
  • Инструкция (Manual)

Тест-план? Какие элементы у него есть

План тестирования (Test Plan) — документ, описывающий весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения.

В стандарте IEEE 829 перечислены пункты, из которых может/должен состоять тест-план:

  1. Test plan identifier
  2. Introduction
  3. Test items
  4. Features to be tested
  5. Features not to be tested
  6. Approach
  7. Item pass/fail criteria
  8. Suspension criteria and resumption requirements
  9. Test deliverables
  10. Testing tasks
  11. Environmental needs
  12. Responsibilities
  13. Staffing and training needs
  14. Schedule
  15. Risks and contingencies
  16. Approvals

Какую обязательную информацию должен содержать тест-план? Как правильно его использовать, поддерживать и нужен ли он вообще для большинства проектов

Должен отвечать на вопросы:

  • Что надо тестировать?
  • Что будете тестировать?
  • Как будете тестировать?
  • Когда будете тестировать?
  • Критерии начала тестирования.
  • Критерии окончания тестирования.

Составляется до начала этапа тестирования. Для проектов использующих agile подходы тест-план может быстро устаревать, т.к. условия и требования могут регулярно менятся. Соответственно потребуются трудозатраты по его обновлению.

Разница между чеклистом и тест-кейсами

Чек-лист (check list) — артефакт, описывающий что должно быть протестировано. При этом чек-лист может быть абсолютно разного уровня детализации. На сколько детальным будет чек-лист зависит от требований к отчетности, уровня знания продукта сотрудниками и сложности продукта.
Как правило, чек-лист содержит только действия (шаги), без ожидаемого результата. Чек-лист менее формализован чем тестовый сценарий. Его уместно использовать тогда, когда тестовые сценарии будут избыточны. Также чек-лист ассоциируется с гибкими подходами в тестировании.

Тестовый кейс/сценарий (Test Case) — артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.
Должен иметь 3 части:

  • PreConditions — список действий, которые приводят систему к состоянию пригодному для проведения основной проверки. Либо список условий, выполнение которых говорит о том, что система находится в пригодном для проведения основного теста состояния.
  • Test Case Description — список действий, переводящих систему из одного состояния в другое, для получения результата, на основании которого можно сделать вывод о удовлетворении реализации, поставленным требованиям
  • PostConditions — список действий, переводящих систему в первоначальное состояние (состояние до проведения теста — initial state)

Тест кейсы разделяют на позитивные и негативные:

  • Позитивный тест кейс использует только корректные данные и проверяет, что приложение правильно выполнило вызываемую функцию.
  • Негативный тест кейс оперирует как корректными так и некорректными данными (минимум 1 некорректный параметр) и ставит целью проверку исключительных ситуаций (срабатывание валидаторов), а также проверяет, что вызываемая приложением функция не выполняется при срабатывании валидатора.

AQA (Automation QA)

Программирование

Что такое ООП? Назовите его принципы с примерами

Объектно-ориентированное программирование (ООП) — подход, при котором вся программа рассматривается как набор взаимодействующих друг с другом объектов. При этом нам важно знать их характеристики.

Основные понятия ООП:

Класс – способ описания сущности, определяющий состояние и поведение, зависящее от этого состояния, а также правила для взаимодействия с данной сущностью (контракт).
С точки зрения программирования класс можно рассматривать как набор данных (полей, атрибутов, членов класса) и функций для работы с ними (методов).
С точки зрения структуры программы, класс является сложным типом данных.

Объект (экземпляр) – отдельный представитель класса, имеющий конкретное состояние и поведение, полностью определяемое классом.
Говоря простым языком, объект имеет конкретные значения атрибутов и методы, работающие с этими значениями на основе правил, заданных в классе.

Интерфейс – набор методов класса, доступных для использования другими классами.

Абстрагирование – способ выделить набор значимых характеристик объекта, исключая из рассмотрения незначимые. Соответственно, абстракция – это набор всех таких характеристик.

Инкапсуляция – свойство системы, позволяющее объединить данные и методы, работающие с ними, в классе и скрыть детали реализации от пользователя.

Полиморфизм – свойство системы использовать объекты с одинаковым интерфейсом без информации о типе и внутренней структуре объекта.

Наследование – свойство системы, позволяющее описать новый класс на основе уже существующего с частично или полностью заимствующейся функциональностью. Класс, от которого производится наследование, называется базовым или родительским. Новый класс – потомком, наследником или производным классом.

SHORT VERSION

Базовые принципы ООП:

  • Абстракция — отделение концепции от ее экземпляра
  • Полиморфизм — реализация задач одной и той же идеи разными способами
  • Наследование — способность объекта или класса базироваться на другом объекте или классе. Это главный механизм для повторного использования кода. Наследственное отношение классов четко определяет их иерархию
  • Инкапсуляция — размещение одного объекта или класса внутри другого для разграничения доступа к ним

Используйте следующее вместе с наследованием:

  • Делегация — перепоручение задачи от внешнего объекта внутреннему
  • Композиция — включение объектом-контейнером объекта-содержимого и управление его поведением; последний не может существовать вне первого
  • Агрегация — включение объектом-контейнером ссылки на объект-содержимое; при уничтожении первого последний продолжает существование

Интерфейс? Абстрактный класс? Чем они отличаются

Абстрактный класс — класс, у которого не реализован один или больше методов (некоторые языки требуют такие методы помечать специальными ключевыми словами). Абстрактный класс необходим, когда нужно семейство классов, у которых есть много общего. Конечно, можно применить и интерфейс, но тогда нужно будет писать много идентичного кода.

Интерфейс — абстрактный класс, у которого ни один метод не реализован, все они публичные и нет переменных класса. Интерфейс используется, когда, например, один класс хочет дать другому возможность доступа к некоторым своим методам, но не хочет себя «раскрывать». Поэтому он просто реализует интерфейс.

Что такое SOLID? Приведите примеры

SOLID — 5 правил разработки ПО задающие принципы, которым стоит следовать, когда пишешь программы, чтобы их проще было масштабировать и поддерживать.

S — Single Responsibility (Принцип единственной обязанности)
Для каждого класса должно быть определено единственное назначение. Все ресурсы, необходимые для его осуществления, должны быть инкапсулированы в этот класс и подчинены только этой задаче.
S

O — Open-Closed (Принцип открытости/закрытости)
Сущности программы должны быть открыты для расширения, но закрыты для изменения.
O

L — Liskov Substitution (Принцип подстановки Барбары Лисков)
Должна быть возможность вместо базового типа подставить любой его подтип.
L

I — Interface Segregation (Принцип разделения интерфейсов)
Клиенты не должны вынужденно зависеть от методов, которыми не пользуются.
I

D — Dependency Inversion (Принцип инверсии зависимостей)
Модули верхнего уровня не должны зависеть от модулей нижнего уровня. И те и другие должны зависеть от абстракций.
Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.
D

Что такое DRY, KISS, YAGNI

DRY (Don’t Repeat Yourself — Не повторяйся)
Избегайте повторного написания кода, вынося в абстракции часто используемые задачи и данные. Каждая часть вашего кода или информации должна находиться в единственном числе в единственном доступном месте. Это один из принципов читаемого кода.

KISS (Keep It Simple, Stupid/Keep It Simple and Straightforward — Будь проще)
Не придумывайте к задаче более сложного решения, чем ей требуется. Простота кода – превыше всего, потому что простой код – наиболее понятный.

YAGNI (You Aren’t Gonna Need It — Вам это не понадобится)
Если пишете код, то будьте уверены, что он вам понадобится. Не пишите код, если думаете, что он пригодится позже. Если вы занимаетесь рефакторингом метода, класса или файла, не бойтесь удалять лишние методы. Даже если раньше они были полезны – теперь они не нужны.

Какие паттерны GOF вам известны? Приведите примеры их использования.

Стратегия (Strategy) — предлагает определить семейство схожих алгоритмов, которые часто изменяются или расширяются, и вынести их в собственные классы, называемые стратегиями.
Пример: способ построения маршрута в навигаторе (для авто, пешехода, велосипедиста, на общественном транспорте)

Строитель (Builder) — разделяет создание сложного объекта и инициализацию его состояния так, что одинаковый процесс построения может создать объекты с разным состоянием.
Пример: избавление от лишних опций конструктора (Lombok и создание экземпляров класса), StringBuilder

Итератор (Iterator) — предоставляет способ последовательного доступа к элементам множества независимо от его внутреннего устройства.
Пример: foreach

Одиночка (Singleton) — гарантирует, что класс имеет только один экземпляр и предоставляет глобальную току доступа к нему.
Пример: общий доступ к базе данных из разных частей программы, selenium driver

Фабричный метод (Factory Method) — определяет интерфейс для создания объекта, но позволяет подклассам решать, какой класс инстанцировать. Позволяет делегировать создание объекта подклассам.

Абстрактная фабрика (Abstarct Factory) — предоставляет интерфейс для создания групп связанных или зависимых объектов, не указывая их конкретный класс.

PageObject и PageFactory

Page Object — паттерн при котором для каждой страницы тестируемого приложения создаётся отдельный объект, методы которого инкапсулируют логику работы с отдельными элементами. Позволяет уменьшить количество кода и упростить его поддержку.
Page Factory — реализация паттерна Factory для создания экземпляров страниц встроенная в Selenium.

Какая иерархия Collections

Интерфейсы:

  • Collection
  • List
  • Set
  • Map
  • Sorted Set
  • Sorted Map
  • Queue

Классы:

  • Lists:
    • ArrayList
    • LinkedList
    • Vector(deprecated)
  • Sets
    • HashSet
    • LinkedHashSet
    • TreeSet
  • Maps
    • HashMap
    • TreeMap
    • HashTable (deprecated)
    • LinkedHashMap
  • Queue
  • Priority Queue

IMG

Разница между Thread class и Runnable interface

Многопоточность программы в Java организуется с помощью интерфейса Runnable и класса Thread, который наследуется от Runnable. Первый способ более гибкий, второй – проще.
Когда пользовательский класс должен наследоваться от другого класса (не Thread), приходится использовать наследование от интерфейса Runnable, т.к. в Java нет множественного наследования классов.

Разница между String, Stringbuffer и Stringbuilder

String
Строки в Java иммутабельны (не могут быть изменены). При изменении объекта String в Java каждый раз создается совершенно новый объект.
При использовании оператора new для создания в памяти кучи каждый раз будет создаваться новый объект String. При использовании литерала объекта («some string»), если такой объект уже существует в куче, новый объект не появится, а ссылочная переменная будет указывать на существующий объект.

StringBuilder
Класс StringBuilder представляет собой альтернативу классу String, поскольку создает мутабельный (изменяемый) набор символов.
Класс StringBuilder не обеспечивает синхронизацию: экземпляры класса StringBuilder не могут совместно использоваться несколькими потоками. Для операций со строками в среде, не являющейся многопоточной, стоит использовать StringBuilder, потому что он быстрее, чем StringBuffer.

StringBuffer
Класс StringBuffer также создает изменяемый строковый объект и содержит те же методы, что и StringBuilder.
Разница между ними в том, что класс StringBuffer — потокобезопасный и синхронизированный: экземпляры класса StringBuffer могут совместно использоваться несколькими потоками. Для операций со строками в многопоточных средах стоит использовать StringBuffer.

Разница между final, finally и finalize

final – модификатор, который применяется к переменным, полям, методам и классам. Переменная или поле становится неизменяемым и требует инициализации. Финальный метод нельзя переопределить в наследниках. Финальный класс не может иметь наследников вообще.

finally – часть языковой конструкции try-catch-finally.

finalize — метод класса Object. Сборщик мусора вызывает его для объектов, на которые больше нет ссылок и которые помечены для сбора мусора. Deprecated с Java 9.

Selenium

​​Что такое Selenium и зачем его используют

Selenium — это набор программ с открытым исходным кодом, которые применяют для тестирования веб-приложений и администрирования сайтов локально и в сети. Программы Selenium позволяют автоматизировать действия браузера.

  • Selenium IDE — плагин для браузера Firefoх для записи действий пользователя.
  • Selenium RC — устаревшая библиотека для управления браузерами.
  • Selenium WebDriver — современная библиотека для управления браузерами.
  • Selenium Server — сервер для управления браузером удаленно по сети.
  • Selenium Grid — кластер Selenium-серверов для управления браузерами на разных компьютерах в сети.

Что такое Selenium Grid

Selenium Grid — кластер, состоящий из нескольких Selenium-серверов. Предназначен для организации распределённой сети, позволяющей параллельно запускать много браузеров на большом количестве машин. Имеется выделенный сервер, который носит название «хаб» или «коммутатор», а остальные сервера называются «ноды» или «узлы».

Драйвер браузера

Драйвер браузера — не имеющая пользовательского интерфейса программная библиотека, которая позволяет различным программам взаимодействовать с браузером, управлять его поведением, получать от браузера данные и заставлять браузер выполнять команды.

Какие виды локаторов страницы существуют? Каковы их преимущества и недостатки

id=<element_id> — соответствует элементу, у которого атрибут id равен значению element_id. Cледует отметить, что данный вид локаторов является одним из самых быстрых в нахождении и одним из самых уникальных.

name=<element_name> — соответствует элементу, у которого атрибут name равен значению element_name. Эффективно применяется при работе с полями ввода формы (кнопки, текстовые поля, выпадающие списки). Данный тип локаторов тоже является достаточно быстрым в нахождении, но менее уникальным, так как на странице может быть несколько форм, у которых могут быть элементы с одинаковым именем.

dom=<dom_object> — данный тип локатора позволяет обращаться к элементу так же, как и в DHTML используя DOM-структуру. Данный тип локатора используется нечасто, так как обычно находятся более удобные аналоги, но тем не менее данная возможность есть.

link=<link_text> — специально для ссылок используется отдельно зарезервированный тип локаторов, который находит нужную ссылку по ее тексту. Это сделано отчасти потому, что ссылки как правило не имеют таких атрибутов как ID или name. Также у ссылки есть фиксированная часть и есть часть, которая может варьироваться. В этом случае мы можем использовать wildcards, в частности ‘*’.

xpath=<xpath_locator> — наиболее универсальный тип локаторов. HTML представляет собой различное сочетание тегов, которые выстраиваются в определенную иерархию, наподобие структуры каталогов в файловой системе. Задача XPath — отразить подобный путь к нужному элементу, с учетом иерархии. У XPath есть много удобств, но есть и основной недостаток — низкая скорость нахождения объекта. В таких случаях рекомендуется воспользоваться CSS-локаторами, но в некоторых случаях от XPath уйти не получится.

css=<css_path> — данный тип локаторов основан на описаниях таблиц стилей (CSS). В отличие от локаторов по ID, по имени или по тексту ссылки, данный тип локаторов может учитывать иерархию объектов, а также значения атрибутов, что делает его ближайшим аналогом XPath. А в силу того, что объект находится по данному локатору быстрее, чем XPath, рекомендуется прибегать к помощи CSS вместо XPath.

Selenium Waits? Какие есть и чем отличаются

Implicit Wait (неявное ожидание) — пожалуй, самый популярный способ ожидания в Selenium благодаря своей легкости в использовании. Использование:

  • установить его всего 1 раз
  • указать вручную лимит ожидания

Explicit wait (явное ожидание) — чаще используется для ожидания определенного условия, которое должно быть выполнено прежде, чем тест пойдет дальше. Стоит помнить следующие вещи:

  • ожидание сработает именно там, где оно указано
  • как и неявному ожиданию, ему необходимо указать лимит времени
  • ожидает выполнения необходимого условия
  • ждет завершения Ajax request

Какие exceptions может бросить Selenium? Что они означают и как их обрабатывать

ElementClickInterceptedException — команда [Клик] не могла быть выполнена должным образом, так как элемент, получающий команду каким-то образом скрыт (например, перекрыт другим элементом).

ElementNotVisibleException — выдается, когда веб-элемент присутствует, но не виден. Поскольку элемент не виден, любое взаимодействие с ним невозможно.

NoSuchElementException — бросается, когда локатор, используемый для доступа к элементу, недействителен или предпринимается попытка выполнить действие над элементом, которого нет в DOM. В любом из этих случаев элемент не будет найден.

TimeoutException — происходит, когда команда, выполняемая в данный момент, не завершается в течение ожидаемого периода времени.

WebDriverException — возникает из-за несовместимости Selenium WebDriver и целевого веб-браузера.

Исключения в Selenium обрабатываются посредством использования try-catch блока

Для чего используют JavascriptExecutor? Приведите примеры.

JavascriptExecutor — это интерфейс Selenium, который позволяет выполнить JavaScript код. Например, ввести текст, сделать щёлчок по элементу и т.п.

Способы click и send keys Selenium

Через методы Селениума или через использование JavaScriptExecutor.

Как вы запускаете параллельное выполнение тестов? Что такое ThreadLocal

maven-surefire-plugin -> thread-count

Параллелизация сьютов между агентами на CI сервере

jUnit5
-Djunit.jupiter.execution.parallel.enabled=true
-Djunit.jupiter.execution.parallel.mode.default=concurrent

TestNG
TestNG(xmlSuite.setParallel(XmlSuite.ParallelMode.CLASSES))
TestNG(xmlSuite.setThreadCount(<n>) + xmlSuite.setDataProviderThreadCount(<m>))

java.lang.ThreadLocal — класс используется для хранения переменных, которые должны быть доступны для всего потока. Фактически это нечто вроде ещё одной области видимости переменных. Класс ThreadLocal имеет методы get и set, которые позволяют получить текущее значение и установить новое значение.
Обычно экземпляры ThreadLocal объявляются как приватные статические переменные в классе. Каждый поток получает из метода get своё значение и устанавливает через set тоже своё значение, изолированное от других потоков.

Разница между Action и Actions

Action — интерфейс, который представляет одно действие пользователя. Содержит один из наиболее широко используемых методов perform().

Actions — класс ориентированный на пользователя API для эмуляции сложных пользовательских действий. Класс Actions реализует паттерн Builder, который может создавать CompositeAction, содержащий все действия, указанные вызовами метода.

Как написать метод isElementPresent

public boolean isElementPresent(By by) {
    return driver.findElement(by).isDisplayed();
    }

Как вычитать данные из динамической веб-таблицы

Необходимо сначала определить количество колонок и столбцов в данный момент с помощью xPath и тэгов <td>, <tr>, а затем обращаться к определённой ячейке или итеративно получить данные из всех ячеек.

Можете ли вы назвать 10 интерфейсов в Selenium

  • WebDriver
  • Options
  • Capabilities
  • Timeouts
  • JavascriptExecutor
  • Action
  • LocalStorage
  • Logs
  • WrapsDriver
  • WrapsElement

Я не вижу практического применения в заучивании названий интерфейсов.

2 способа, позволяющих автоматизировать капчу

  1. Боты с поддержкой оптического распознавания символов (OCR) — в этом подходе КАПЧА решается автоматически с помощью бота.
  2. Услуги по решению капчи реальными людьми — в сервисе есть сотрудники, которые постоянно доступны онлайн для решения капчи. Когда вы отправляете свою КАПЧУ, компания пересылает ее работникам, которые ее решают, и отправляет обратно решения.

Типы команд Selenium

  • Действия – функциональное действие над тестируемым веб-приложением в браузере. Например, заполнение полей, нажатие на кнопку и т.п.
  • Проверки – выполнение проверок на тестируемой странице. Например, проверка того, что определенное поле формы имеет указанное значение, или проверка заголовка окна.
  • Ожидания – организация того как, сколько и какого события будет дожидаться Selenium (ожидания загрузки страницы, ajax и т.д.).

Как найти поврежденные ссылки в Selenium WebDriver

  1. Собрать все ссылки на веб-странице на основе тега <a>.
  2. Отправить HTTP-запрос для первой ссылки.
  3. Получить HTTP-код ответа и узнать, является ли ссылка действительной или нет.
  4. Повторить это для всех захваченных ссылок.

TestNG/JUnit

Для чего нужны TestNG/JUnit

Это фреймворки автоматического тестирования. Нужны чтобы не писать свой велосипед для тех же задач по конфигурированию тестов, аннотаций для них, дата-провайдеров и т.д.

Какие аннотации используются в TestNG/JUnit

TestNG:

  • @BeforeSuite / @AfterSuite
  • @BeforeTest / @AfterTest
  • @BeforeClass / @AfterClass
  • @BeforeGroups / @AfterGroups
  • @BeforeMethod / @AfterMethod
  • @Test
  • @DataProvider
  • @Factory
  • @Parameters
  • @Listener

jUnit 5:

  • @BeforeAll / @AfterAll
  • @BeforeEach / @AfterEach
  • @Test
  • @Disable
  • @Nested
  • @Tag
  • @TestFactory
  • @Suite / @SelectClasses / @SelectPackages / @IncludePackages / @ExcludePackages
  • @IncludeClassNamePatterns / @ExcludeClassNamePatterns / @IncludeTags / @ExcludeTags

Какие assertions есть в TestNG/JUnit

TestNG:

  • assertEquals() / assertNotEquals()
  • assertTrue() / assertFalse()
  • assertNull() / assertNotNull()
  • assertSame() / assertNotSame()
  • assertEqualsNoOrder()
  • fail()

jUnit 5:

  • assertTrue() / assertFalse()
  • assertEquals() / assertNotEquals()
  • assertArrayEquals()
  • assertIterableEquals()
  • assertLinesMatch()
  • assertNull() / assertNotNull()
  • assertSame() / assertNotSame()
  • assertTimeout() / assertTimeoutPreemptively()
  • assertThrows()
  • fail()

Как выполнять тесты параллельно TestNG/JUnit

Перевести драйвер браузера на ThreadLocal!

TestNG

TestNG (xmlSuite.setParallel(XmlSuite.ParallelMode.CLASSES))
TestNG (xmlSuite.setThreadCount(<n>) + xmlSuite.setDataProviderThreadCount(<m>))

jUnit 5

-Djunit.jupiter.execution.parallel.enabled=true
-Djunit.jupiter.execution.parallel.mode.default=concurrent

Git

Для чего используют системы контроля версий

Система контроля версий (Version Control System/VCS) — позволяет хранить несколько версий одного и того же документа, при необходимости возвращаться к более ранним версиям, определять, кто и когда сделал то или иное изменение, и многое другое.
VCS позволяет изменять одни и те же файлы нескольким разработчикам одновременно. При этом все варианты изменений сохраняются отдельно, и можно сделать разные варианты одного и того же файла с учетом разных правок от разных людей. Если же несколько изменений затрагивают один и тот же фрагмент документа, то система предложит выбрать нужный вариант.

Что такое Git? Каков принцип его работы

Git — одна из VCS. Набор консольных утилит, которые отслеживают и фиксируют изменения в файлах.
Принцип работы —

Что такое commits, branches в Git

Коммит (commit) — снимок изменений в репозитории.
Бранч (branch) — ветка или копия проекта, в которую можно вносить любые изменения и они не повлияют на основной проект.

Для чего нужны GitHub, GitLab и другие, базирующиеся на Git, вебхостинги проектов

Для общего доступа к коду проекта, его скачиванию, обновлению и правке.

CI

Что такое CI/CD/CD

Непрерывная интеграция (Continuous Integration/CI) — методология разработки и набор практик, при которых в код вносятся небольшие изменения с частыми коммитами. Поскольку большинство современных приложений разрабатываются с использованием различных платформ и инструментов, то появляется необходимость в механизме интеграции и тестировании вносимых изменений.
Цель CI — обеспечить последовательный и автоматизированный способ сборки, упаковки и тестирования приложений.

Непрерывная поставка (Continuous Delivery/CD) — основывается на автоматизации сборки и тестирования, которую вводит непрерывная интеграция. Она предполагает перевод ручных шагов, необходимых для выпуска сборки приложения в продакшн, на автоматизированный процесс.

Непрерывное развёртывание (Continuous Deployment/CD) — после автоматизации релиза остаётся один ручной этап: одобрение и запуск развёртывания в продакшен. Практика непрерывного развёртывания упраздняет это, не требуя непосредственного утверждения со стороны разработчика. Все изменения развёртываются автоматически.

Последовательность выполнения CI/CD процесса на проекте

  1. Написание кода
  2. Сборка
  3. Тестирование
  4. Релиз
  5. Развертывание
  6. Поддержка и мониторинг
  7. Планирование

IMG

Как автоматическое тестирование интегрируется в CI

Непрерывная интеграция и непрерывная поставка нуждаются в непрерывном тестировании. Непрерывное тестирование часто реализуется в виде набора различных автоматизированных тестов (регрессионных, производительности и других), которые выполняются в CI/CD-конвейере.

Какие инструменты для генерации репорта после выполнения автоматических тестов вы знаете

Allure, Serenity

Какую информацию должен содержать отчет о выполнении автоматических тестов

Исходя из приоритетов целевой аудитории, мы должны определить, какую информацию должен содержать отчёт. Соответственно, в ходе проекта, информация должна консолидироваться по тому направлению, которое необходимо отразить.
Мы можем выделить три группы целевых аудиторий:

  1. Технические пользователи — Test-manager. Для них приоритетно понимание хода тестирования, какие возникают проблемы, как они решаются, построение самого процесса тестирования, описание применяемых методов и технологий.
  2. Product Manager, они же Менеджеры продукта. Их фокус сконцентрирован на сроках выполнения, выжимках из результатов тестирования без излишних технических подробностей и на общей статистике (цифровые и сравнительные метрики).
  3. Бизнес-пользователи. Обычно это и есть те люди, которые принимают решения по завершению тестирования. Они же определяют качество проделанной работы. Для них, в первую очередь, важен конечный результат в максимально кратком и ясном формате (данет), наглядное представление информации (графики, диаграммы), экспертное мнение о возможности выпуска продукта в промышленную среду и т. п., без углубления в детали.

WEB

Клиент-серверная архитектура

IMG

В промежутках могут находиться балансировщики, если используется несколько серверов или БД.

Что может выступать в роли клиента

Клиент — это рабочая станция с одной выходной точкой – конечный пользователь. В его обязанности входит отправка запросов и получение ответа.

Что такое REST, SOAP? В чем разница

SOAP и REST — это два стиля API, которые подходят к вопросу передачи данных с разных точек зрения.

SOAP (Simple Object Access Protocol) — это стандартизированный протокол, который отправляет сообщения с использованием других протоколов, таких как HTTP и SMTP. Спецификации SOAP являются официальными веб-стандартами, которые поддерживаются и разрабатываются Консорциумом World Wide Web (W3C).

REST (Representational State Transfer) — это не протокол, в отличие от SOAP, а архитектурный стиль. Архитектура REST устанавливает набор рекомендаций, которым необходимо следовать, если вы хотите построить веб-службу RESTful, например, сервисы без сохранения промежуточного состояния или использование HTTP-кодов состояния.

Какие протоколы передачи данных знаете

IP (Internet Protocol) — протокол передачи, который первым объединил отдельные компьютеры в единую сеть. Один из самых простых. Он является ненадёжным, т.е. не подтверждает доставку пакетов получателю и не контролирует целостность данных. По протоколу IP передача данных осуществляется без установки соединения.

TCP/IP (Transmission Control Protocol/Internet Protocol) — стек протоколов TCP и IP. Первый обеспечивает и контролирует надёжную передачу данных и следит за её целостностью. Второй же отвечает за маршрутизацию для отправки данных.

UDP (User Datagram Protocol) — протокол, обеспечивающий передачу данных без предварительного создания соединения. Этот протокол является ненадёжным. В нём пакеты могут не только не дойти, но и прийти не по порядку или вовсе продублироваться. Основное его преимущество заключается в скорости доставки данных. Именно поэтому чувствительные к сетевым задержкам приложения часто используют этот тип передачи данных.

FTP (File Transfer Protocol) — протокол передачи файлов. Использовали ещё в 1971 году — задолго до появления протокола IP. На текущий момент этим протоколом пользуются при удалённом доступе к хостингам. FTP является надёжным протоколом, поэтому гарантирует передачу данных. Работает по принципу клиент-серверной архитектуры. Пользователь проходит аутентификацию (хотя может подключаться и анонимно) и получает доступ к файловой системе сервера.

HTTP (HyperText Transfer Protocol) — изначально протокол передачи HTML-документов. Сейчас же он используется для передачи произвольных данных в интернете. Он является протоколом клиент-серверного взаимодействия без сохранения промежуточного состояния. В роли клиента чаще всего выступает веб-браузер, хотя может быть и, например, поисковый робот. Для обмена информацией протокол HTTP в большинстве случаев использует TCP/IP. HTTP имеет расширение HTTPS (HTTP over TLS), которое поддерживает шифрование.

SSH (Secure Shell) — протокол удалённого управления ОС с использованием TCP. В SSH шифруется весь трафик, с возможностью выбора алгоритма шифрования. В основном это нужно для передачи паролей и другой важной информации. Также SSH позволяет обрабатывать любые другие протоколы передачи. Это значит, что кроме удалённого управления компьютером, через протокол можно пропускать любые файлы или даже аудио/видео поток. SSH часто применяется при работе с хостингами.

Какие способы взаимодействия с API существуют? В чем разница между ними

  • SOAP (Simple Object Access Protocol) — Простой Протокол Доступа к Объектам. Клиент и сервер обмениваются сообщениями посредством XML. Это менее гибкий API, который был более популярен в прошлом.

  • RPC (Remote Procedure Call) — Удалённый Вызов Процедур. Клиент выполняет функцию (или процедуру) на сервере, и сервер отправляет результат обратно клиенту.

  • Websocket – современная разработка web API, которая использует объекты JSON для передачи данных. WebSocket поддерживает двустороннюю связь между клиентскими приложениями и сервером. Сервер может отправлять сообщения обратного вызова подключенным клиентам, что делает его более эффективным, чем REST.

  • REST — на сегодняшний день это самые популярные и гибкие API-интерфейсы в Интернете. Клиент отправляет запросы на сервер в виде данных. Сервер использует этот клиентский ввод для запуска внутренних функций и возвращает выходные данные обратно клиенту.

Как можно протестировать API, что там нужно проверять

Убедиться, что API работает правильно можно с помощью функционального тестирования.
Основные задачи:

  • убедиться, что реализация API работает правильно, как и ожидалось
  • гарантировать, что реализация API работает в соответствии со спецификацией требований
  • предотвратить регрессии между написанным кодом и релизом

Проверка спецификации:

  • эндпоинты правильно именованы
  • ресурсы и их типы правильно отражают объектную модель
  • нет отсутствующей или дублирующей функциональности
  • отношения между ресурсами правильно отражаются в API

Этапы тестирования API
Каждый тест состоит из атомарных действий, которые должны выполняться в каждом потоке тестирования API. Для каждого запроса API тест должен будет выполнить следующие действия:

  1. Корректность кода состояния HTTP (создание ресурса должно возвращать 201 CREATED, а запрещенные запросы должны возвращать 403 FORBIDDEN и т.д.)
  2. Полезная нагрузка ответа (правильность тела JSON, имен, типов и значений полей ответа, в том числе в ответах на ошибочные запросы)
  3. Заголовки ответа (заголовки HTTP-сервера влияют как на безопасность, так и на производительность)
  4. Правильность состояния приложения (применяется в основном к ручному тестированию или когда пользовательский интерфейс или другой интерфейс можно легко проверить)
  5. Базовая работоспособность (если операция была завершена успешно, но заняла неоправданно много времени, тест не пройден)

Форматы передачи данных

  • JSON (JavaScript Object Notation) — текстовый формат обмена данными, основанный на JavaScript, но при этом независим от JS.
  • XML (eXtensible Markup Language/расширяемый язык разметки) — используется для хранения и передачи данных. формат рекомендован Консорциумом Всемирной паутины (W3C), поэтому часто используется для передачи данных по API. Единственно возможный формат входных и выходных данных в SOAP.
  • CSV (Comma-Separated Values/значения, разделенные запятыми) – текстовый формат, предназначенный для представления табличных данных с фиксированным количеством столбцов. Каждая строка файла — это одна строка таблицы.
  • YAML (YAML Ain’t markup language/YAML не язык разметки; ранее Yet Another Markup Language) — язык для сериализации данных, который позволяет хранить сложноорганизованные данные в компактном и читаемом формате. Похож на XML и JSON, но использует более минималистичный синтаксис при сохранении аналогичных возможностей.

Отличия между XML и JSON

XML — язык разметки.

JSON — формат для обмена данными, обычно реализуемый, как массив данных.

Ключевые различия:

  • Объект JSON имеет тип, тогда как объекты XML не содержат типов
  • В JSON проще получить объект нежели в XML (данные XML должны быть проанализированы)
  • Читабельность JSON файла выше по сравнению с XML
  • JSON не обеспечивает поддержку пространства имен, в то время как XML обеспечивает
  • JSON не имеет возможностей отображения, тогда как XML имеет такую возможность
  • JSON менее защищен, тогда как XML более безопасен по сравнению с JSON
  • JSON поддерживает только кодировку UTF-8, тогда как XML поддерживает различные кодировки

Как происходит шифрование

Симметричное — используется лишь один пароль/ключ.
В системе шифрования предусмотрен некий математический алгоритм. На его цифровой «вход» подается исходный ключ и исходные данные. Далее информация шифруется и отправляется.
При получении срабатывает обратный алгоритм и проходит процедура дешифровки с использованием того самого ключа.
Если знать ключ, то безопасность симметричного шифрования стремится к нулю. Поэтому ключ должен быть максимально сложным и запутанным. Несмотря на определенные ограничения, симметричное шифрование очень распространено из-за простоты и быстродействия.

Ассиметричное — используются два ключа: открытый/публичный и закрытый/приватный. Преимущество ассиметричного шифрования в том, что один из ключей всегда остается на устройстве и не передается.
Схема передачи данных между двумя субъектами (А и Б) выглядит следующим образом:

  • Субъект А генерирует пару ключей, публичный и приватный.
  • Субъект А передает публичный ключ субъекту Б. Передача может осуществляться по незащищенным каналам.
  • Субъект Б шифрует пакет данных при помощи полученного публичного ключа и передает его А. Передача может осуществляться по незащищенным каналам.
  • Субъект А расшифровывает полученную от Б информацию при помощи приватного ключа.

Какие бывают виды БД

https://proglib.io/p/11-tipov-sovremennyh-baz-dannyh-kratkie-opisaniya-shemy-i-primery-bd-2020-01-07

  1. Простейшие типы БД
  • Текстовые файлы, csv-файлы
  • Иерархические (файловые системы, DNS, LDAP)
  • Сетевые (IDMS)
  1. Реляционные БД (MySQL, PostgreSQL..)

  2. NoSQL БД

  • «Ключ-значение» (Redis, memcached)
  • Документные (MongoDB, RethinkDB)
  • Графовые (Neo4j, Dgraph)
  • Колоночные (Cassandra, HBase)
  • БД временных рядов (OpenTSDB, TimescaleDB)
  1. Комбинированные типы БД
  • NewSQL (MemSQL, VoltDB, CockroachDB)
  • Многомодельные (OrientDB, Couchbase)

Охарактеризуйте каждый класс HTTP status code (1хх; 2xx; 3xx; 4xx; 5xx).

  • 1xx: Informational (информационные)
  • 2xx: Success (успешно)
  • 3xx: Redirection (перенаправление)
  • 4xx: Client Error (ошибка клиента)
  • 5xx: Server Error (ошибка сервера)

Расшифровка CRUD

CRUD — акроним, обозначающий четыре базовые функции, используемые при работе с постоянными хранилищами данных: создание (create), чтение (read), модификация (update), удаление (delete).

Какие есть HTTP-методы

GET — запрашивает информацию из указанного источника и не влияет на его содержимое. Запрос доступен для кеширования данных и добавления в закладки.

POST — используется для отправки данных, что может оказывать влияние на содержимое ресурса. В отличие от метода GET запросы POST не могут быть кешированы, они не остаются в истории браузера и их нельзя добавить в закладки.

HEAD — аналогичен методу GET, однако в ответе сервера содержится только заголовок, без тела. Обычно применяется для того, чтобы проверить, существует ли ресурс по указанному адресу, а также не изменился ли он с момента последнего обращения.

PUT — Загружает содержимое запроса на указанный в запросе URI. Если по заданному URI ресурса нет, то сервер создает его, возвращая статус 201 (Created).

PATCH — Используется для частичного изменения ресурса. В PATCH вложенный объект содержит набор инструкций, описывающих, как ресурс, должен быть модифицирован для создания новой версии. А в PUT содержится новая версия ресурса целиком.

DELETE — Удаляет указанный ресурс.

OPTIONS — Используется для описания параметров коммуникации между клиентом и сервером.

CONNECT — Преобразует соединение запроса в прозрачный TCP/IP-туннель.

Отличия GET от POST

IMG

Разница между методами PUT, POST, PATCH

POST — создание новой сущности. Может создавать коллекцию сущностей.
PUT — создание новой или полное обновление существующей сущности. Может работать только с одой сущностью.
PATCH — частичное обновление существующей сущности.

Какие знаете Web elements

Кнопки, лейблы, поля ввода, выпадающие списки, чекбоксы, радиобатоны, фреймы

Для чего необходимы инструменты разработчика в браузере (Chrome DevTools) и как они помогают в тестировании

  • Переопределение геолокации и подмена User-Agent
  • Определение JS пути к строке
  • Изменение HTML-кода и стилей CSS у элементов
  • Тестирование производительности и неиспользуемых CSS и Javascript в вёрстке
  • Debug JavaScript
  • Имитация медленного сетевого соединения
  • Мониторинг сетевых запросов
  • Информация о cookies во вкладке applications

Что такое кэш

Кэш — промежуточный буфер с быстрым доступом к нему, содержащий информацию, которая может быть запрошена с наибольшей вероятностью. Доступ к данным в кэше осуществляется быстрее, чем выборка исходных данных из более медленной памяти или удалённого источника, однако его объём существенно ограничен по сравнению с хранилищем исходных данных.

Кэш браузера — буфер между браузером и интернетом, в котором сохраняются посещённые пользователем страницы. Вместо того, чтобы скачивать их из интернета, браузер может «достать» страницы из кэша, что значительно сокращает скорость загрузки страниц. Проблема может возникнуть, если на сервере страница обновится, а браузер продолжит подгружать старую версию из кэша.

Что такое сессия

Cессия — механизм, позволяющий однозначно идентифицировать браузер и создающий для этого браузера файл на сервере, в котором хранятся переменные сеанса.

Зачем нужны cookies

Cookies — текстовые файлы небольшого размера со служебной информацией для браузера. Часто в таких файлах хранится статистика посещений, логин и пароль от сайтов или сервисов, индивидуальные настройки пользователя — регион, дизайн оформления и прочее.

iFrame и как с ним работать в Selenium

Фрейм (Frame/iFrame) — самостоятельный документ, который отображается в отдельном окне браузера и представляет собой полностью законченную HTML-страницу. Простыми словами, фрейм — разделитель браузерных окон на отдельные области.

Способы переключаться на iframe:

  • По индексу driver.switchTo().frame(i);
  • По имени или идентификатору driver.switchTo().frame("a077aa5e");
  • По веб-элементу
    driver.switchTo().frame(driver.findElement(By.cssSelector("#modal>iframe"));

Что такое HTML/CSS/JavaScript

HTML (HyperText Markup Language/язык гипертекстовой разметки) — стандартизированный язык разметки документов для просмотра веб-страниц в браузере.

CSS (Cascading Style Sheets/каскадные таблицы стилей) — формальный язык описания внешнего вида документа (веб-страницы), написанного с использованием языка разметки (чаще всего HTML или XHTML). Также может применяться к любым XML-документам, например, к SVG или XUL.

JavaScript — мультипарадигменный язык программирования. Поддерживает объектно-ориентированный, императивный и функциональный стили. Часто используется как встраиваемый язык для программного доступа к объектам приложений. Наиболее широкое применение находит в браузерах как язык сценариев для придания интерактивности веб-страницам.

Какую структуру имеет веб-страница

  • Заголовок: <header>
  • Навигационное меню: <nav>.
  • Основное содержимое: <main>, с различными подразделами содержимого, представленными элементами <article>, <section> и <div>.
  • Боковая панель: <aside>, обычно располагается внутри <main>.
  • Нижний колонтитул: <footer>.

Зачем чистить кэш

Веб-страницы могут отображаться некорректно в связи с тем, что в них были внесены изменения, а браузер продолжает использовать устаревшие данные из кэша. Также устаревший кэш может занимать место на ЖД.

Что такое AJAX

AJAX (Asynchronous JavaScript and XML/асинхронный JavaScript и XML) — технология описывающая как можно получать данные с сервера в фоновом режиме и использовать их для обновления страницы (без перезагрузки). Основная цель AJAX – это сделать сайты и веб-приложения более удобными, быстрыми и отзывчивыми.
Асинхронный потому, что действие выполняется в фоне (не в основном потоке), таким образом, что оно не мешает пользователю взаимодействовать со страницей.
JavaScript отвечает за создание и настройку запроса, отправку его на сервер, получение ответа и его разбор, обновление страницы.

Преимущества использования AJAX:

  • снижение трафика (уменьшения объёма передаваемых данных между клиентом и сервером)
  • уменьшение нагрузки на сервер (перегенерируется только часть страницы, которую нужно обновить)
  • увеличение быстродействия и отзывчивости (нет необходимости в полной перезагрузке страницы, достаточно обновить содержимое отдельных блоков)
  • повышение интерактивности (с помощью AJAX можно сразу отображать результаты и сделать ресурс более удобным для пользования)

Mobile

Какие мобильные платформы существуют

  • Android
  • iOS

Какие версии Android и iOS используются на рынке (минимальные и максимальные)

Взят min в 1%

Android: 4.4 — 13

iOS: 12 — 15

Типы мобильных приложений

  • Игры для смартфона
  • Промо-приложения
  • Контентные сервисы
  • Социальные сети

Что такое ADB

ADB (Android Debug Bridge) — клиент-серверное приложение, которое предоставляет доступ к работающему эмулятору или устройству. С его помощью можно копировать файлы, устанавливать скомпилированные программные пакеты и запускать консольные команды.
Состоит из трёх компонентов:

  • фоновой службы (демона), работающей в эмуляторе
  • сервиса, запущенного на компьютере разработчика
  • клиентской программы (наподобие DDMS), которая связывается со службой через Сервис

Как снять логи с Android/IOS

Android:

  1. Подсоедините ваше устройство
  2. Подтвердите, что согласны подключить устройство к компьютеру (на устройстве)
  3. Откройте командную строку Windows
  4. adb devices
  5. adb -s <device ID> logcat -> log.log
  6. Воспроизведите проблему
  7. Остановите процесс подключения (ctrl+c) или просто отсоедините устройство
  8. В папке, из которой вы запустили командную строку, вы найдете файл log.log.

iOS (нужен MAC):

  1. Запустите Xcode.
  2. Подсоедините ваше устройство.
  3. Нажмите на вкладку Window — выберите в выпадающем списке «Устройства».
  4. Выберите ваше устройство.
  5. Воспроизведите проблему.
  6. Выберите log файл нажатием клавиш cmd+A
  7. Сохраните файл.

Что такое Appium

Appium — бесплатный кроссплатформенный инструмент с открытым исходным кодом, который помогает автоматизировать приложения как для Android, так и для iOS. Appium придерживается того же подхода, что и Selenium WebDriver, который получает HTTP-запросы в формате JSON от клиентов и преобразует их в зависимости от платформы, на которой он работает.

Требования для Android:

  • Java (version >= 7)
  • Android SDK API (version >= 17)
  • Android Virtual Device (AVD) / real device
  • Intel Hardware Accelerated Execution Manager

Требования для iOS:

  • Mac OS X (version >= 10.7)
  • Xcode (version >= 5.1)
  • Java (version >= 7)
  • Homebrew
  • NodeJS
  • npm

Как запускать тесты Android без Appium

  • Espresso — официальный фреймворк для UI-тестирования, но тесты с его использованием работают по модели белого ящика (white-box). Espresso поддерживает Android API с 10 версии.
  • UiAutomator — официальный фреймворк для тестирования. Как GUI-драйвер он служит для поиска элементов интерфейса на экране девайса и эмуляции различных действий: кликов, тачей, свайпов, ввода текста, проверок на видимость. Позволяет писать тесты по модели черного ящика (black-box). Он живет в собственном процессе и работает без доступа к исходному коду приложения. Тест с его использованием может взаимодействовать практически с любыми приложениями, в том числе системными.
  • Robolectric — позволяет писать особые unit-тесты на основе JUnit с использованием Android API. Мокирует часть Android SDK, предоставляя пользователю так называемые shadow-объекты. Robolectric берет на себя такие задачи, как inflate view, загрузка ресурсов, и множество других, которые имеют нативную С-реализацию на Android-девайсах. Поэтому Robolectric позволяет писать тесты, имеющие зависимости на Android, но запускать их не на эмуляторе или реальном девайсе, а на десктопной JVM. Это существенно ускоряет процесс сборки, запуска и выполнения тестов.
  • Robotium
  • Selendroid

Asked
5 years, 9 months ago

Viewed
6k times

I was reading the differences between defect, error, bug and failure. I found a website that says about them. Are these correct?

A mistake in coding is called error, error found by tester is
called defect, defect accepted by development team then it is called
bug , build does not meet the requirements then it Is failure.

Error: A discrepancy between a computed, observed, or measured value or condition and the true, specified, or theoretically correct
value or condition. This can be a misunderstanding of the internal
state of the software, an oversight in terms of memory management,
confusion about the proper way to calculate a value, etc.

Failure: The inability of a system or component to perform its required functions within specified performance requirements. See:
bug, crash, exception, and fault.

Bug: A fault in a program which causes the program to perform in an unintended or unanticipated manner. See: anomaly, defect, error,
exception, and fault. The bug is terminology of Tester.

Fault: An incorrect step, process, or data definition in a computer program which causes the program to perform in an unintended
or unanticipated manner. See: bug, defect, error, exception.

Defect: Commonly refers to several troubles with the software products, with its external behavior or with its internal features.

Source: Click here

Bharat Mane's user avatar

Bharat Mane

6,76910 gold badges38 silver badges67 bronze badges

asked Apr 19, 2017 at 14:42

Muhammad Ali Khamis's user avatar

1

ISQTB foundation level material states the following:

A human being can make an error (mistake), which produces a defect
(fault, bug) in the program code, or in a document.

If a defect in code is executed, the system may fail to do what it
should do (or do something it shouldn’t), causing a failure.

Defects in software, systems or documents may result in failures, but
not all defects do so.

If you read this definition carefully, I think it is pretty self-explanatory.

answered Apr 20, 2017 at 7:44

Zvonimir Horvatic's user avatar

1

As with most testing terminology it depends on the company, person and or industry. It is a means to communicate. When in doubt ask what people mean with it within its context.

For me bugs and defects are the same. Bugs are something from the 40ties according to Wikipedia.

featuring a dead moth that was removed from the device

I would push for calling all bugs defects instead, because dead animals do not anymore block computer systems.

Coding mistakes are just coding mistakes, they could cause errors.

An ‘error’ is a deviation from accuracy or correctness. A ‘mistake’ is
an error caused by a fault: the fault being misjudgment, carelessness,
or forgetfulness. Now, say that I run a stop sign because I was in a
hurry, and wasn’t concentrating, and the police stop me, that is a
mistake. If, however, I try to park in an area with conflicting signs,
and I get a ticket because I was incorrect on my interpretation of
what the signs meant, that would be an error. The first time it would
be an error. The second time it would be a mistake since I should have
known better.

https://en.wikipedia.org/wiki/Error

For build failures. Hmm. I think if the build cannot build it is a build failure. When it does not meet its requirements it just a defect, or an improvements depending on its classification. Calling it a failure does not add a lot of value. Still it might fail as a product, because its requirements were not met, but is the build a failure? Only time will tell, maybe the requirements were wrong to start with.

So from my perspective that quote you found on a website is not correct, but I think I could also create an argument for it being valid. :)

answered Apr 19, 2017 at 15:18

Niels van Reijmersdal's user avatar

Honestly, it depends on the organization, the developement methodology, and the QA guidelines. You could say a defect is simply a bug report, a bug is a confirmed bug, an error is a user-facing error (or is user error — an error caused by the user), a fault is a type of bug, and a failure is when, for any number of reasons, the system does not meet the agreed upon standards or metrics that it was designed to meet.

All of these change depending on your organization and personal opinion. A website that expects 50 purchases per day and is very well designed and bug free, but only nets 49 purchases per day could be called a failure by management, despite being bug, defect, and error free.

answered Jun 12, 2017 at 22:13

jmclaughlin's user avatar

In today’s world of software functional testing services these are some terms that requires clarification and below
are the details:

Error:
Error is a human action that produces an incorrect result. It is deviation from actual and expected value. The mistakes made by programmer is known as an ‘Error’.

Failure:
Failure is a deviation of the software from its intended purpose. It is the inability of a system or a component to perform its required functions within specified requirements.

Bug:
A Bug is the result of a coding Error or Fault in the program which causes the program to behave in an unintended or unanticipated manner. Bugs arise from mistakes and errors, made by people, in either a program’s source code or its design.

Fault or Defect:
A Defect is a deviation from the Requirements. A Defect is a condition in a software product which does not meet a software requirement. In other words, a defect is an error in coding or logic that causes a program to malfunction or to produce incorrect/unexpected result. This could be hardware, software, network, performance, format, or functionality.

Conclusion:

A Bug is the result of a coding Error and A Defect is a deviation from the Requirements. A defect does not necessarily mean there is a bug in the code, it could be a function that was not implemented but defined in the requirements of the software.

answered Jun 15, 2017 at 12:13

Anand's user avatar

AnandAnand

7554 silver badges8 bronze badges

Asked
5 years, 9 months ago

Viewed
6k times

I was reading the differences between defect, error, bug and failure. I found a website that says about them. Are these correct?

A mistake in coding is called error, error found by tester is
called defect, defect accepted by development team then it is called
bug , build does not meet the requirements then it Is failure.

Error: A discrepancy between a computed, observed, or measured value or condition and the true, specified, or theoretically correct
value or condition. This can be a misunderstanding of the internal
state of the software, an oversight in terms of memory management,
confusion about the proper way to calculate a value, etc.

Failure: The inability of a system or component to perform its required functions within specified performance requirements. See:
bug, crash, exception, and fault.

Bug: A fault in a program which causes the program to perform in an unintended or unanticipated manner. See: anomaly, defect, error,
exception, and fault. The bug is terminology of Tester.

Fault: An incorrect step, process, or data definition in a computer program which causes the program to perform in an unintended
or unanticipated manner. See: bug, defect, error, exception.

Defect: Commonly refers to several troubles with the software products, with its external behavior or with its internal features.

Source: Click here

Bharat Mane's user avatar

Bharat Mane

6,76910 gold badges38 silver badges67 bronze badges

asked Apr 19, 2017 at 14:42

Muhammad Ali Khamis's user avatar

1

ISQTB foundation level material states the following:

A human being can make an error (mistake), which produces a defect
(fault, bug) in the program code, or in a document.

If a defect in code is executed, the system may fail to do what it
should do (or do something it shouldn’t), causing a failure.

Defects in software, systems or documents may result in failures, but
not all defects do so.

If you read this definition carefully, I think it is pretty self-explanatory.

answered Apr 20, 2017 at 7:44

Zvonimir Horvatic's user avatar

1

As with most testing terminology it depends on the company, person and or industry. It is a means to communicate. When in doubt ask what people mean with it within its context.

For me bugs and defects are the same. Bugs are something from the 40ties according to Wikipedia.

featuring a dead moth that was removed from the device

I would push for calling all bugs defects instead, because dead animals do not anymore block computer systems.

Coding mistakes are just coding mistakes, they could cause errors.

An ‘error’ is a deviation from accuracy or correctness. A ‘mistake’ is
an error caused by a fault: the fault being misjudgment, carelessness,
or forgetfulness. Now, say that I run a stop sign because I was in a
hurry, and wasn’t concentrating, and the police stop me, that is a
mistake. If, however, I try to park in an area with conflicting signs,
and I get a ticket because I was incorrect on my interpretation of
what the signs meant, that would be an error. The first time it would
be an error. The second time it would be a mistake since I should have
known better.

https://en.wikipedia.org/wiki/Error

For build failures. Hmm. I think if the build cannot build it is a build failure. When it does not meet its requirements it just a defect, or an improvements depending on its classification. Calling it a failure does not add a lot of value. Still it might fail as a product, because its requirements were not met, but is the build a failure? Only time will tell, maybe the requirements were wrong to start with.

So from my perspective that quote you found on a website is not correct, but I think I could also create an argument for it being valid. :)

answered Apr 19, 2017 at 15:18

Niels van Reijmersdal's user avatar

Honestly, it depends on the organization, the developement methodology, and the QA guidelines. You could say a defect is simply a bug report, a bug is a confirmed bug, an error is a user-facing error (or is user error — an error caused by the user), a fault is a type of bug, and a failure is when, for any number of reasons, the system does not meet the agreed upon standards or metrics that it was designed to meet.

All of these change depending on your organization and personal opinion. A website that expects 50 purchases per day and is very well designed and bug free, but only nets 49 purchases per day could be called a failure by management, despite being bug, defect, and error free.

answered Jun 12, 2017 at 22:13

jmclaughlin's user avatar

In today’s world of software functional testing services these are some terms that requires clarification and below
are the details:

Error:
Error is a human action that produces an incorrect result. It is deviation from actual and expected value. The mistakes made by programmer is known as an ‘Error’.

Failure:
Failure is a deviation of the software from its intended purpose. It is the inability of a system or a component to perform its required functions within specified requirements.

Bug:
A Bug is the result of a coding Error or Fault in the program which causes the program to behave in an unintended or unanticipated manner. Bugs arise from mistakes and errors, made by people, in either a program’s source code or its design.

Fault or Defect:
A Defect is a deviation from the Requirements. A Defect is a condition in a software product which does not meet a software requirement. In other words, a defect is an error in coding or logic that causes a program to malfunction or to produce incorrect/unexpected result. This could be hardware, software, network, performance, format, or functionality.

Conclusion:

A Bug is the result of a coding Error and A Defect is a deviation from the Requirements. A defect does not necessarily mean there is a bug in the code, it could be a function that was not implemented but defined in the requirements of the software.

answered Jun 15, 2017 at 12:13

Anand's user avatar

AnandAnand

7554 silver badges8 bronze badges

Дефекты.  Ошибки, сбои, отказы

Дефекты. Ошибки, сбои, отказы

Дефект — расхождение ожидаемого и фактического результата. Или дефект — отклонение фактического результата от ожиданий наблюдателя, сформированных на основе требований, спецификаций, иной документации или опыта и здравого смысла. Ожидаемый результат — поведение системы, описанное в требованиях. Фактический результат — поведение системы, наблюдаемое в процессе тестирования. Ошибки совершает человек , которые приводят к возникновению дефектов в коде, которые, в свою очередь, приводят к сбоям и отказам приложения (однако сбои и отказы могут возникать и из-за внешних условий, таких как электромагнитное воздействие на оборудование и т.д.). Таким образом, упрощённо можно изобразить следующую схему

Дефект — расхождение ожидаемого и фактического результата. Или дефект — отклонение фактического результата от ожиданий наблюдателя, сформированных на основе требований, спецификаций, иной документации или опыта и здравого смысла.

Ожидаемый результат — поведение системы, описанное в требованиях.

Фактический результат — поведение системы, наблюдаемое в процессе тестирования.

Ошибки совершает человек , которые приводят к возникновению дефектов в коде, которые, в свою очередь, приводят к сбоям и отказам приложения (однако сбои и отказы могут возникать и из-за внешних условий, таких как электромагнитное воздействие на оборудование и т.д.). Таким образом, упрощённо можно изобразить следующую схему

Ошибка (error , mistake) — действие человека, приводящее к некорректным результатам. Дефект (defect, bug, problem, fault) — недостаток в компоненте или системе, способный привести к ситуации сбоя или отказа. Дефекты могут быть в документации, настройках, входных данных и т.д. Сбой или отказ — отклонение поведения системы от ожидаемого. В ГОСТ 27.002-89 даны краткие определения сбоя и отказа : Сбой  — самоустраняющийся отказ или однократный отказ, устраняемый незначительным вмешательством оператора. Отказ — событие, заключающееся в нарушении работоспособного состояния объекта. Сбои и отказы являются тем, что тестировщик замечает в процессе тестирования и отталкиваясь от чего, проводит исследование с целью выявить дефект и его причины. Отчёт о дефекте и его жизненный цикл При обнаружении дефекта тестировщик создаёт отчёт о дефекте .  Отчёт о дефекте — документ, описывающий обнаруженный дефект, а также содействующий его устранению

Ошибка (error , mistake) — действие человека, приводящее к некорректным результатам.

Дефект (defect, bug, problem, fault) — недостаток в компоненте или системе, способный привести к ситуации сбоя или отказа.

Дефекты могут быть в документации, настройках, входных данных и т.д.

Сбой или отказ — отклонение поведения системы от ожидаемого.

В ГОСТ 27.002-89 даны краткие определения сбоя и отказа :

Сбой — самоустраняющийся отказ или однократный отказ, устраняемый незначительным вмешательством оператора.

Отказ — событие, заключающееся в нарушении работоспособного состояния объекта.

Сбои и отказы являются тем, что тестировщик замечает в процессе тестирования и отталкиваясь от чего, проводит исследование с целью выявить дефект и его причины.

Отчёт о дефекте и его жизненный цикл

При обнаружении дефекта тестировщик создаёт отчёт о дефекте .

Отчёт о дефекте — документ, описывающий обнаруженный дефект, а также содействующий его устранению

Отчёт о дефекте пишется со следующими основными целями: предоставить информацию о проблеме — уведомить проектную команду и иных заинтересованных лиц о наличии проблемы, описать суть проблемы; приоритизировать проблему — определить степень опасности проблемы для проекта и желаемые сроки её устранения; содействовать устранению проблемы — качественный отчёт о дефекте не только предоставляет все необходимые подробности для понимания сути случившегося, но также может содержать анализ причин возникновения проблемы и рекомендации по исправлению ситуации. Хорошо написанный отчёт о дефекте — половина решения проблемы для программиста. От полноты, корректности, аккуратности, подробности и логичности отчёта о дефекте зависит очень многое — одна и та же проблема может быть описана так, что программисту останется исправить пару строк кода, а может быть описана и так, что сам автор отчёта на следующий день не сможет понять, что же он имел в виду.

Отчёт о дефекте пишется со следующими основными целями:

  • предоставить информацию о проблеме — уведомить проектную команду и иных заинтересованных лиц о наличии проблемы, описать суть проблемы; приоритизировать проблему — определить степень опасности проблемы для проекта и желаемые сроки её устранения;
  • содействовать устранению проблемы — качественный отчёт о дефекте не только предоставляет все необходимые подробности для понимания сути случившегося, но также может содержать анализ причин возникновения проблемы и рекомендации по исправлению ситуации.

Хорошо написанный отчёт о дефекте — половина решения проблемы для программиста. От полноты, корректности, аккуратности, подробности и логичности отчёта о дефекте зависит очень многое — одна и та же проблема может быть описана так, что программисту останется исправить пару строк кода, а может быть описана и так, что сам автор отчёта на следующий день не сможет понять, что же он имел в виду.

Отчёт о дефекте (и сам дефект вместе с ним) проходит определённые стадии жизненного цикла, которые схематично можно показать так (рисунок 2на следующем слайде):

  • Обнаружен (submitted) — начальное состояние отчёта (иногда называется «Новый» (new)), в котором он находится сразу после создания. Некоторые средства также позволяют сначала создавать черновик (draft) и лишь потом публиковать отчёт.
  • Назначен (assigned) — в это состояние отчёт переходит с момента, когда кто — то из проектной команды назначается ответственным за исправление дефекта. Назначение ответственного производится или решением лидера команды разработки, или коллегиально, или по добровольному принципу, или иным принятым в команде способом или выполняется автоматически на основе определённых правил.
  • Исправлен (fixed) — в это состояние отчёт переводит ответственный за исправление дефекта член команды после выполнения соответствующих действий по исправлению.
  • Проверен (verified) — в это состояние отчёт переводит тестировщик, удостоверившийся, что дефект на самом деле был устранён. Как правило, такую проверку выполняет тестировщик, изначально написавший отчёт о дефекте.

Свежий взгляд человека, ранее не знакомого с данным дефектом, позволяет ему в процессе верификации с большой вероятностью обнаружить новые дефекты. Жизненный цикл отчёта о дефекте с наиболее типичными переходами между состояниями

Свежий взгляд человека, ранее не знакомого с данным дефектом, позволяет ему в процессе верификации с большой вероятностью обнаружить новые дефекты.

Жизненный цикл отчёта о дефекте с наиболее типичными переходами между состояниями

Набор стадий жизненного цикла, их наименование и принцип перехода от стадии к стадии может различаться в разных инструментальных средствах управления жизненным циклом отчётов о дефектах. Более того — многие такие средства позволяют гибко настраивать эти параметры. Закрыт (closed) — состояние отчёта, означающее, что по данному дефекту не планируется никаких дальнейших действий. Здесь есть некоторые расхождения в жизненном цикле, принятом в разных инструментальных средствах управления отчётами о дефектах: В некоторых средствах существуют оба состояния — « Проверен » и « Закрыт », чтобы подчеркнуть, что в состоянии « Проверен » ещё могут потребоваться какие-то дополнительные действия (обсуждения, дополнительные проверки) в то время как состояние « Закрыт » означает «с дефектом покончено, больше к этому вопросу не возвращаемся». В некоторых средствах одного из состояний нет (оно поглощается другим)

Набор стадий жизненного цикла, их наименование и принцип перехода от стадии к стадии может различаться в разных инструментальных средствах управления жизненным циклом отчётов о дефектах. Более того — многие такие средства позволяют гибко настраивать эти параметры.

  • Закрыт (closed) — состояние отчёта, означающее, что по данному дефекту не планируется никаких дальнейших действий.

Здесь есть некоторые расхождения в жизненном цикле, принятом в разных инструментальных средствах управления отчётами о дефектах:

В некоторых средствах существуют оба состояния — « Проверен » и « Закрыт », чтобы подчеркнуть, что в состоянии « Проверен » ещё могут потребоваться какие-то дополнительные действия (обсуждения, дополнительные проверки) в то время как состояние « Закрыт » означает «с дефектом покончено, больше к этому вопросу не возвращаемся».

  • В некоторых средствах одного из состояний нет (оно поглощается другим)

В некоторых средствах в состояние «Закрыт» или «Отклонён» отчёт о дефекте может быть переведён из множества предшествующих состояний с резолюциями наподобие: «Не является дефектом» — приложение так и должно работать, описанное поведение не является аномальным. «Дубликат» — данный дефект уже описан в другом отчёте. «Не удалось воспроизвести» — разработчикам не удалось воспроизвести проблему на своём оборудовании. «Не будет исправлено» — дефект есть, но по каким-то серьёзным причинам его решено не исправлять. «Невозможно исправить» — непреодолимая причина дефекта находится вне области полномочий команды разработчиков, например существует проблема в операционной системе или аппаратном обеспечении, влияние которой устранить разумными способами невозможно. В подобных случаях будет переведён в состояние «Закрыт», в некоторых — в состояние «Отклонён», в некоторых — часть случаев закреплена за состоянием «Закрыт», часть — за «Отклонён».

В некоторых средствах в состояние «Закрыт» или «Отклонён» отчёт о дефекте может быть переведён из множества предшествующих состояний с резолюциями наподобие:

  • «Не является дефектом» — приложение так и должно работать, описанное поведение не является аномальным.
  • «Дубликат» — данный дефект уже описан в другом отчёте.
  • «Не удалось воспроизвести» — разработчикам не удалось воспроизвести проблему на своём оборудовании.
  • «Не будет исправлено» — дефект есть, но по каким-то серьёзным причинам его решено не исправлять.
  • «Невозможно исправить» — непреодолимая причина дефекта находится вне области полномочий команды разработчиков, например существует проблема в операционной системе или аппаратном обеспечении, влияние которой устранить разумными способами невозможно. В подобных случаях будет переведён в состояние «Закрыт», в некоторых — в состояние «Отклонён», в некоторых — часть случаев закреплена за состоянием «Закрыт», часть — за «Отклонён».
  • Открыт заново (reopened) — в это состояние (как правило, из состояния «Исправлен») отчёт переводит тестировщик, удостоверившийся, что дефект попрежнему воспроизводится на билде, в котором он уже должен быть исправлен.
  • Рекомендован к отклонению (to be declined) — в это состояние отчёт о дефекте может быть переведён из множества других состояний с целью вынести на рассмотрение вопрос об отклонении отчёта по той или иной причине. Если рекомендация является обоснованной, отчёт переводится в состояние «Отклонён» (см. следующий пункт).
  • Отклонён (declined) — в это состояние отчёт переводится в случаях, подробно описанных в пункте «Закрыт», если средство управления отчётами о дефектах предполагает использование этого состояния вместо состояния «Закрыт» для тех или иных резолюций по отчёту.
  • Отложен (deferred) — в это состояние отчёт переводится в случае, если исправление дефекта в ближайшее время является нерациональным или не представляется возможным, однако есть основания полагать, что скоро ситуация исправится (выйдет новая версия библиотеки, вернётся из отпуска специалист по данной технологии, изменятся требования заказчика и т.д.).

Атрибуты (поля) отчёта о дефекте Общий вид всей структуры отчёта о дефекте представлен на рисунке

Атрибуты (поля) отчёта о дефекте

Общий вид всей структуры отчёта о дефекте представлен на рисунке

  • Идентификатор представляет собой уникальное значение, позволяющее однозначно отличить один отчёт о дефекте от другого и используемое во всевозможных ссылках. В общем случае идентификатор отчёта о дефекте может представлять собой просто уникальный номер, но может быть : включать префиксы, суффиксы и иные осмысленные компоненты, позволяющие быстро определить суть дефекта и часть приложения (или требований), к которой он относится.
  • Краткое описание должно в предельно лаконичной форме давать исчерпывающий ответ на вопросы «Что произошло?» «Где это произошло»? «При каких условиях это произошло?».

Например: «Отсутствует логотип на странице приветствия, если пользователь

является администратором»:

— Что произошло? Отсутствует логотип.

— Где это произошло? На странице приветствия.

— При каких условиях это произошло? Если пользователь является

администратором.

Заполнение поля « краткое описание », которое одновременно должно:

— содержать предельно краткую, но в то же время достаточную для

понимания сути проблемы информацию о дефекте;

— быть достаточно коротким, чтобы полностью помещаться на экране;

 - при необходимости содержать информацию об окружении, под  которым был обнаружен дефект;  - по возможности не дублировать краткие описания других  дефектов (и даже не быть похожими на них), чтобы дефекты  было сложно перепутать или посчитать дубликатами друг друга;  - быть законченным предложением русского или английского (или  иного) языка, построенным по соответствующим правилам  грамматики. Для создания хороших кратких описаний дефектов рекомендуется пользоваться следующим алгоритмом: Полноценно понять суть проблемы. До тех пор, пока у тестировщика нет чёткого понимания того, «что не работает», писать отчёт о дефекте не стоит. Сформулировать подробное описание 3. Убрать из получившегося подробного описания всё лишнее, уточнить важные детали.

— при необходимости содержать информацию об окружении, под

которым был обнаружен дефект;

— по возможности не дублировать краткие описания других

дефектов (и даже не быть похожими на них), чтобы дефекты

было сложно перепутать или посчитать дубликатами друг друга;

— быть законченным предложением русского или английского (или

иного) языка, построенным по соответствующим правилам

грамматики.

Для создания хороших кратких описаний дефектов рекомендуется пользоваться следующим алгоритмом:

  • Полноценно понять суть проблемы. До тех пор, пока у тестировщика нет чёткого понимания того, «что не работает», писать отчёт о дефекте не стоит.
  • Сформулировать подробное описание
  • 3. Убрать из получившегося подробного описания всё лишнее, уточнить важные детали.

 4. Выделить в подробном описании слова (словосочетания, фрагменты фраз), отвечающие на вопросы, «что, где и при каких условиях случилось».  5. Оформить получившееся в пункте 4 в виде законченного грамматически правильного предложения.  6. Если предложение получилось слишком длинным, переформулировать  его, сократив длину (за счёт подбора синонимов, использования  общепринятых аббревиатур и сокращений). К слову, в английском языке  предложение почти всегда будет короче русского аналога. Пример применения этого алгоритма. Тестированию подвергается некое веб-приложение, поле описания товара должно допускать ввод максимум 250 символов; в процессе тестирования оказалось, что этого ограничения нет. Суть проблемы: исследование показало, что ни на клиентской, ни на серверной части нет никаких механизмов, проверяющих и/или ограничивающих длину введённых в поле «О товаре» данных. Исходный вариант подробного описания: в клиентской и серверной части приложения отсутствуют проверка и ограничение длины данных, вводимых в поле «О товаре» на странице http://testapplication/admin/goods/edit.

4. Выделить в подробном описании слова (словосочетания, фрагменты фраз), отвечающие на вопросы, «что, где и при каких условиях случилось».

5. Оформить получившееся в пункте 4 в виде законченного грамматически правильного предложения.

6. Если предложение получилось слишком длинным, переформулировать

его, сократив длину (за счёт подбора синонимов, использования

общепринятых аббревиатур и сокращений). К слову, в английском языке

предложение почти всегда будет короче русского аналога.

Пример применения этого алгоритма.

Тестированию подвергается некое веб-приложение, поле описания товара должно допускать ввод максимум 250 символов; в процессе тестирования оказалось, что этого ограничения нет.

  • Суть проблемы: исследование показало, что ни на клиентской, ни на серверной части нет никаких механизмов, проверяющих и/или ограничивающих длину введённых в поле «О товаре» данных.
  • Исходный вариант подробного описания: в клиентской и серверной части приложения отсутствуют проверка и ограничение длины данных, вводимых в поле «О товаре» на странице http://testapplication/admin/goods/edit.

Конечный вариант подробного описания:  - Фактический результат: в описании товара (поле «О товаре»,  http://testapplication/admin/goods/edit/) отсутствуют проверка и  ограничение длины вводимого текста (MAX=250 символов).  - Ожидаемый результат: в случае попытки ввода 251+ символов  выводится сообщение об ошибке. Определение «что, где и при каких условиях случилось»:  - Что: отсутствуют проверка и ограничение длины вводимого текста.  - Где: описание товара, поле «О товаре»,  http://testapplication/admin/goods/edit/.  - При каких условиях: – (в данном случае дефект присутствует всегда, вне  зависимости от каких бы то ни было особых условий). Первичная формулировка: отсутствуют проверка и ограничение максимальной длины текста, вводимого в поле «О товаре» описания товара. Сокращение (итоговое краткое описание): нет ограничения максимальной длины поля «О товаре». Английский вариант: no check for «О товаре» max length.

  • Конечный вариант подробного описания:

— Фактический результат: в описании товара (поле «О товаре»,

http://testapplication/admin/goods/edit/) отсутствуют проверка и

ограничение длины вводимого текста (MAX=250 символов).

— Ожидаемый результат: в случае попытки ввода 251+ символов

выводится сообщение об ошибке.

  • Определение «что, где и при каких условиях случилось»:

— Что: отсутствуют проверка и ограничение длины вводимого текста.

— Где: описание товара, поле «О товаре»,

http://testapplication/admin/goods/edit/.

— При каких условиях: – (в данном случае дефект присутствует всегда, вне

зависимости от каких бы то ни было особых условий).

  • Первичная формулировка: отсутствуют проверка и ограничение максимальной длины текста, вводимого в поле «О товаре» описания товара.
  • Сокращение (итоговое краткое описание): нет ограничения максимальной длины поля «О товаре». Английский вариант: no check for «О товаре» max length.

Подробное описание представляет в развёрнутом виде необходимую информацию о дефекте, а также (обязательно!) описание фактического результата, ожидаемого результата и ссылку на требование (если это возможно). Пример подробного описания : Если в систему входит администратор, на странице приветствия отсутствует логотип. Фактический результат: логотип отсутствует в левом верхнем углу страницы. Ожидаемый результат: логотип отображается в левом верхнем углу страницы. Требование: R245.3.23b. В отличие от краткого описания, которое является одним предложением, здесь нужно давать подробную информацию. Если одна и та же проблема (вызванная одним источником) проявляется в нескольких местах приложения, можно в подробном описании перечислить эти места. Шаги по воспроизведению описывают действия, которые необходимо выполнить для воспроизведения дефекта.

  • Подробное описание представляет в развёрнутом виде необходимую информацию о дефекте, а также (обязательно!) описание фактического результата, ожидаемого результата и ссылку на требование (если это возможно).

Пример подробного описания :

Если в систему входит администратор, на странице приветствия отсутствует логотип. Фактический результат: логотип отсутствует в левом верхнем углу страницы. Ожидаемый результат: логотип отображается в левом верхнем углу страницы. Требование: R245.3.23b.

В отличие от краткого описания, которое является одним предложением, здесь нужно давать подробную информацию. Если одна и та же проблема (вызванная одним источником) проявляется в нескольких местах приложения, можно в подробном описании перечислить эти места.

  • Шаги по воспроизведению описывают действия, которые необходимо выполнить для воспроизведения дефекта.

Это поле похоже на шаги тест-кейса, за исключением одного отличия: здесь действия прописываются максимально подробно, с указанием конкретных вводимых значений и самых мелких деталей, т.к. отсутствие этой информации в сложных случаях может привести к невозможности воспроизведения дефекта.

Пример шагов воспроизведения :

  • Открыть http://testapplication/admin/login/.
  • Авторизоваться с именем «defaultadmin» и паролем «dapassword». Дефект : в левом верхнем углу страницы отсутствует логотип (вместо него отображается пустое пространство с надписью «logo»).

Воспроизводимость показывает, при каждом ли прохождении по шагам воспроизведения дефекта удаётся вызвать его проявление. Это поле принимает всего два значения: всегда или иногда. Можно сказать, что воспроизводимость «иногда» означает, что тестировщик не нашёл настоящую причину возникновения дефекта. Это приводит к серьёзным дополнительным сложностям в работе с дефектом:

  • Тестировщику нужно потратить много времени на то, чтобы удостовериться в наличии дефекта (т.к. однократный сбой в работе приложения мог быть вызван большим количеством посторонних причин).

 Разработчику тоже нужно потратить время, чтобы добиться проявления дефекта и убедиться в его наличии. После внесения исправлений в приложение разработчик фактически должен полагаться только на свой профессионализм, т.к. даже многократное прохождение по шагам воспроизведения в таком случае не гарантирует, что дефект был исправлен (возможно, через ещё 10–20 повторений он бы проявился). Важность показывает степень ущерба, который наносится проекту существованием дефекта. В общем случае выделяют следующие виды важности:  - Критическая — существование дефекта приводит к масштабным последствиям катастрофического характера, например: потеря данных, раскрытие конфиденциальной информации, нарушение ключевой функциональности приложения и т.д.  - Высокая — существование дефекта приносит ощутимые неудобства многим пользователям в рамках их типичной деятельности, например: недоступность вставки из буфера обмена, неработоспособность общепринятых клавиатурных комбинаций, необходимость перезапуска приложения при выполнении типичных сценариев работы.

  • Разработчику тоже нужно потратить время, чтобы добиться проявления дефекта и убедиться в его наличии. После внесения исправлений в приложение разработчик фактически должен полагаться только на свой профессионализм, т.к. даже многократное прохождение по шагам воспроизведения в таком случае не гарантирует, что дефект был исправлен (возможно, через ещё 10–20 повторений он бы проявился).
  • Важность показывает степень ущерба, который наносится проекту существованием дефекта. В общем случае выделяют следующие виды важности:

Критическая — существование дефекта приводит к масштабным последствиям катастрофического характера, например: потеря данных, раскрытие конфиденциальной информации, нарушение ключевой функциональности приложения и т.д.

Высокая — существование дефекта приносит ощутимые неудобства многим пользователям в рамках их типичной деятельности, например: недоступность вставки из буфера обмена, неработоспособность общепринятых клавиатурных комбинаций, необходимость перезапуска приложения при выполнении типичных сценариев работы.

 - Средняя — существование дефекта слабо влияет на типичные  сценарии работы пользователей, и/или существует обходной путь  достижения цели, например: диалоговое окно не закрывается  автоматически после нажатия кнопок «OK»/«Cancel», при распечатке  нескольких документов подряд не сохраняется значение поля  «Двусторонняя печать», перепутаны направления сортировок по  некоему полю таблицы.  - Низкая — существование дефекта редко обнаруживается  незначительным процентом пользователей и (почти) не влияет на их  работу, например: опечатка в глубоко вложенном пункте меню  настроек, некоторое окно при отображении расположено неудобно  (нужно перетянуть его в удобное место), неточно отображается время  до завершения операции копирования файлов.

Средняя — существование дефекта слабо влияет на типичные

сценарии работы пользователей, и/или существует обходной путь

достижения цели, например: диалоговое окно не закрывается

автоматически после нажатия кнопок «OK»/«Cancel», при распечатке

нескольких документов подряд не сохраняется значение поля

«Двусторонняя печать», перепутаны направления сортировок по

некоему полю таблицы.

Низкая — существование дефекта редко обнаруживается

незначительным процентом пользователей и (почти) не влияет на их

работу, например: опечатка в глубоко вложенном пункте меню

настроек, некоторое окно при отображении расположено неудобно

(нужно перетянуть его в удобное место), неточно отображается время

до завершения операции копирования файлов.

Срочность показывает, как быстро дефект должен быть устранён. В общем случае выделяют следующие виды срочности: Наивысшая срочность указывает на необходимость устранить дефект настолько быстро, насколько это возможно. Высокая срочность означает, что дефект следует исправить вне очереди, т.к. его существование или уже объективно мешает работе, или начнёт создавать такие помехи в самом ближайшем будущем. Обычная срочность означает, что дефект следует исправить в порядке общей очерёдности. Такое значение срочности получает большинство дефектов. Низкая срочность означает, что в обозримом будущем исправление данного дефекта не окажет существенного влияния на повышение качества продукта.

  • Срочность показывает, как быстро дефект должен быть устранён. В общем случае выделяют следующие виды срочности:
  • Наивысшая срочность указывает на необходимость устранить дефект настолько быстро, насколько это возможно.
  • Высокая срочность означает, что дефект следует исправить вне очереди, т.к. его существование или уже объективно мешает работе, или начнёт создавать такие помехи в самом ближайшем будущем.
  • Обычная срочность означает, что дефект следует исправить в порядке общей очерёдности. Такое значение срочности получает большинство дефектов.
  • Низкая срочность означает, что в обозримом будущем исправление данного дефекта не окажет существенного влияния на повышение качества продукта.
  • С имптом — позволяет классифицировать дефекты по их типичному проявлению. Не существует никакого общепринятого списка симптомов.

В качестве примера рассмотрим следующие значения симптомов дефекта.

  • Косметический дефект — визуально заметный недостаток интерфейса, не влияющий на функциональность приложения (например, надпись на кнопке выполнена шрифтом не той гарнитуры).
  • Повреждение/потеря данных — в результате возникновения дефекта искажаются, уничтожаются (или не сохраняются) некоторые данные (например, при копировании файлов копии оказываются повреждёнными).
  • Проблема в документации (— дефект относится не к приложению, а к документации (например, отсутствует раздел руководства по эксплуатации).
  • Некорректная операция — некоторая операция выполняется некорректно
  • Проблема инсталляции — дефект проявляется на стадии установки и/или конфигурирования приложения.
  • Ошибка локализации — что-то в приложении не переведено или переведено неверно на выбранный язык интерфейса.
  • Нереализованная функциональность — некая функция приложения не выполняется или не может быть вызвана (например, в списке форматов для экспорта документа отсутствует несколько пунктов, которые там должны быть
  • Проблема масштабируемости — при увеличении количества доступных приложению ресурсов не происходит ожидаемого прироста производительности приложения
  • Низкая производительность — выполнение неких операций занимает недопустимо большое время
  • Крах системы — приложение прекращает работу или теряет способность выполнять свои ключевые функции
  • Неожиданное поведение — в процессе выполнения некоторой типичной операции приложение ведёт себя необычным (отличным от общепринятого) образом (например, после добавления в список новой записи активной становится не новая запись, а первая в списке).
  • Недружественное поведение — поведение приложения создаёт пользователю неудобства в работе (например, на разных диалоговых окнах в разном порядке расположены кнопки «OK» и «Cancel»).
  • Расхождение с требованиями — этот симптом указывают, если дефект сложно соотнести с другими симптомами, но тем не менее приложение ведёт себя не так, как описано в требованиях.
  • Предложение по улучшению — во многих инструментальных средствах управления отчётами о дефектах для этого случая есть отдельный вид отчёта

Часто у одного дефекта может быть сразу несколько симптомов. Возможность обойти — показывает, существует ли альтернативная последовательность действий, выполнение которой позволило бы пользователю достичь поставленной цели (например, клавиатурная комбинация Ctrl+P не работает, но распечатать документ можно, выбрав соответствующие пункты в меню). В некоторых инструментальных средствах управления отчётами о дефектах это поле может просто принимать значения «Да» и «Нет», в некоторых при выборе «Да» появляется возможность описать обходной путь. Традиционно считается, что дефектам без возможности обхода стоит повысить срочность исправления. Комментарий— может содержать любые полезные для понимания и исправления дефекта данные. Вложения — представляет собой не столько поле, сколько список прикреплённых к отчёту о дефекте приложений (копий экрана, вызывающих сбой файлов и т.д.).

Часто у одного дефекта может быть сразу несколько симптомов.

  • Возможность обойти — показывает, существует ли альтернативная последовательность действий, выполнение которой позволило бы пользователю достичь поставленной цели (например, клавиатурная комбинация Ctrl+P не работает, но распечатать документ можно, выбрав соответствующие пункты в меню). В некоторых инструментальных средствах управления отчётами о дефектах это поле может просто принимать значения «Да» и «Нет», в некоторых при выборе «Да» появляется возможность описать обходной путь. Традиционно считается, что дефектам без возможности обхода стоит повысить срочность исправления.
  • Комментарий— может содержать любые полезные для понимания и исправления дефекта данные.
  • Вложения — представляет собой не столько поле, сколько список прикреплённых к отчёту о дефекте приложений (копий экрана, вызывающих сбой файлов и т.д.).

Improve Article

Save Article

  • Read
  • Discuss
  • Improve Article

    Save Article

    Software Testing defines a set of procedures and methods that check whether the actual software product matches with expected requirements, thereby ensuring that the product is Defect free. There are a set of procedures that needs to be in mind while testing the software manually or by using automated procedures. The main purpose of software testing is to identify errors, deficiencies, or missing requirements with respect to actual requirements.

    Software Testing is Important because if there are any bugs or errors in the software, they can be identified early and can be solved before the delivery of the software product. 

    Here we will discuss 5 terms related to SDLC:

    1. Bug: A bug refers to defects which means that the software product or the application is not working as per the adhered requirements set. When we have any type of logical error, it causes our code to break, which results in a bug. It is now that the Automation/ Manual Test Engineers describe this situation as a bug.
      A bug once detected can be reproduced with the help of standard bug reporting templates.
    2. Defect: A defect refers to the situation when the application is not working as per the requirement and the actual and expected result of the application or software are not in sync with each other.
    3. Fault: Sometimes due to certain factors such as Lack of resources or not following proper steps Fault occurs in software which means that the logic was not incorporated to handle the errors in the application. This is an undesirable situation, but it mainly happens due to invalid documented steps or a lack of data definitions.
    4. Failure: Failure is the accumulation of several defects that ultimately lead to Software failure and results in the loss of information in critical modules thereby making the system unresponsive. Generally, such situations happen very rarely because before releasing a product all possible scenarios and test cases for the code are simulated.  Failure is detected by end-users once they face a particular issue in the software.
    5. Error: Error is a situation that happens when the Development team or the developer fails to understand a requirement definition and hence that misunderstanding gets translated to buggy code. This situation is referred to as an Error and is mainly a term coined by the developers.

    A simple diagram depicting Bug vs Defect vs Fault vs Failure:

    Bug vs Defect vs Fault vs Failures vs Error

    Bug vs Defect vs Error vs Fault vs Failure:

    Some of the vital differences between bug, defect, fault, error, and failure are listed in the below table:

    Basis Bug Defect Fault Error Failure
    Definition A bug refers to defects which means that the software product or the application is not working as per the adhered requirements set A Defect is a deviation between the actual and expected output A Fault is a state that causes the software to fail and therefore it does not achieve its necessary function. An Error is a mistake made in the code due to which compilation or execution fails, Failure is the accumulation of several defects that ultimately lead to Software failure and results in the loss of information in critical modules thereby making the system unresponsive.
    Raised by Test Engineers  The defect is identified by The Testers And is resolved by developers in the development phase of SDLC. Human mistakes lead to fault. Developers and automation test engineers The failure is found by the test engineer during the  development cycle of SDLC
    Different types
    • Logical bugs
    • Algorithmic bugs
    • Resource bugs

     Defects are classified as follows:
    Based on Priority:

    • High
    • Medium
    • Low

    Based on Severity:

    • Critical
    • Major
    • Minor
    • Trivial
    • Business Logic Faults
    • Functional and Logical Faults
    • Graphical User Interface (GUI) Faults
    • Performance Faults
    • Security Faults
    • Hardware Faults
    • Syntactic Error
    • UI screen error
    • Error handling error
    • Flow control error
    • Calculation error
    • Hardware error
       
    NA
    Reasons behind
    • Missing Logic
    • Erroneous Logic
    • Redundant codes
       
    • Receiving & providing incorrect input
    • Coding/Logical Error leading to the breakdown of software
    • Wrong design of the data definition processes.
    • An irregularity in Logic or gaps in the software lead to the non-functioning of the software.
    • Error in code.
    • Inability to compile/execute a program 
    • Ambiguity in code logic
    • Misunderstanding of requirements
    • Faulty design and architecture
    • Logical error
    • Environment variables
    • System Errors
    • Human Error
    Way to prevent the reasons
    • Implementing Test-driven development.
    • Adjusting enhanced development practices and evaluation of
       cleanliness of the code.
    • Implementing Out-of-the-box programming methods.
    • Proper usage of primary and correct software coding practices.
       
    • Peer review of the Test documents and requirements.
    • Verifying the correctness of software design and coding.
    • Conduct peer reviews and code-reviews
    • Need for validation of bug fixes and enhancing the overall quality of the software.
    • Confirmation of Re-testing the process end to end,
    • Carefully review the requirements as well as the specifications.
    • Categorizing and evaluating the errors and issues.

    Most of these terms- error, defect, fault, failure and bugs are used interchangeably but there is difference between them. Some of these terms are very much different from others.

    Error

    An error is a mistake made by human that leads to discrepancy between the actual and the expected result.

    Defect

    A defect is a problem in the functioning of a software system during testing. ISTQB defines a defect as “A flaw in a component or system that can cause the component or system to fail to perform its required function, e.g., an incorrect statement or data definition.”

    Fault

    A fault is an incorrect step, process or data definition in a software product.

    Bug

    A bug is a flaw in a software system that causes the system to behave in an unintended manner.

    Failure

    A failure is the inability of a software system to perform its operations within the specified performance benchmark. As per ISTQB, “a defect, if encountered during execution, may cause a failure of the component or system”.

    So, we can say that a mistake made by humans during coding is called error, an error found during the testing phase is called a defect, a defect to be resolved by the development team is called a bug and when a build does not meet its specifications then it is termed as failure.

    More Difference Between

    Manual vs Automation Testing Smoke vs Sanity Testing
    White-box vs Black-box Testing System vs Integration Testing
    Verification vs Validation Quality Assurance vs Quality Control
    SDLC vs STLC Test Plan vs Test Strategy
    Test Case vs Test Scenario Agile vs Waterfall Model
    Agile vs Scrum Methodology REST vs SOAP Web Service
    Web Application vs Desktop Application Web Service vs Website
    Assert vs Verify Error, Defect, Fault, Failure & Bug

    Kuldeep Rana

    Kuldeep is the founder and lead author of ArtOfTesting. He is skilled in test automation, performance testing, big data, and CI-CD. He brings his decade of experience to his current role where he is dedicated to educating the QA professionals. You can connect with him on LinkedIn.

    Понравилась статья? Поделить с друзьями:
  • Buffer overrun detected ошибка
  • Buffer overrun detected как исправить call of duty
  • Buffer i o error on dev sr0 logical block 0 async page read
  • Buffer i o error on dev sda logical block 0 async page read
  • Buffer full error