About

Careers

Team

<h3>Manual Testing Method</h3> 1.Manual Testing is a type of Software Testing where Testers manually execute test cases without using any automation tools. Manual Testing is the most primitive of all testing types and helps find bugs in the software system.2.Any new application must be manually tested before its testing can be automated. Manual Testing requires more effort but is necessary to check automation feasibility.3.Manual Testing does not require knowledge of any testing tool. <h3 style="text-align: justify;">Goals of Manual Testing</h3> 1.The key concept of manual testing is to ensure that the application is error free and it is working in conformance to the specified functional requirements.2.Test Suites or cases, are designed during the testing phase and should have 100% test coverage.3.It also makes sure that reported defects are fixed by developers and re-testing has been performed by testers on the fixed defects.4.Basically, this testing checks the quality of the system and delivers bug-free product to the customer. <blockquote style="text-align: justify;">Useful Links: <a href="https://www.guru99.com/manual-testing.html" target="_blank" style="font-size: 14px;">Manual testing article/eng</a> <a href="https://www.softwaretestinghelp.com/manual-testing-tutorial-1/" target="_blank" style="font-size: 14px;">Manual testing article/eng</a> <a href="https://www.youtube.com/watch?v=AjkYTJklAa8" target="_blank" style="font-size: 14px;">Manual testing video tutorial/eng</a> <a href="https://www.youtube.com/watch?v=1lHCM2Br2eA" target="_blank" style="font-size: 14px;">Manual testing video tutorial/ru</a> </blockquote>

Manual Testing

<h3>What is QE?</h3> Quality Engineering consists of analysis methods and the development of systems to ensure products or services are designed, developed and manufactured to meet or exceed the customer’s requirements and expectations. Quality Engineering encompasses all activities related to the analysis of a product’s design, development and manufacturing processes for the purpose of improving the quality of the product and the production process while identifying and reducing waste in its many forms. Quality Engineering methods and tools are often developed and implemented using a cross-functional approach involving multiple business and engineering disciplines. Quality Engineering encompasses a broad range of methodologies and tools including but not limited to the following list:<ul><li style="text-align: justify;">Creation, implementation and management of the Quality Management System (QMS)</li><li style="text-align: justify;">Application of Advanced Product Quality Planning (APQP) tools, such as Quality Function Deployment (QFD) and Failure Mode and Effects Analysis (FMEA), from the initial design concept to the manufacturing and monitoring of the finished product</li><li style="text-align: justify;">Integration of the VOC into new product designs and processes</li><li style="text-align: justify;">Working with internal and external suppliers to ensure materials, components and assemblies meet the design and quality requirements</li><li style="text-align: justify;">Identification and elimination of waste in manufacturing and business processes</li><li style="text-align: justify;">Implementation and monitoring of process controls such as Statistical Process Control (SPC)</li><li style="text-align: justify;">Development of appropriate tests and inspections to ensure that process controls are effective</li><li style="text-align: justify;">Working with customers to resolve any quality issues through application of Root Cause Analysis (RCA) and Problem-Solving tools such as 5 Why, 8D, Cause and Effect / Ishikawa diagrams etc., and implementing effective countermeasures to prevent the issue from re-occurring Quality Engineers are the front-line forces for developing, implementing and maintaining the various quality disciplines within the world of Quality Engineering. They are professionals who have gained a thorough understanding of quality principles and product and process evaluation and control. Quality Engineers are normally responsible for developing, implementing and maintaining the systems used to measure, monitor and control product and process quality in the production process. They work with design teams and manufacturing teams to institute quality standards for products and their associated production processes. Quality Engineers must understand process capability and the use of SPC in monitoring the manufacturing processes. In addition, they often define the parameters and develop appropriate end of line testing including setting acceptable limits for the results. Furthermore, the Quality Engineer must be well versed in the use and application of problem-solving tools, troubleshooting, and process improvement. A Quality Engineer must be able to discover and understand the process issues and develop effective countermeasures including process or product changes when necessary, to ensure that quality standards are upheld and the customer’s requirements and expectations are met or exceeded. The benefits of Quality Engineering are vast and can have a profound effect on product quality, process efficiency, and overall customer satisfaction. If you would like additional information about how Quality Engineering methods and tools can positively impact your organization, please contact one of our professional staff at Quality-One.</li></ul> <h3>What is Software Testing?</h3> Software Testing is a process of verifying a computer system/program to decide whether it meets the specified requirements and produces the desired results. As a result, you identify bugs in software product/project. Software Testing is indispensable to provide a quality product without any bug or issue. <h3>What is Quality Assurance?</h3> Quality assurance can be defined as "part of quality management focused on providing confidence that quality requirements will be fulfilled." The confidence provided by quality assurance is twofold—internally to management and externally to customers, government agencies, regulators, certifiers, and third parties. An alternate definition is "all the planned and systematic activities implemented within the quality system that can be demonstrated to provide confidence that a product or service will fulfill requirements for quality." <h3>Quality Assurance Stages:</h3> <ol><li style="line-height: 1.5; text-align: justify;">Check product requirements</li><li style="line-height: 1.5; text-align: justify;">Risk assessment</li><li style="line-height: 1.5; text-align: justify;">Planning product quality improvement ideas</li><li style="line-height: 1.5; text-align: justify;">Test scheduling</li><li style="line-height: 1.5; text-align: justify;">Analysis of test results </li></ol> <h3 style="text-align: justify; line-height: 1.5;">Quality Assurance VS Quality Control </h3> Quality assurance and quality control are two aspects of quality management. While some quality assurance and quality control activities are interrelated, the two are defined differently. Typically, QA activities and responsibilities cover virtually all of the quality system in one fashion or another, while QC is a subset of the QA activities. Also, elements in the quality system might not be specifically covered by QA/QC activities and responsibilities but may involve QA and QC. <blockquote>Useful Links: <a href="https://www.youtube.com/watch?v=goaZTAzsLMk" target="_blank">Software Testing/video tutorial/eng</a>&nbsp; <a href="https://www.youtube.com/watch?v=FS_TuKTsYOg" target="_blank">QA Engineering/video tutorial/arm</a> <a href="https://www.guru99.com/all-about-quality-assurance.html" target="_blank">Quality Assurance/article/en</a></blockquote>

What is Quality Assurance and why do we need it?

Quality Assurance

<h3>What is Software Testing?</h3> Software Testing is a method to check whether the actual software product matches expected requirements and to ensure that software product is Defect free. It involves execution of software/system components using manual or automated tools to evaluate one or more properties of interest. The purpose of software testing is to identify errors, gaps or missing requirements in contrast to actual requirements. <h3>Why is Software Testing important?</h3> Software Testing is Important because if there are any bugs or errors in the software, it can be identified early and can be solved before delivery of the software product. Properly tested software product ensures reliability, security and high performance which further results in time saving, cost effectiveness and customer satisfaction. Testing is important because software bugs could be expensive or even dangerous. Software bugs can potentially cause monetary and human loss, and history is full of such examples. <ul><li style="text-align: justify;">In April 2015, Bloomberg terminal in London crashed due to software glitch affected more than 300,000 traders on financial markets. It forced the government to postpone a 3bn pound debt sale.</li><li style="text-align: justify;">Nissan cars recalled over 1 million cars from the market due to software failure in the airbag sensory detectors. There has been reported two accident due to this software failure.</li><li style="text-align: justify;">Starbucks was forced to close about 60 percent of stores in the U.S and Canada due to software failure in its POS system. At one point, the store served coffee for free as they were unable to process the transaction.</li><li style="text-align: justify;">Some of Amazon's third-party retailers saw their product price is reduced to 1p due to a software glitch. They were left with heavy losses.</li><li style="text-align: justify;">Vulnerability in Windows 10. This bug enables users to escape from security sandboxes through a flaw in the win32k system.</li><li style="text-align: justify;">In 2015 fighter plane F-35 fell victim to a software bug, making it unable to detect targets correctly.</li><li style="text-align: justify;">China Airlines Airbus A300 crashed due to a software bug on April 26, 1994, killing 264 innocents live</li><li style="text-align: justify;">In 1985, Canada's Therac-25 radiation therapy machine malfunctioned due to software bug and delivered lethal radiation doses to patients, leaving 3 people dead and critically injuring 3 others.</li><li style="text-align: justify;">In April of 1999, a software bug caused the failure of a $1.2 billion military satellite launch, the costliest accident in history</li><li style="text-align: justify;">In May of 1996, a software bug caused the bank accounts of 823 customers of a major U.S. bank to be credited with 920 million US dollars.</li></ul> <h3>Methods of Software Testing</h3> Positive Testing - In this type of testing, by entering valid data, it is checked whether the application works as expected or not. For example: There is a text box that accepts only numbers up to 99999, all other values are not accepted. Testing will be Positive when we take as input values 0-99999 numbers and check whether the system accepts these values or not. Negative Testing - In this type of testing, by entering invalid data, it is checked whether the application is doing something that is not allowed. For example: In the text box of the previous example, let's take A-Z, a-z as input values symbols, the application should either not accept or give an error message. <h3 style="text-align: left;">Positive and Negative&nbsp;testing implementation techniques</h3> Boundary Value Analysis – In this case, only boundary values are checked. Moreover, if the entered data is within the boundary values, it is Positive Testing, and if it is outside, it is Negative Testing. For example: Text box accepts only values 0-10, all other numbers are invalid. The edge values -1, 0, 1 and 9, 10, 11 will be checked. Equivalence Partitioning – In this case, the input data is divided into parts. Each part must be checked at least once. valid values are used for Positive Testing, invalid values for Negative Testing. For the previous example, we divide the input data into 2 (or 3) parts, for example -10 to 0 and 0 to 10. To check, we take 5 (Positive Testing), -5 (Negative Testing). Useful Links: <blockquote style="text-align: justify;"><a href="https://www.youtube.com/watch?v=goaZTAzsLMk" target="_blank" style="font-size: 16px;">Software testing /video tutorial/eng</a> <a href="https://www.youtube.com/watch?v=Xx1lRYj_NsY&amp;list=PLRs8EELOYKc7DYIQixlV1s4EH5SR3TdNB" target="_blank" style="font-size: 16px;">Software testing /video tutorial/rus</a> <a href="https://www.guru99.com/software-testing.html" target="_blank" style="font-size: 16px;">Software testing /article/eng</a> <a href="https://www.guru99.com/software-testing-introduction-importance.html" target="_blank" style="font-size: 16px;">Software testing /article/en</a> </blockquote>

What is Software Testing and why is Software Testing important?

Software Testing

<h3>7 Principles of Software Testing</h3> <ol><li>Testing shows presence of defects</li><li>Exhaustive testing is not possible</li><li>Early testing</li><li>Defect clustering</li><li>Pesticide paradox</li><li>Testing is context dependent</li><li>Absence of errors fallacy</li></ol> <h3>Testing shows presence of defects </h3> Hence, the testing principle states that - Testing talks about the presence of defects and doesn’t talk about the absence of defects. i.e. Software Testing reduces the probability of undiscovered defects remaining in the software but even if no defects are found, it is not proof of correctness.But what if, you work extra hard, taking all precautions &amp; make your software product 99% bug-free. And the software does not meet the needs &amp; requirements of the clients.This leads us to our next principle, which states that- Absence of Error. <h3>Exhaustive testing is not possible </h3> Yes! Exhaustive testing is not possible. Instead, we need the optimal amount of testing based on the risk assessment of the application. <h3>Early Testing </h3> Early Testing - Testing should start as early as possible in the Software Development Life Cycle. So that any defects in the requirements or design phase are captured in the early stages. It is much cheaper to fix a Defect in the early stages of testing. But how early one should start testing? It is recommended that you start finding the bug the moment the requirements are defined. More on this principle in a later training tutorial. <h3>Defect clustering </h3> Defect Clustering which states that a small number of modules contain most of the defects detected. This is the application of the Pareto Principle to software testing: approximately 80% of the problems are found in 20% of the modules. <h3>Pesticide Paradox </h3> Repetitive use of the same pesticide mix to eradicate insects during farming will over time lead to the insects developing resistance to the pesticide Thereby ineffective of pesticides on insects. The same applies to software testing. If the same set of repetitive tests are conducted, the method will be useless for discovering new defects.To overcome this, the test cases need to be regularly reviewed &amp; revised, adding new &amp; different test cases to help find more defects.Testers cannot simply depend on existing test techniques. He must look out continually to improve the existing methods to make testing more effective. But even after all this sweat &amp; hard work in testing, you can never claim your product is bug-free. To drive home this point, let's see this video of the public launch of Windows 98You think a company like MICROSOFT would not have tested their OS thoroughly &amp; would risk their reputation just to see their OS crashing during its public launch! <h3>Testing is context-dependent</h3> Testing is context-dependent which basically means that the way you test an e-commerce site will be different from the way you test a commercial off-the-shelf application. All the developed software’s are not identical. You might use a different approach, methodologies, techniques, and types of testing depending upon the application type. For instance testing, any POS system at a retail store will be different than testing an ATM machine. <h3>Absence of Error - fallacy </h3> It is possible that software which is 99% bug-free is still unusable. This can be the case if the system is tested thoroughly for the wrong requirement. Software testing is not merely finding defects, but also checking that software addresses the business needs. The absence of Error is a Fallacy i.e. Finding and fixing defects does not help if the system build is unusable and does not fulfill the user's needs &amp; requirements. Useful links: <a href="https://www.youtube.com/watch?v=rFaWOw8bIMM" target="_blank">7 Principles of Software Testing /video tutorial/eng</a> <a href="https://www.youtube.com/watch?v=XDiVs2-Ggz4" target="_blank">Software Testing Principles /video tutorial/rus</a> <a href="https://www.youtube.com/watch?v=YvbcTFlJMhc" target="_blank">Software Testing Principles /video tutorial/rus</a> <a href="https://www.guru99.com/software-testing-seven-principles.html" target="_blank">7 Principles of Software Testing /article/eng</a> <a href="https://www.softwaretestingmaterial.com/principles-of-software-testing-2/" target="_blank">7 Principles of Software Testing /article/eng</a>

7 Principles of Software Testing - one by one.

7 Principles of Software Testing

<h3>What is SDLC?</h3> SDLC is Software Development Life Cycle. It is the sequence of activities carried out by Developers to design and develop high-quality software. Requirement collection and analysis The requirement is the first stage in the SDLC process. It is conducted by the senior team members with inputs from all the stakeholders and domain experts in the industry. Planning for the quality assurance requirements and recognization of the risks involved is also done at this stage. This stage gives a clearer picture of the scope of the entire project and the anticipated issues, opportunities, and directives which triggered the project. Requirements Gathering stage need teams to get detailed and precise requirements. This helps companies to finalize the necessary timeline to finish the work of that system. Feasibility study Once the requirement analysis phase is completed the next SDLC step is to define and document software needs. This process conducted with the help of 'Software Requirement Specification' document also known as 'SRS' document. It includes everything which should be designed and developed during the project life cycle. There are mainly five types of feasibilities checks: Economic: Can we complete the project within the budget or not? Legal: Can we handle this project as cyber law and other regulatory compliances. Operation feasibility: Can we create operations which is expected by the client? Technical: Need to check whether the current computer system can support the software Schedule: Decide that the project can be completed within the given schedule or not. Design In this third phase, the system and software design documents are prepared as per the requirement specification document. This helps define overall system architecture. This design phase serves as input for the next phase of the model. There are two kinds of design documents developed in this phase: High-Level Design (HLD) <ul><li>Brief description and name of each module</li><li>An outline about the functionality of every module</li><li>Interface relationship and dependencies between modules</li><li>Database tables identified along with their key elements</li><li>Complete architecture diagrams along with technology details </li></ul> Low-Level Design(LLD) <ul><li>Functional logic of the modules</li><li>Database tables, which include type and size</li><li>Complete detail of the interface</li><li>Addresses all types of dependency issues</li><li>Listing of error messages</li><li>Complete input and outputs for every module </li></ul> Coding Once the system design phase is over, the next phase is coding. In this phase, developers start to build the entire system by writing code using the chosen programming language. In the coding phase, tasks are divided into units or modules and assigned to the various developers. It is the longest phase of the Software Development Life Cycle process. In this phase, the Developer needs to follow certain predefined coding guidelines. They also need to use programming tools like compilers, interpreters, debuggers to generate and implement the code. Testing Once the software is complete, and it is deployed in the testing environment. The testing team starts testing the functionality of the entire system. This is done to verify that the entire application works according to the customer's requirements. During this phase, QA and testing team may find some bugs/defects which they communicate to developers. The development team fixes the bug and sends it back to QA for a re-test. This process continues until the software is bug-free, stable, and working according to the business needs of that system. Installation/Deployment Once the software testing phase is over and no bugs or errors are left in the system then the final deployment process starts. Based on the feedback given by the project manager, the final software is released and checked for deployment issues if any. Maintenance Once the system is deployed, and customers start using the developed system, the following 3 activities occur:<ul><li>Bug fixing - bugs are reported because of some scenarios which are not tested at all</li><li>Upgrade - Upgrading the application to the newer versions of the Software</li><li>Enhancement - Adding some new features into the existing software</li></ul> The main focus of this SDLC phase is to ensure that needs continue to be met and that the system continues to perform as per the specification mentioned in the first phase. <h3>Waterfall model in SDLC</h3> The waterfall is a widely accepted SDLC model. In this approach, the whole process of the software development is divided into various phases of SDLC. In this SDLC model, the outcome of one phase acts as the input for the next phase. This SDLC model is documentation-intensive, with earlier phases documenting what need be performed in the subsequent phases. <h3>V-Model in SDLC</h3> In this type of SDLC model testing and development, the phase is planned in parallel. So, there are verification phases of SDLC on one side and the validation phase on the other side. V-Model joins by Coding phase. <blockquote>Useful Links: <a href="https://www.youtube.com/watch?v=i-QyW8D3ei0" target="_blank" style="font-size: 16px;">SDLC /video tutorial/eng</a> <a href="https://www.youtube.com/watch?v=_dr5zodeFQo" target="_blank" style="font-size: 16px;">SDLC /video tutorial/rus</a> <a href="https://www.guru99.com/software-development-life-cycle-tutorial.html" target="_blank" style="font-size: 16px;">SDLC /article/eng</a> <a href="https://habr.com/ru/company/dcmiran/blog/521718/" target="_blank" style="font-size: 16px;">SDLC /article/rus/</a></blockquote>

SDLC

<h3>What is Software Testing Life Cycle?</h3> Software Testing Life Cycle (STLC) is a sequence of specific activities conducted during the testing process to ensure software quality goals are met. STLC involves both verification and validation activities. Contrary to popular belief, Software Testing is not just a single/isolate activity, i.e. testing. It consists of a series of activities carried out methodologically to help certify your software product. STLC stands for Software Testing Life Cycle. There are following six major phases in every Software Testing Life Cycle Model (STLC Model): <ol><li style="text-align: justify;">Requirement Analysis</li><li style="text-align: justify;">Test Planning</li><li style="text-align: justify;">Test case development</li><li style="text-align: justify;">Test Environment setup</li><li style="text-align: justify;">Test Execution</li><li style="text-align: justify;">Test Cycle closure</li></ol> <h3>Requirement Collection and analysis</h3> Requirement Phase Testing also known as Requirement Analysis in which test team studies the requirements from a testing point of view to identify testable requirements and the QA team may interact with various stakeholders to understand requirements in detail. Requirements could be either functional or non-functional. Automation feasibility for the testing project is also done in this stage. Activities in Requirement Phase Testing <ul><li style="text-align: justify;">Identify types of tests to be performed. </li><li style="text-align: justify;">Gather details about testing priorities and focus.</li><li style="text-align: justify;">Prepare Requirement Traceability Matrix (RTM).</li><li style="text-align: justify;">Identify test environment details where testing is supposed to be carried out.</li><li style="text-align: justify;">Automation feasibility analysis (if required).</li></ul> Deliverables of Requirement Phase Testing <ul><li style="text-align: justify;">RTM</li></ul><ul><li style="text-align: justify;">Automation feasibility report. (if applicable)</li></ul> <h3>Test Planning</h3> Test Planning in STLC is a phase in which a Senior QA manager determines the test plan strategy along with efforts and cost estimates for the project. Moreover, the resources, test environment, test limitations and the testing schedule are also determined. The Test Plan gets prepared and finalized in the same phase. Test Planning Activities<ul><li style="text-align: justify;">Preparation of test plan/strategy document for various types of testing</li><li style="text-align: justify;">Test tool selection</li><li style="text-align: justify;">Test effort estimation</li><li style="text-align: justify;">Resource planning and determining roles and responsibilities.</li><li style="text-align: justify;">Training requirement </li></ul> Deliverables of Test Planning<ul><li style="text-align: justify;">Test plan /strategy document.</li><li style="text-align: justify;">Effort estimation document.</li></ul> <h3>Test Case Development</h3> The Test Case Development Phase involves the creation, verification and rework of test cases &amp; test scripts after the test plan is ready. Initially, the Test data is identified then created and reviewed and then reworked based on the preconditions. Then the QA team starts the development process of test cases for individual units. Test Case Development Activities<ul><li style="text-align: justify;">Create test cases, automation scripts (if applicable)</li><li style="text-align: justify;">Review and baseline test cases and scripts</li><li style="text-align: justify;">Create test data (If Test Environment is available)</li></ul> Deliverables of Test Case Development<ul><li style="text-align: justify;">Test cases/scripts</li></ul>Test data <h3>Test Environment Setup</h3> Test Environment Setup decides the software and hardware conditions under which a work product is tested. It is one of the critical aspects of the testing process and can be done in parallel with the Test Case Development Phase. Test team may not be involved in this activity if the development team provides the test environment. The test team is required to do a readiness check (smoke testing) of the given environment. Test Environment Setup Activities<ul><li style="text-align: justify;">Understand the required architecture, environment set-up and prepare hardware and software requirement list for the Test Environment.</li><li style="text-align: justify;">Setup test Environment and test data</li><li style="text-align: justify;">Perform smoke test on the build</li></ul> Deliverables of Test Environment Setup<ul><li style="text-align: justify;">Environment ready with test data set up</li><li style="text-align: justify;">Smoke Test Results.</li></ul> <h3>Test Cycle Closure</h3> Test Cycle Closure Activities<ul><li style="text-align: justify;">Evaluate cycle completion criteria based on Time, Test coverage, Cost,Software, Critical Business Objectives, Quality</li><li style="text-align: justify;">Prepare test metrics based on the above parameters.</li><li style="text-align: justify;">Document the learning out of the project</li><li style="text-align: justify;">Prepare Test closure report</li><li style="text-align: justify;">Qualitative and quantitative reporting of quality of the work product to the customer.</li><li style="text-align: justify;">Test result analysis to find out the defect distribution by type and severity.</li></ul> Deliverables of Test Cycle Closure<ul><li style="text-align: justify;">Test Closure report</li><li style="text-align: justify;">Test metrics </li></ul> <blockquote style="text-align: justify;">Useful Links: <a href="https://www.youtube.com/watch?v=_3OhZrad8RM" target="_blank">STLC /video tutorial/eng</a> <a href="https://www.youtube.com/watch?v=HylDB3bN6hQ" target="_blank">STLC /video tutorial/eng</a> <a href="https://www.youtube.com/watch?v=An7HC1LolDM" target="_blank">SDLC vs STLC /video tutorial/eng</a> <a href="https://www.youtube.com/watch?v=ZoOX8Q92zqc" target="_blank">STLC /video tutorial/rus</a> <a href="https://www.guru99.com/software-testing-life-cycle.html" target="_blank">STLC /article/eng</a> <a href="https://ru.education-wiki.com/5141467-sdlc-vs-stlc" target="_blank">SDLC vs STLC /article/rus</a></blockquote>

STLC

<h3>Verification</h3> Verification in Software Testing is a process of checking documents, design, code, and program in order to check if the software has been built according to the requirements or not. The main goal of verification process is to ensure quality of software application, design, architecture etc. The verification process involves activities like reviews, walk-throughs and inspection. <h3>Validation</h3> Validation in Software Testing is a dynamic mechanism of testing and validating if the software product actually meets the exact needs of the customer or not. The process helps to ensure that the software fulfills the desired use in an appropriate environment. The validation process involves activities like unit testing, integration testing, system testing and user acceptance testing. <h3>Verification VS Validation</h3> <table style="border-collapse: collapse; width: 98.392%; height: 172px; margin-left: 0.552764%; text-align: justify;"><tbody>
<tr>
o<td style="width: 50%;">Verification </td>
o<td style="width: 50%;">Validation</td></tr>
<tr>
o<td style="width: 50%; vertical-align: middle;">The verifying process includes checking documents, design, code, and program </td>
o<td style="width: 50%; vertical-align: middle;">It is a dynamic mechanism of testing and validating the actual product </td></tr>
<tr>
o<td style="width: 50%; vertical-align: middle;">It does not involve executing the code </td>
o<td style="width: 50%; vertical-align: middle;">It always involves executing the code </td></tr>
<tr>
o<td style="width: 50%; vertical-align: middle;">Verification uses methods like։ reviews, walkthroughs, inspections, and desk- checking etc. </td>
o<td style="width: 50%; vertical-align: middle;">It uses methods like Black Box Testing, White Box Testing, and non-functional testing </td></tr>
<tr>
o<td style="width: 50%; vertical-align: middle;">Whether the software conforms to specification is checked </td>
o<td style="width: 50%; vertical-align: middle;">It checks whether the software meets the requirements and expectations of a customer </td></tr>
<tr>
o<td style="width: 50%; vertical-align: middle;">It finds bugs early in the development cycle </td>
o<td style="width: 50%; vertical-align: middle;">It can find bugs that the verification process can not catch </td></tr>
<tr>
o<td style="width: 50%; vertical-align: middle;">Target is application and software architecture, specification, complete design, high level, and database design, etc. </td>
o<td style="width: 50%; vertical-align: middle;">Target is an actual product </td></tr>
<tr>
o<td style="width: 50%; vertical-align: middle;">QA team does verification and make sure that the software is as per the requirement in the SRS document. </td>
o<td style="width: 50%; vertical-align: middle;">With the involvement of the testing team validation is executed on software code. </td></tr>
<tr>
o<td style="width: 50%; vertical-align: middle;">It comes before validation </td>
o<td style="width: 50%; vertical-align: middle;">It comes after verification </td></tr></tbody></table> <blockquote style="text-align: justify;">Useful Links: <a href="https://www.guru99.com/verification-v-s-validation-in-a-software-testing.html" target="_blank">Validation vs Verification /article/eng</a> <a href="https://smartbear.com/blog/verification-and-validation-the-difference/" target="_blank">Difference Between Verification and Validation /article/eng</a> <a href="https://testmatick.com/ru/validatsiya-i-verifikatsiya-ponyatiya-shodstva-i-otlichiya/" target="_blank">Validation vs Verification /article/rus</a> <a href="https://www.youtube.com/watch?v=qxitgylm1EU" target="_blank">Validation vs Verification /video tutorial/eng</a></blockquote>

Differences between Verification and Validation.

Verification and Validation

<h3>Testing levels</h3> There are mainly four Levels of Testing in software testing <ul><li style="text-align: justify;">Unit Testing: checks if software components are fulfilling functionalities or not.</li><li style="text-align: justify;">Integration Testing: checks the data flow from one module to other modules.</li><li style="text-align: justify;">System Testing: evaluates both functional and non-functional needs for the testing.</li><li style="text-align: justify;">Acceptance Testing: checks the requirements of a specification or contract are met as per its delivery.</li><li style="text-align: justify;">Each of these testing levels has a specific purpose. These testing level provide value to the software development lifecycle.</li></ul> <h3>Unit testing</h3> A Unit is a smallest testable portion of system or application which can be compiled, liked, loaded, and executed. This kind of testing helps to test each module separately. The aim is to test each part of the software by separating it. It checks that component are fulfilling functionalities or not. This kind of testing is performed by developers. <blockquote style="text-align: justify; line-height: 1;">Useful Links: <a href="https://www.guru99.com/levels-of-testing.html" target="_blank">Levels of testing /article/eng</a> <a href="https://www.guru99.com/unit-testing-guide.html" target="_blank">Unit testing /article/eng</a> <a href="https://logrocon.ru/news/unit_testing" target="_blank">Unit testing /article/rus</a> <a href="https://www.youtube.com/watch?v=lj5nnGa_DIw" target="_blank">Unit testing /video tutorial/eng</a> <a href="https://www.youtube.com/watch?v=0WtTd2fWaTE" target="_blank">Unit testing /video tutorial/arm</a></blockquote>

Levels of testing and Unit Testing overview.

Unit Testing

<h3>Integration Testing</h3> Integration means combining. For Example, in this testing phase, different software modules are combined and tested as a group to make sure that integrated system is ready for system testing. Integrating testing checks the data flow from one module to other modules. This kind of testing is performed by testers. <h3>Big-Bang Testing</h3> Big Bang Testing is an Integration testing approach in which all the components or modules are integrated together at once and then tested as a unit. This combined set of components is considered as an entity while testing. If all of the components in the unit are not completed, the integration process will not execute. Advantages:<ul><li style="text-align: justify;">Convenient for small systems.</li></ul> Disadvantages:<ul><li style="text-align: justify;">Fault Localization is difficult.</li><li style="text-align: justify;">Given the sheer number of interfaces that need to be tested in this approach, some interfaces link to be tested could be missed easily.</li><li style="text-align: justify;">Since the Integration testing can commence only after "all" the modules are designed, the testing team will have less time for execution in the testing phase.</li><li style="text-align: justify;">Since all modules are tested at once, high-risk critical modules are not isolated and tested on priority. Peripheral modules which deal with user interfaces are also not isolated and tested on priority.</li></ul> <h3>Incremental Testing</h3> In the Incremental Testing approach, testing is done by integrating two or more modules that are logically related to each other and then tested for proper functioning of the application. Then the other related modules are integrated incrementally and the process continues until all the logically related modules are integrated and tested successfully. Incremental Approach, in turn, is carried out by two different Methods:<ul><li style="text-align: justify;">Bottom Up</li><li style="text-align: justify;">Top Down</li></ul> Bottom-up Integration TestingBottom-up Integration Testing is a strategy in which the lower-level modules are tested first. These tested modules are then further used to facilitate the testing of higher-level modules. The process continues until all modules at the top level are tested. Once the lower-level modules are tested and integrated, then the next level of modules are formed. Diagrammatic Representation: <span style="font-size:11pt;font-family:Arial,sans-serif;color:#000000;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre;white-space:pre-wrap;"><img src="https://lh6.googleusercontent.com/FW2pLc6r5M-j2oXLDAkr_VAvVxvqU_qeg4BIL9w6gRhBJ6MQpGodSalbX_oAswERuUuQlMaz7FW0obzqbbaUafO7_WVFeyINseNtZcRYn09swEa-jg8omENomGjY1EJdvTuffR0GqML1iZuLhd7wrhI" width="621" height="246" style="margin-left:0px;margin-top:0px;"> Advantages:<ul><li style="text-align: justify;">Fault localization is easier.</li><li style="text-align: justify;">No time is wasted waiting for all modules to be developed unlike Big-bang approach</li></ul> Disadvantages:<ul><li style="text-align: justify;">Critical modules (at the top level of software architecture) which control the flow of application are tested last and may be prone to defects.</li><li style="text-align: justify;">An early prototype is not possible</li></ul> Top-down Integration TestingTop-Down Integration Testing is a method in which integration testing takes place from top to bottom following the control flow of the software system. The higher-level modules are tested first and then lower-level modules are tested and integrated in order to check the software functionality. Stubs are used for testing if some modules are not ready. Diagrammatic Representation: <span style="font-size:9pt;font-family:Arial,sans-serif;color:#c5c700;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre;white-space:pre-wrap;"><img src="https://lh5.googleusercontent.com/4ItJApFCmtDHWw2VadD6pU-yUyLT4F4JXmA1ga_WJ8q23woqoLVVofCF-e2qvziICkqDItadocila2YxY5SGhhHNkMzKknWfo-gYog37jntpLiQpRGaNLmpGKPZN__awRtKpFG_O7G0G4FxyA0ij6X8" width="624" height="275" style="margin-left:0px;margin-top:0px;"> Advantages:<ul><li style="text-align: justify;">Fault Localization is easier.</li><li style="text-align: justify;">Possibility to obtain an early prototype.</li><li style="text-align: justify;">Critical Modules are tested on priority; major design flaws could be found and fixed first.</li></ul> Disadvantages:<ul><li style="text-align: justify;">Needs many Stubs.</li><li style="text-align: justify;">Modules at a lower level are tested inadequately</li></ul> <blockquote style="text-align: justify;">Useful Links: <a href="https://www.guru99.com/integration-testing.html" target="_blank" style="font-size: 14px;">Integration testing /article/eng</a> <a href="https://u-tor.com/topic/integration-testing" target="_blank" style="font-size: 14px;">Integration testing /article/eng</a> <a href="https://logrocon.ru/news/intgration_testing" target="_blank" style="font-size: 14px;">Integration testing /article/rus</a> <a href="https://www.youtube.com/watch?v=cQ39AwhjxH8" target="_blank" style="font-size: 14px;">Testing levels /video tutorial/eng</a> <a href="https://www.youtube.com/watch?v=QYCaaNz8emY" target="_blank" style="font-size: 14px;">Integration testing /video tutorial/eng</a></blockquote>

Integration Testing

<h3>System Testing</h3> System testing is software testing performed on a complete, integrated system to verify that the system meets its original requirements, both functional and non-functional. The test object is highlighted in red. By performing system testing, you can detect the following types of defects: Incorrect use of system resources. Unexpected combinations of user data. Environment compatibility problems. Unintended use cases. Inconsistency with functional requirements. Poor usability. System testing is performed using the “Black Box” method, because the set being checked are “external” entities that do not require interaction with the internal structure of the program. It is also recommended to perform it in an environment that is as close as possible to the end user's environment. There are 2 approaches to system testing: Based on requirements. Testing is carried out in accordance with functional or non-functional requirements, for each of which a test case is written. Based on use cases. Testing occurs in accordance with product use cases, on the basis of which user cases are created. For each of these user cases, their own test cases are created. System testing also includes alpha testing and beta testing, the essence of which we will consider in the following articles. <blockquote style="text-align: justify;">Useful Links: <a href="https://www.guru99.com/system-testing.html" target="_blank">System testing /article/eng</a> <a href="https://www.xenonstack.com/insights/what-is-system-testing" target="_blank">System testing /article/eng</a> <a href="https://beqa.pro/blog/testing-levels/" target="_blank">Testing levels /article/rus</a> <a href="https://www.youtube.com/watch?v=t-1Cw2e7PYc" target="_blank">System testing /video tutorial/rus</a></blockquote>

System Testing

<h3>Acceptance Testing</h3> Acceptance is a type of testing carried out at the stage of delivery of the finished product (or finished part of the product) to the customer. The purpose of acceptance testing is to determine the readiness of the product, which is achieved by passing test scenarios and cases that are built on the basis of the specification of requirements for the software being developed. The result of acceptance testing can be: 1.Sending the project for revision. 2.Acceptance by the customer as a completed task. This is the final stage of testing the product before its release. At the same time, it is not extremely thorough, comprehensive and complete - mainly only the main functionality is tested. Acceptance testing is carried out either by the customer himself, or by a group of testers representing the interests of the customer, or by testers of the development company. Depends on the preferences of the customer company. Alpha Testing Alpha Testing is a type of acceptance testing; performed to identify all possible issues and bugs before releasing the final product to the end users. Alpha testing is carried out by the testers who are internal employees of the organization. The main goal is to identify the tasks that a typical user might perform and test them. To put it as simple as possible, this kind of testing is called alpha only because it is done early on, near the end of the development of the software, and before beta testing. The main focus of alpha testing is to simulate real users by using a black box and white box techniques. Benefits of alpha testing: 1.Provides better insight into software reliability at an early stage. 2.Helps simulate user behavior and the environment in real time. 3.Detects many serious errors. 4.Enables early detection of design and functionality errors. Disadvantages of alpha testing: The full functionality cannot be tested as the software is still under development. Sometimes developers and testers are unhappy with the results of alpha testing. Beta Testing Beta testing is the intensive use of an almost finished version of a product in order to identify the maximum number of errors in its operation for their subsequent elimination before the final release of the product to the market, to the mass consumer. Beta testing is a really working version of the program with full functionality. And the task of beta tests is to evaluate the capabilities and stability of the program from the point of view of its future users. Unlike alpha testing, which is carried out by in-house developers or testers, beta testing involves recruiting volunteers from among ordinary future users of the product who have access to the said preliminary version of the product (the so-called beta version). These volunteers (called beta testers) are often driven by curiosity about a new product - a curiosity for the sake of which they are quite willing to put up with the opportunity to experience the consequences of bugs that have not yet been found (and therefore not corrected). In addition to curiosity, motivation can be due to the desire to influence the development process and ultimately obtain a product that more satisfies their needs, and much more. It is very good if these are people who already have experience working with programs of this type, and even better - with a previous version of the same program. Typically, companies already have a certain circle of people with whom they constantly collaborate. Beta testing can be: 1.Closed: The program is tested in a small group of users by invitation. 2.Open: This option allows you to test the application with a larger group and get a lot of feedback. Any user will be able to join the open beta and provide personal feedback. Open beta testing, for example, can be used as part of a product's go-to-market strategy (e.g., giving away beta versions for free to attract widespread consumer attention to the final, expensive version of the product) and to obtain early feedback on the product from a wide range of future users. It must be said that developers have no shortage of people willing to take part in such work. This kind of cooperation benefits both parties, because it is easier to make corrections during the work process, and not after it has already been completed, and besides, comments and suggestions from users allow us to make the software better and of higher quality. Benefits of beta testing: 1.Reduces the risk of product failure through customer validation. 2.Beta testing allows a company to test the infrastructure after launch. 3.Improves product quality through customer feedback. 4.It is an economical method of data collection compared to similar methods. 5.Creates goodwill with customers and increases customer satisfaction. Disadvantages of Beta Testing: 1.Test management is a problem. Compared to other types of testing, which are typically performed in-house in a controlled environment, beta testing is performed in the real world, where the company rarely has control. 2.Finding the right beta users and keeping them engaged can be challenging. <blockquote style="text-align: justify;">Useful Links: <a href="https://www.guru99.com/user-acceptance-testing.html" target="_blank" style="font-size: 14px;">User acceptance testing /article/eng</a> <a href="https://www.istqb.org/certifications/acceptance-tester" target="_blank" style="font-size: 14px;">Acceptance testing /article/eng</a> <a href="https://www.calltouch.ru/blog/glossary/uat-testirovanie/" target="_blank" style="font-size: 14px;">Acceptance testing /article/rus</a> <a href="https://www.youtube.com/watch?v=JDD5EEJgpHU" target="_blank" style="font-size: 14px;">Writing acceptance tests /video tutorial/eng</a> <a href="https://www.youtube.com/watch?v=uhkREQbRl-k" target="_blank" style="font-size: 14px;">Acceptance testing /video tutorial/rus</a> </blockquote>

Acceptance Testing as a final level of testing.

Acceptance Testing

<h3>White Box Testing</h3> White Box Testing is software testing technique in which internal structure, design and coding of software are tested to verify flow of input-output and to improve design, usability and security. In white box testing, code is visible to testers so it is also called Clear box testing, Open box testing, Transparent box testing, Code-based testing and Glass box testing. It is one of two parts of the Box Testing approach to software testing. Its counterpart, Blackbox testing, involves testing from an external or end-user type perspective. On the other hand, White box testing in software engineering is based on the inner workings of an application and revolves around internal testing. The term "WhiteBox" was used because of the see-through box concept. The clear box or WhiteBox name symbolizes the ability to see through the software's outer shell (or "box") into its inner workings. Likewise, the "black box" in "Black Box Testing" symbolizes not being able to see the inner workings of the software so that only the end-user experience can be tested. <blockquote style="text-align: justify;">Useful Links: <a href="https://www.guru99.com/white-box-testing.html" target="_blank">White-box testing article/eng</a> <a href="https://www.mend.io/resources/blog/white-box-testing/" target="_blank">White-box testing article/eng</a> <a href="https://coderlessons.com/tutorials/kachestvo-programmnogo-obespecheniia/ruchnoe-testirovanie/testirovanie-belogo-iashchika" target="_blank">White-box testing article/rus</a> <a href="https://www.youtube.com/watch?v=a-nn_lXf1uA" target="_blank">White-box testing video tutorial/eng</a> <a href="https://www.youtube.com/watch?v=AqoMSfErDSE" target="_blank">White,Black and Gray box testing video tutorial/rus</a></blockquote>

White Box Testing

<h3>Black Box method</h3> Black Box Testing is a software testing method in which the functionalities of software applications are tested without having knowledge of internal code structure, implementation details and internal paths. Black Box Testing mainly focuses on input and output of software applications and it is entirely based on software requirements and specifications. It is also known as Behavioral Testing. <span style="font-size:9pt;font-family:Arial,sans-serif;color:#c5c700;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre;white-space:pre-wrap;"><img src="https://lh5.googleusercontent.com/BF1GkBhK3QsDQYJn0s_ajSvJ13kZxF4xQktFWfy46Vanm_6k_lfvSHU7nApNI6QKX3uQgc6HJG81i1hZKOo3CS9EwfFcx7wpyuh25g9YnLEZkidv9fVdrj-NK28WIp53evMMXQkHRgymiiTRlQVLfWo" width="624" height="152" style="margin-left:0px;margin-top:0px;"> The above Black-Box can be any software system you want to test. For Example, an operating system like Windows, a website like Google, a database like Oracle or even your own custom application. Under Black Box Testing, you can test these applications by just focusing on the inputs and outputs without knowing their internal code implementation. <blockquote style="text-align: justify;">Useful Links: <a href="https://www.guru99.com/black-box-testing.html" target="_blank" style="font-size: 14px;">Black-box testing article/eng</a> <a href="https://www.imperva.com/learn/application-security/black-box-testing/" target="_blank" style="font-size: 14px;">Black-box testing article/eng</a> <a href="https://quality-lab.ru/blog/key-principles-of-black-box-testing/" target="_blank" style="font-size: 14px;">Black-box testing article/rus</a> <a href="https://www.youtube.com/watch?v=O7j3tBXO23M" target="_blank" style="font-size: 14px;">Black-box vs White-box testing video tutorial/eng</a> <a href="https://www.youtube.com/watch?v=joTjpiohrQw" target="_blank" style="font-size: 14px;">Black-box testing video tutorial/rus</a> </blockquote>

Black Box Testing

<h3>Gray Box Testing</h3> Gray Box Testing or Gray box testing is a software testing technique to test a software product or application with partial knowledge of internal structure of the application. The purpose of grey box testing is to search and identify the defects due to improper code structure or improper use of applications. In this process, context-specific errors that are related to web systems are commonly identified. It increases the testing coverage by concentrating on all of the layers of any complex system. Gray Box Testing is a software testing method, which is a combination of both White Box Testing and Black Box Testing method. <ol><li>In White Box testing internal structure (code) is known</li><li>In Black Box testing internal structure (code) is unknown</li><li>In Grey Box Testing internal structure (code) is partially known</li></ol> <span style="font-size:9pt;font-family:Arial,sans-serif;color:#c5c700;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre;white-space:pre-wrap;"><img src="https://lh6.googleusercontent.com/GQqrgFt4THJtgs22YO9VjqpNZgHjCWv6bqNSSOOHGtrO7nZ-L4p_LsRyFLY1UqS64VTm8wEDRttErPdjISjPVOpm-VI8ZzvgnnQLzHXWqcnp8E3Z11QGEG3t0fqDjoymuZh0-40mfjp8B3MqCRQw3RY" width="624" height="217" style="margin-left:0px;margin-top:0px;"> In Software Engineering, Gray Box Testing gives the ability to test both sides of an application, presentation layer as well as the code part. It is primarily useful in Integration Testing and Penetration Testing. Example of Gray Box Testing: While testing websites feature like links or orphan links, if tester encounters any problem with these links, then he can make the changes straightaway in HTML code and can check in real time. <blockquote>Useful Links: <a href="https://www.guru99.com/grey-box-testing.html" target="_blank" style="font-size: 14px;">Gray-box testing article/eng</a> <a href="https://www.mend.io/resources/blog/gray-box-testing/" target="_blank" style="font-size: 14px;">Gray-box testing article/eng</a> <a href="https://ru.education-wiki.com/7781700-gray-box-testing" target="_blank" style="font-size: 14px;">Gray-box testing article/rus</a> <a href="https://www.youtube.com/watch?v=x-tNXvvz_KA" target="_blank" style="font-size: 14px;">Gray-box testing video tutorial/rus</a> <a href="https://www.youtube.com/watch?v=VD5tOODUOzs" target="_blank" style="font-size: 14px;">Gray-box testing video tutorial/eng</a> </blockquote>

Gray Box Testing

<h3>Visual (GUI) Testing</h3> Such visual details as fonts, colors, alignment and images are necessary not just for the convenience of using the site, but also for expressing the characteristic features of the brand, for example, friendliness, reliability or innovation. Many teams first define characteristic features, then designers and shareholders choose appropriate visual details. This approach assumes that the opinion of designers and shareholders will accurately predict the response of users. This is a good move, but there is no guarantee that what seems "friendly" to the designer will be the same for the user. A company can gain a lot from effective branding, so visual aesthetics and its impact on users should be carefully evaluated based on research. <h3 style="text-align: justify;">How to test perception of visual design </h3> As in any other UX research, recruit participants from your target audience. It is not necessary for them to have special knowledge in the field of design — people do not need professional training to understand that they like something. According to a study by Gitte Lindegaard and her colleagues, users need ten seconds to evaluate a design. But if someone likes the design, it doesn't mean that it correctly conveys the characteristics of the brand. Neither you, nor team members, nor management are users of the product. It is not enough to simply ask users whether they like the design or not. A more structured approach is needed, which can be divided into two main parts. <ol><li>Familiarity with a visual stimulus. show participants the research design. This can be a picture, a prototype, a live interactive site or an application. Rating of the user's reaction to this stimulus. Measure reactions to the design using open-ended or strictly controlled questions. </li></ol> <blockquote style="text-align: justify;">Useful Links: <a href="https://www.guru99.com/gui-testing.html" target="_blank" style="font-size: 14px;">GUI testing article/eng</a> <a href="https://www.browserstack.com/guide/visual-testing-beginners-guide" target="_blank" style="font-size: 14px;">Visual testing article/eng</a> <a href="https://www.youtube.com/watch?v=crbwyGlcXm0" target="_blank" style="font-size: 14px;">Visual testing video tutorial/rus</a> </blockquote>

Visual or GUI Testing as a testing method.

Visual Testing

<h3>Ad Hoc Testing</h3> Free testing (ad-hoc testing) is a type of testing that is performed without preparation for testing a product, without defining expected results, or designing test scenarios. This is an informal, improvisational test. It does not require any documentation, planning, processes to be followed while performing testing. This method of testing in most cases produces a larger number of bug reports. This is due to the fact that the tester in the first steps begins testing the main functional part of the product and performs both positive and negative versions of possible scenarios. Most often, such testing is performed when the product owner does not have specific goals, design documentation and previously set tasks. In this case, the tester relies on his general understanding of the product, comparison with similar products, and his own experience. However, when testing ad-hoc, it makes sense to have general information about the product, especially if the project is very complex and large. Therefore, you need a good understanding of the goals of the project, its purpose and the main functions and capabilities. And then you can start ad-hoc testing. Types of free testing (ad-hoc testing): Buddy testing is a process where two people, usually a developer and a tester, work in parallel and find defects in the same module of the product being tested. This type of testing helps the tester to perform the necessary checks and the developer to fix many defects in the early stages. Pair testing is a process where 2 testers test one module and help each other. For example, one can look for defects, and the second can document them. Thus, one tester will have the function of, so to speak, a detector, and the other will have a descriptor function. Monkey testing is arbitrary testing of a product with the goal of breaking the program or causing it to stop as quickly as possible, using various variations of input data (in simple words, to break it). Differences between Buddy testing and Pair testing: Buddy testing is a combination of unit testing and system testing between a developer and a tester. Pair testing - performed only by testers with different levels of knowledge and experience (this combination will help to share views and ideas). The main advantages of ad-hoc testing: there is no need to waste time preparing documentation; the most important defects are often detected in the early stages; often used when hiring a new employee. Using this method, a person learns in 3 days what it would take a week to deal with test cases - this is called forced training for new employees; the ability to find hard-to-reproduce and elusive defects that would be impossible to find using standard test scripts. Example of free testing (Ad-hoc testing): We often use ad-hoc testing in our lives, take, for example, a regular trip to the supermarket. After entering the supermarket, right at the entrance you can find a basket/trolley for groceries, but if it is not in your usual place, this can be considered a bug. When choosing milk, pay attention to the expiration date and if the milk is expired, again it will be a bug. It's the same with other products. And, if in the end, when paying for purchases at the checkout, a bottle of wine that had a price tag of 100 turns out to be priced at 200, this will also be a bug. If we need to do ad-hoc testing of an online store, then this short list can help with what needs to be checked: all site features are available without registration; correct display of animations and pictures; all site features are available after registration; registration process; process of adding/removing from cart; process of payment for purchases; ease of use for beginners, simplicity, tips, help. It is also worth noting that ad-hoc testing is often a favorite type of testing for testers, where they can show all their knowledge and perform the most difficult to predict scenarios, that is, they provide the opportunity for pure improvisation. Ways to increase the efficiency of Ad-hoc testing Preparation. Analyze defects in similar applications, thereby increasing the likelihood of finding similar defects in the application under test. Formation of a draft. This should not be a detailed test plan, but an outline of where to start and what problems to look for. Session testing. Test various product functionality one by one, i.e. not all at once. This helps you focus better and understand the problems. Focus on target areas. First of all, check those areas that are not covered by the test design and test documentation. Use of various auxiliary programs. Some defects can be detected using debuggers, profilers and monitoring. Knowledge of such utilities helps in testing. Record test results. Records of what bugs were found, in which parts of the application there are more of them, etc. This can help both developers and testers of future versions of the application. You can also write down what didn’t work, because... It can be helpful for analysts to see what worked well. Exploratory testing Free testing (ad-hoc testing) is a type of testing that is performed without preparation for testing a product, without defining expected results, or designing test scenarios. This is an informal, improvisational test. It does not require any documentation, planning, processes to be followed while performing testing. This method of testing in most cases produces a larger number of bug reports. This is due to the fact that the tester in the first steps begins testing the main functional part of the product and performs both positive and negative versions of possible scenarios. If each subsequent test that a tester performs is selected based on the results of the previous test, this means that we are using exploratory testing. The main thing to remember about exploratory testing is that it is not a testing technique in itself. Rather, it is an approach that can be applied to any type of testing. Another important point is that exploratory testing is not just about running tests. Testers can use an exploratory approach both when developing new tests at the beginning of an iteration and when reviewing completed tests. Also, exploratory testing should not be performed carelessly, hastily or without preparation. The research approach can require very careful and lengthy preparation for certain tests, and the accumulated knowledge and skills of the tester using this approach over many years is an often invisible but important form of preparation. Exploratory testing can be carried out manually, or can be carried out with extensive use of automation tools, i.e. any auxiliary testing tools. When should exploratory testing be used? The most common cases: when you need to provide quick feedback for a new product or new product functionality; when you need to quickly familiarize yourself with a product; when the main types of testing have already been carried out and time allows for diversifying testing methods; when you need to find a defect localized in a specific module in the shortest possible time; when the work of another testing specialist is checked; when it is necessary to study the state of a specific risk in order to decide whether it is necessary to cover a specific area with tests. <blockquote style="text-align: justify;">Useful Links: <a href="https://www.guru99.com/adhoc-testing.html" target="_blank" style="font-size: 14px;">Ad-hoc testing article/eng</a> <a href="https://coderlessons.com/tutorials/kachestvo-programmnogo-obespecheniia/ruchnoe-testirovanie/spetsialnoe-testirovanie" target="_blank" style="font-size: 14px;">Ad-hoc testing article/rus</a> <a href="https://www.youtube.com/watch?v=Nk_bC9WmuC4" target="_blank" style="font-size: 14px;">Ad-hoc testing video tutorial/eng</a> </blockquote>

Ad Hoc Testing

<h3>Automated Testing Method</h3> Automated testing is the application of software tools to automate a human-driven manual process of reviewing and validating a software product. Most modern software projects now include automated testing from inception. <h3>Selenium Locators</h3> Locator is a command that tells Selenium IDE which GUI elements (say Text Box, Buttons, Check Boxes etc) its needs to operate on. Identification of correct GUI elements is a prerequisite to creating an automation script. But accurate identification of GUI elements is more difficult than it sounds. The choice of locator depends largely on your Application Under Test. In this tutorial, we will toggle between Facebook, new tours.demoaut on the basis of locators that these applications support. Likewise in your Testing project, you will select any of the above-listed element locators in Selenium webdriver, based on your application support. Locating by ID This is the most common way of locating elements since ID's are supposed to be unique for each element. Target Format: id=id of the element Locating by Name Locating elements by name are very similar to locating by ID, except that we use the "name=" prefix instead. Target Format: name=name of the element Locating by Name using Filters Filters can be used when multiple elements have the same name. Filters are additional attributes used to distinguish elements with the same name. Target Format: name=name_of_the_element filter=value_of_filte Locating by Link Text This type of CSS locator in Selenium applies only to hyperlink texts. We access the link by prefixing our target with "link=" and then followed by the hyperlink text. Target Format: link=link_text Locating by CSS Selector CSS Selectors in Selenium are string patterns used to identify an element based on a combination of HTML tag, id, class, and attributes. Locating by CSS Selectors in Selenium is more complicated than the previous methods, but it is the most common locating strategy of advanced Selenium users because it can access even those elements that have no ID or name. CSS Selectors in Selenium have many formats, but we will only focus on the most common ones.<ul><li style="text-align: justify;">Tag and ID</li><li style="text-align: justify;">Tag and class</li><li style="text-align: justify;">Tag and attribute</li><li style="text-align: justify;">Tag, class, and attribute</li><li style="text-align: justify;">Inner text</li></ul> When using this strategy, we always prefix the Target box with "css=" as will be shown in the following examples. Locating by CSS Selector - Tag and IDAgain, we will use Facebook's Email text box in this example. As you can remember, it has an ID of "email," and we have already accessed it in the "Locating by ID" section. This time, we will use a Selenium CSS Selector with ID in accessing that very same element. Locating by CSS Selector - Tag and Class Locating by CSS Selector in Selenium using an HTML tag and a class name is similar to using a tag and ID, but in this case, a dot (.) is used instead of a hash sign. Locating by CSS Selector - Tag and Attribute This strategy uses the HTML tag and a specific attribute of the element to be accessed. Locating by CSS Selector - tag, class, and attribute Locating by CSS Selector - inner textAs you may have noticed, HTML labels are seldom given id, name, or class attributes. So, how do we access them? The answer is through the use of their inner texts. Inner texts are the actual string patterns that the HTML label shows on the page. <h3>API Testing</h3> API (Application Programming Interface) is a computing interface which enables communication and data exchange between two separate software systems. Software system that executes an API includes several functions/subroutines that another software system can perform. API defines requests that can be made, how to make requests, data formats that can be used, etc. between two software systems. API testing is a software testing type that validates Application Programming Interfaces (APIs). The purpose of API Testing is to check the functionality, reliability, performance, and security of the programming interfaces. In API Testing, instead of using standard user inputs(keyboard) and outputs, you use software to send calls to the API, get output, and note down the system's response. API tests are very different from GUI Tests and won't concentrate on the look and feel of an application. It mainly concentrates on the business logic layer of the software architecture. API automation Testing requires an application that can be interacted via an API. In order to test an API, you will need to<ul><li style="text-align: justify;">Use Testing Tool to drive the API</li><li style="text-align: justify;">Write your own code to test the API</li></ul> Test Cases for API TestingTest cases of API testing are based on։ <ul><li style="text-align: justify;">Return value based on input condition: it is relatively easy to test, as input can be defined and results can be authenticated</li><li style="text-align: justify;">Does not return anything: When there is no return value, a behavior of API on the system to be checked</li><li style="text-align: justify;">Trigger some other API/event/interrupt: If an output of an API triggers some event or interrupt, then those events and interrupt listeners should be tracked</li><li style="text-align: justify;">Update data structure: Updating data structure will have some outcome or effect on the system, and that should be authenticated</li><li style="text-align: justify;">Modify certain resources: If API call modifies some resources, then it should be validated by accessing respective resources</li></ul> <h3>Docker</h3> Docker is a software development platform for virtualization with multiple Operating systems running on the same host. It helps to separate infrastructure and applications in order to deliver software quickly. Unlike Hypervisors, which are used for creating VM (Virtual machines), virtualization in Docker is performed on system-level, also called Docker containers. As you can see the difference in the image below, Docker containers run on top of the host's Operation system. This helps you to improves efficiency and security. Moreover, we can run more containers on the same infrastructure than we can run Virtual machines because containers use fewer resources. Why use Docker?<ul><li style="text-align: justify;">Docker is computer software used for Virtualization in order to have multiple Operating systems running on the same host</li><li style="text-align: justify;">Docker is the client-server type of application which means we have clients who relay to the server</li><li style="text-align: justify;">Docker images are the "source code" for our containers; we use them to build</li><li style="text-align: justify;">Dockerfile has two types of registries 1.) public and 2)private registries</li><li style="text-align: justify;">Containers are the organizational units of Docker volume. In simple terms, an image is a template, and a container is a copy of that template. You can have multiple containers (copies) of the same image.</li></ul> Docker ArchitectureNow in this Docker container tutorial, let's talk about Docker main components in the Docker Architecture: <span style="font-size:9pt;font-family:Arial,sans-serif;color:#c5c700;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre;white-space:pre-wrap;"><img src="https://lh5.googleusercontent.com/bKoWtSZ6g6kp95CwVID5868xBqCqyqTVFLbShrGTBHjBcgkikaw68zuZHDMvOgXxIA8lbc4kZ00Gut20Cn9cy4Aqt-A1R0bxEy11-sZpBbxOyrlsMH8cTumosSKlRNW0wZjf5eqxzBYfE2OABk5IVnc" width="624" height="209" style="margin-left:0px;margin-top:0px;"> Docker Engine Docker is the client-server type of application which means we have clients who relay to the server. So the Docker daemon called: dockerd is the Docker engine which represents the server. The docker daemon and the clients can be run on the same or remote host, and they communicate through command line client binary, as well as a full RESTful API to interact with the daemon: dockerd. Docker Images Docker images are the "source code" for our containers; we use them to build containers. They can have software pre-installed which speeds up deployment. They are portable, and we can use existing images or build our own. Docker Registries Docker stores the images we build in registries. There are public and private registries. Docker company has public registry called Docker hub, where you can also store images privately. Docker hub has millions of images, which you can start using now. Docker Containers Containers are the organizational units and one of the Docker basics concept. When we build an image and start running it; we are running in a container. The container analogy is used because of the portability of the software we have running in our container. We can move it, in other words, "ship" the software, modify, manage, create or get rid of it, destroy it, just as cargo ships can do with real containers. In simple terms, an image is a template, and a container is a copy of that template. You can have multiple containers (copies) of the same image. <h3>Jenkins</h3> Jenkins is an open-source Continuous Integration server written in Java for orchestrating a chain of actions to achieve the Continuous Integration process in an automated fashion. Jenkins supports the complete development life cycle of software from building, testing, documenting the software, deploying, and other stages of the software development life cycle. Jenkins is a widely used application around the world that has around 300k installations and growing day by day. By using Jenkins, software companies can accelerate their software development process, as Jenkins can automate build and test at a rapid rate. It is a server-based application and requires a web server like Apache Tomcat. The reason Jenkins software became so popular is that of its monitoring of repeated tasks which arise during the development of a project. For example, if your team is developing a project, Jenkins will continuously test your project builds and show you the errors in early stages of your development. What is Continuous Integration? Continuous Integration is a process of integrating code changes from multiple developers in a single project many times. The software is tested immediately after a code commit. With each code commit, code is built and tested. If the test is passed, the build is tested for deployment. If the deployment is successful, the code is pushed to production. This commit, build, test, and deploy is a continuous process and hence the name continuous integration/deployment. How does Jenkins work? Jenkins is a server-based application and requires a web server like Apache Tomcat to run on various platforms like Windows, Linux, macOS, Unix, etc. To use Jenkins, you need to create pipelines which are a series of steps that a Jenkins server will take. Jenkins Continuous Integration Pipeline is a powerful instrument that consists of a set of tools designed to host, monitor, compile and test code, or code changes, like: <ul><li style="text-align: justify;">Continuous Integration Server (Jenkins, Bamboo, CruiseControl, TeamCity, and others)</li><li style="text-align: justify;">Source Control Tool (e.g., CVS, SVN, GIT, Mercurial, Perforce, ClearCase and others)</li><li style="text-align: justify;">Build tool (Make, ANT, Maven, Ivy, Gradle, and others)</li><li style="text-align: justify;">Automation testing framework (Selenium, Appium, TestComplete, UFT, and others)</li></ul> Jenkin History<ul><li style="text-align: justify;">Kohsuke Kawaguchi, a Java developer, working at SUN Microsystems, was tired of building the code and fixing errors repetitively. In 2004, created an automation server called Hudson that automates build and test task.</li><li style="text-align: justify;">In 2011, Oracle who owned Sun Microsystems had a dispute with Hudson open source community, so they forked Hudson and renamed it as Jenkins.</li><li style="text-align: justify;">Both Hudson and Jenkins continued to operate independently. But in short span of time, Jenkins acquired a lot of projects and contributors while Hudson remained with only 32 projects. With time, Jenkins became more popular, and Hudson is not maintained anymore.</li></ul> <blockquote style="text-align: justify;">Useful Links: <a href="https://www.guru99.com/automation-testing.html" target="_blank" style="font-size: 14px;">Automation testing article/eng</a> <a href="https://www.guru99.com/introduction-to-selenium.html" target="_blank" style="font-size: 14px;">Selenium as an automation testing tool article/eng</a> <a href="https://www.guru99.com/locators-in-selenium-ide.html" target="_blank" style="font-size: 14px;">Selenium locators article/eng</a> <a href="https://www.ibm.com/cloud/learn/docker" target="_blank" style="font-size: 14px;">Docker article/eng</a> <a href="https://www.guru99.com/api-testing.html" target="_blank" style="font-size: 14px;">API testing article/eng</a> <a href="https://www.guru99.com/jenkin-continuous-integration.html" target="_blank" style="font-size: 14px;">Jenkins article/eng</a> <a href="https://www.youtube.com/watch?v=QtZ4yV49RtA" target="_blank" style="font-size: 14px;">Automation testing video tutorial/eng</a> <a href="https://www.youtube.com/watch?v=TH4qot56Uqg" target="_blank" style="font-size: 14px;">Automation testing video tutorial/arm</a> <a href="https://www.youtube.com/watch?v=TNImFcYqb40" target="_blank" style="font-size: 14px;">Automation testing video tutorial/rus</a> <a href="https://www.youtube.com/watch?v=jK_4nnEJVHQ" target="_blank" style="font-size: 14px;">Locators in Selenuim video tutorial/eng</a> <a href="https://www.youtube.com/watch?v=9-iVt0MIqNY" target="_blank" style="font-size: 14px;">Xpath in Selenium video tutorial/eng</a> <a href="https://www.youtube.com/watch?v=89yWXXIOisk" target="_blank" style="font-size: 14px;">Jenkins video tutorial/eng</a> <a href="https://www.youtube.com/watch?v=wi-MGFhrad0&amp;list=PLhW3qG5bs-L99pQsZ74f-LC-tOEsBp2rK" target="_blank" style="font-size: 14px;">Docker video tutorial/eng</a> </blockquote>

Automated Testing

<h3>Manual Testing VS Automation Testing</h3> <table style="border-collapse: collapse; width: 98.9782%; height: 273px;"><tbody>
<tr>
o<td style="width: 50%; text-align: center;">Manual Testing </td>
o<td style="width: 50%; text-align: center;">Automated Testing </td></tr>
<tr>
o<td style="width: 50%;">Manual testing requires human intervention for test execution. </td>
o<td style="width: 50%;">Automation Testing is the use of tools to execute test cases․ </td></tr>
<tr>
o<td style="width: 50%;">Manual testing will require skilled labour, long time &amp; will imply high costs. </td>
o<td style="width: 50%;">Automation Testing saves time, cost, and manpower. Once recorded, it's easier to run an automated test suite․ </td></tr>
<tr>
o<td style="width: 50%;">Any type of application can be tested manually, certain testing types like ad-hoc and monkey testing are more suited for manual execution. </td>
o<td style="width: 50%;">Automated testing is recommended only for stable systems and is mostly used for Regression Testing․ </td></tr>
<tr>
o<td style="width: 50%;">Manual testing can become repetitive and boring. </td>
o<td style="width: 50%;">The boring part of executing same test cases time and again is handled by automation software in Automation Testing. </td></tr></tbody></table> <blockquote>Useful Links: <a href="https://www.guru99.com/difference-automated-vs-manual-testing.html" target="_blank" style="font-size: 14px;">Manual testing vs Automation testing article/eng</a> <a href="https://auriga.ru/" target="_blank" style="font-size: 14px;">Manual testing vs Automation testing article/rus</a> <a href="https://www.youtube.com/watch?v=SEzPFlnI7mY" target="_blank" style="font-size: 14px;">Manual testing vs Automation testing video tutorial/eng</a> </blockquote>

Difference between Manual testing and Automation testing.

Manual Testing VS Automation Testing

<h3>Non Functional Testing</h3> Non-Functional Testing is defined as a type of Software testing to check non-functional aspects (performance, usability, reliability, etc) of a software application. It is designed to test the readiness of a system as per nonfunctional parameters which are never addressed by functional testing. An excellent example of non-functional test would be to check how many people can simultaneously login into a software. Usability Testing 1.Usability testing is a technique used in user-centered interaction design to evaluate a product by testing it on users.2.This can be seen as an irreplaceable usability practice, since it gives direct input on how real users use the system.3.Usability testing generally involves measuring how well test subjects respond in four areas: efficiency, accuracy, recall, and emotional response. Recovery Testing 1.Recovery testing is the activity of testing how well an application is able to recover from crashes, hardware failures and other similar problems.2.E.g. While an application is receiving data from a network, unplug the connecting cable. After some time, plug the cable back in and analyze the application's ability to continue receiving data from the point at which the network connection disappeared. Compatibility Testing 1.Compatibility testing, part of software non-functional tests, is testing conducted on the application to evaluate the application's compatibility with the computing environment.2.Computing environment may contain different OS types (IOS 6, IOS 7), different types of browsers (Chrome, Firefox, IE). Performance Testing 1.Performance testing is generally executed to determine how a system or sub - system performs in terms of responsiveness and stability under a particular workload.2.It can also serve to investigate measure, validate or verify other quality attributes of the system, such as scalability, reliability and resource usage. Performance Testing Metrics 1.The basic parameters monitored during performance testing include:2.Processor Usage - an amount of time processor spends executing non-idle threads.3.Memory use - amount of physical memory available to processes on a computer.4.Disk time - amount of time disk is busy executing a read or write request.5.Bandwidth - shows the bits per second used by a network interface.6.Private bytes - number of bytes a process has allocated that can't be shared amongst other processes. These are used to measure memory leaks and usage.7.Committed memory - amount of virtual memory used.8.Memory pages/second - number of pages written to or read from the disk in order to resolve hard page faults. Hard page faults are when code not from the current working set is called up from elsewhere and retrieved from a disk.9.Page faults/second - the overall rate in which fault pages are processed by the processor. This again occurs when a process requires code from outside its working set.10.CPU interrupts per second - is the avg. number of hardware interrupts a processor is receiving and processing each second.11.Disk queue length - is the avg. no. of read and write requests queued for the selected disk during a sample interval.12.Network output queue length - length of the output packet queue in packets. Anything more than two means a delay and bottlenecking needs to be stopped.13.Network bytes total per second - rate which bytes are sent and received on the interface including framing characters.14.Response time - time from when a user enters a request until the first character of the response is received.15.Throughput - rate a computer or network receives requests per second.16.Amount of connection pooling - the number of user requests that are met by pooled connections. The more requests met by connections in the pool, the better the performance will be.17.Maximum active sessions - the maximum number of sessions that can be active at once.18.Hit ratios - This has to do with the number of SQL statements that are handled by cached data instead of expensive I/O operations. This is a good place to start for solving bottlenecking issues.19.Hits per second - the no. of hits on a web server during each second of a load test.20.Rollback segment - the amount of data that can rollback at any point in time.21.Database locks - locking of tables and databases needs to be monitored and carefully tuned.22.Top waits - are monitored to determine what wait times can be cut down when dealing with the how fast data is retrieved from memory23.Thread counts - An applications health can be measured by the no. of threads that are running and currently active.24.Garbage collection - It has to do with returning unused memory back to the system. Garbage collection needs to be monitored for efficiency Performance Testing Types 1.Load testing - checks the application's ability to perform under anticipated user loads. The objective is to identify performance bottlenecks before the software application goes live.2.Stress testing - involves testing an application under extreme workloads to see how it handles high traffic or data processing. The objective is to identify the breaking point of an application.3.Volume testing - Under Volume Testing large no. of. Data is populated in a database and the overall software system's behavior is monitored. The objective is to check software application's performance under varying database volumes.4.Scalability testing - The objective of scalability testing is to determine the software application's effectiveness in "scaling up" to support an increase in user load. It helps plan capacity addition to your software system.5.Endurance testing - is done to make sure the software can handle the expected load over a long period of time. Security Testing 1.Security testing is a process to determine that an information system protects data and maintains functionality as intended.2.The six basic security concepts that need to be covered by security testing are: 1.Confidentiality2.Integrity3.Authentication4.Availability5.Authorizationnon-repudiation.6.Availability 7.Testing Internationalization and Localization Testing 1.Internationalization and localization are means of adapting computer applications to different languages, regional differences and technical requirements of a target market.2.Internationalization is the process of designing a software application so that it can be adapted to various languages and regions without engineering changes.3.Localization is the process of adapting internationalized software for a specific region or language by adding locale-specific components and translating text. <blockquote style="text-align: justify;">Useful Links: <a href="https://www.guru99.com/non-functional-testing.html" target="_blank" style="font-size: 14px;">Non-functionl testing article/eng</a> <a href="https://diffy.website/blog/functional-vs-non-functional-testing" target="_blank" style="font-size: 14px;">Functional testing vs Non-functional testing article/eng</a> <a href="https://coderlessons.com/tutorials/kachestvo-programmnogo-obespecheniia/ruchnoe-testirovanie/ne-funktsionalnoe-testirovanie" target="_blank" style="font-size: 14px;">Non-functional testing article/rus</a> <a href="https://www.youtube.com/watch?v=j_79AXkG4PY" target="_blank" style="font-size: 14px;">Functional testing vs Non-functional testing video tutorial/eng</a> <a href="https://www.youtube.com/watch?v=0BszE2j8Zug" target="_blank" style="font-size: 14px;">Functional testing vs Non-functional testing video tutorial/rus</a> </blockquote>

Non Functional Testing

<h3>Maintenance Testing</h3> Maintenance Testing is done on the already deployed software. The deployed software needs to be enhanced, changed or migrated to other hardware. The Testing done during this enhancement, change and migration cycle is known as maintenance testing. <blockquote style="text-align: justify;">Useful Links: <a href="https://www.softwaretestingmaterial.com/maintenance-testing/" target="_blank" style="font-size: 14px;">Maintenance testing article/eng</a> <a href="https://www.youtube.com/watch?v=7B69Z35BvD4" target="_blank" style="font-size: 14px;">Maintenance testing video tutorial/eng</a> </blockquote>

Maintenance Testing

<h3>What is Defect?</h3> The variation between the actual results and expected results is known as defect. If a developer finds an issue and corrects it by himself in the development phase then it’s called a defect. <h3>What is Bug?</h3> If testers find any mismatch in the application/system in testing phase then they call it as Bug. As I mentioned earlier, there is a contradiction in the usage of Bug and Defect. People widely say the bug is an informal name for the defect. <h3>What is Error?</h3> We can’t compile or run a program due to coding mistake in a program. If a developer unable to successfully compile or run a program then they call it as an error. <h3>What is Failure?</h3> Once the product is deployed and customers find any issues then they call the product as a failure product. After release, if an end user finds an issue then that particular issue is called as failure. <blockquote style="text-align: justify;">Useful Links: <a href="https://www.360logica.com/blog/difference-between-defect-error-bug-failure-and-fault/" target="_blank">Difference between Defect, Error,Bug, and Failure article/eng</a> <a href="https://www.youtube.com/watch?v=53braDId-RQ" target="_blank">Defect, Error,Bug, and Failure video tutorial/eng</a></blockquote>

What is the difference between Defect, Error, Bug, Failure?

Defect, Error, Bug, Failure

<h3>Bug Life Cycle</h3> Bug/Defect Life Cycle or Bug Life Cycle in software testing is the specific set of states that defect or bug goes through in its entire life. The purpose of Defect life cycle is to easily coordinate and communicate current status of defect which changes to various assignees and make the defect fixing process systematic and efficient. Defect Status Defect Status or Bug Status in defect life cycle is the present state from which the defect or a bug is currently undergoing. The goal of defect status is to precisely convey the current state or progress of a defect or bug in order to better track and understand the actual progress of the defect life cycle. The number of states that a defect goes through varies from project to project. Below lifecycle diagram, covers all possible states: <ol><li style="text-align: justify;">New: When a new defect is logged and posted for the first time. It is assigned a status as NEW.</li><li style="text-align: justify;">Assigned: Once the bug is posted by the tester, the lead of the tester approves the bug and assigns the bug to the developer team</li><li style="text-align: justify;">Open: The developer starts analyzing and works on the defect fix</li><li style="text-align: justify;">Fixed: When a developer makes a necessary code change and verifies the change, he or she can make bug status as "Fixed."</li><li style="text-align: justify;">Pending retest: Once the defect is fixed the developer gives a particular code for retesting the code to the tester. Since the software testing remains pending from the testers end, the status assigned is "pending retest."</li><li style="text-align: justify;">Retest: Tester does the retesting of the code at this stage to check whether the defect is fixed by the developer or not and changes the status to "Re-test."</li><li style="text-align: justify;">Verified: The tester re-tests the bug after it got fixed by the developer. If there is no bug detected in the software, then the bug is fixed and the status assigned is "verified."</li><li style="text-align: justify;">Reopen: If the bug persists even after the developer has fixed the bug, the tester changes the status to "reopened". Once again the bug goes through the life cycle.</li><li style="text-align: justify;">Closed: If the bug is no longer exists then tester assigns the status "Closed."</li><li style="text-align: justify;">Duplicate: If the defect is repeated twice or the defect corresponds to the same concept of the bug, the status is changed to "duplicate."</li><li style="text-align: justify;">Rejected: If the developer feels the defect is not a genuine defect then it changes the defect to "rejected."</li><li style="text-align: justify;">Deferred: If the present bug is not of a prime priority and if it is expected to get fixed in the next release, then status "Deferred" is assigned to such bugs</li><li style="text-align: justify;">Not a bug:If it does not affect the functionality of the application then the status assigned to a bug is "Not a bug"</li></ol> <span style="font-size:9pt;font-family:'Times New Roman',serif;color:#f4ff00;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre;white-space:pre-wrap;"><img src="https://lh4.googleusercontent.com/UgOiYKxjOhr-1mg_t-JlCdb03bEqfEBHV9TlE-_HdfQa65MPMaZihbuoBMaLRB9x7Vk3_f3TZSOPLmdSSNNnAqVOjaCsXuX9f98NL4yzIxR0jxBJ7ToYhDFZ0IYgRn-CHUEGRN8MlXTMmOExyeH1-1g" width="624" height="464" style="margin-left:0px;margin-top:0px;"> <ol><li style="text-align: justify;">Tester finds the defect</li><li style="text-align: justify;">Status assigned to defect- New</li><li style="text-align: justify;">A defect is forwarded to Project Manager for analyze</li><li style="text-align: justify;">Project Manager decides whether a defect is valid</li><li style="text-align: justify;">Here the defect is not valid- a status is given "Rejected."</li><li style="text-align: justify;">So, project manager assigns a status rejected. If the defect is not rejected then the next step is to check whether it is in scope. Suppose we have another function- email functionality for the same application, and you find a problem with that. But it is not a part of the current release when such defects are</li><li style="text-align: justify;">assigned as a postponed or deferred status.</li><li style="text-align: justify;">Next, the manager verifies whether a similar defect was raised earlier. If yes defect is assigned a status duplicate.</li><li style="text-align: justify;">If no the defect is assigned to the developer who starts fixing the code. During this stage, the defect is assigned a status in- progress.</li><li style="text-align: justify;">Once the code is fixed. A defect is assigned a status fixed</li><li style="text-align: justify;">Next, the tester will re-test the code. In case, the Test Case passes the defect is closed. If the test cases fail again, the defect is re-opened and assigned to the developer.</li><li style="text-align: justify;">Consider a situation where during the 1st release of Flight Reservation a defect was found in Fax order that was fixed and assigned a status closed. During the second upgrade release the same defect again re-surfaced. In such cases, a closed defect will be re-opened.</li></ol> <blockquote style="text-align: justify;">Useful Links: <a href="https://www.guru99.com/defect-life-cycle.html" target="_blank" style="font-size: 14px;">Defect/Bug life cycle article/eng</a> <a href="https://www.youtube.com/watch?v=EZGDyFPHFMw" target="_blank" style="font-size: 14px;">Bug life cycle video tutorial/eng</a> <a href="https://www.youtube.com/watch?v=ndwA0ywELvg" target="_blank" style="font-size: 14px;">Bug life cycle video tutorial/rus</a> </blockquote>

Bug Life Cycle

<h3>Defect Severity</h3> Every defect impacts on the system at some level. This impact is measured by the “Severity” parameter. Severity type is categorized by Software Tester based on the Test Case and functional / requirement understanding. It also indicates the seriousness of the issue occurring on the application. Each Defect management tool categories Severity in different way. <h3 style="text-align: justify;">Severity Levels</h3> A defect that completely crashes the system and Tester is no longer able to move further with the testing. In another scenario when whole feature / functionality is missing from the application, this can be considered as a Blocker defect. Almost all the time Blocker severity defects are having highest priority. Critical Severity: A highly severe defect causing the system failure or functionality collapse. But user is able to access some of it’s functions or the same scenario is executable some other way. Almost all the time Critical severity defects are having highest priority. Major Severity: Defect falling under Major severity is generally functionality specific defects. It does not cause any system failure kind of situation. But such defects are equally important and they should be resolved without any unnecessary delay. Minor &amp; Trivial Severity: Defects having small UI issues, spelling mistakes in content, minor alignment issues, color shades are reported as minor or trivial defects. These issues do not affect any of the functionality and keeping they open long time won’t make any difference. <h3>Defect Priority</h3> Priority is defined to set the order in which the reported defects should be resolved. Usually Priority is set by Software Tester or QA Lead and developers focus on higher priority defects first following the descending order. Priority can be categorized in three layers. <h3 style="text-align: justify;">Priority levels</h3> High Priority (P1): Defects falling under P1 category must be resolved and closed as soon as possible. Due to such defects testing of entire application is blocked and Tester can not move any further. Medium Priority (P2): Once all the defects with High priority are resolved, next focus should be on Medium level defects. Normally functional defects such as a feature is not working as it is supposed to be, major cosmetics errors, validation errors are considered as Medium priority defects. Such issues don’t stop you to perform further testing. Low Priority (P3): These defects are taken into consideration once all High &amp; Major priority defects are resolved. Minor UI issues, spelling mistakes, alignment issues, color code mistakes should be considered as Low priority defects. In short, by providing Priority to a Defect we set the order in which all the reported defects to be resolved. <h3 style="text-align: justify;">Examples</h3> SCENARIO 1: HIGH PRIORITY &amp; BLOCKER SEVERITY 1.A very common example, User is not able to Login into application with proper credentials. This is a very critical scenario which needs to be fixed as soon as possible.2.In an E-Commerce website User is not able to add the produce into the Cart / not able to check-out for payment from the cart. If occurred on the live application, this issue can impact on the business at great level.3.After registration, User is not getting the Link to complete the registration process.4.System is crashed when providing invalid keywords (e.g: XSS scripts) in the Search box. SCENARIO 2: LOW PRIORITY &amp; LOW SEVERITY 1.Minor spelling mistakes on the pages like “Site Map”, “Career” or “Company Blog” pages.2.Color of the button on About Us page is slightly different.3.Minor alignment issues in the content of the Company Blogs page. SCENARIO 3: HIGH PRIORITY &amp; LOW SEVERITY 1.A very common example, “Company Logo” is not displayed as expected. This defect is not affecting any functional scenarios but it can impact on the company’s brand value. So, this issue should be fixed without any delay. <blockquote style="text-align: justify;">Useful Links: <a href="https://www.guru99.com/defect-severity-in-software-testing.html" target="_blank" style="font-size: 14px;">Defect severity and priority article/eng</a> <a href="https://www.performance-lab.ru/blog/sereznost" target="_blank" style="font-size: 14px;">Defect severity and priority article/rus</a> <a href="https://www.youtube.com/watch?v=HW_tnUnUav8" target="_blank" style="font-size: 14px;">Defect severity and priority video tutorial/eng</a> <a href="https://www.youtube.com/watch?v=ZyiV9fmUzjk" target="_blank" style="font-size: 14px;">Defect severity and priority video tutorial/rus</a> </blockquote>

How to define the Priority and Severity of the bug?

Defect Severity and Priority

<h3>Defect Report</h3> is a document that identifies and describes a defect detected by a tester. The purpose of a defect report is to state the problem as clearly as possible so that developers can replicate the defect easily and fix it. <h3>Defect Report Template</h3> In most companies, a defect reporting tool is used and the elements of a report can vary. However, in general, a defect report can consist of the following elements. While reporting the bug to developer, your Bug Report should contain the following information <ol><li>Defect_ID - Unique identification number for the defect.</li><li>Defect Description - Detailed description of the Defect including information about the module in which Defect was found.</li><li>Version - Version of the application in which defect was found.</li><li>Steps - Detailed steps along with screenshots with which the developer can reproduce the defects.</li><li>Date Raised - Date when the defect is raised</li><li>Reference - where in you Provide reference to the documents like. requirements, design, architecture or maybe even screenshots of the error to help understand the defect</li><li>Detected By - Name/ID of the tester who raised the defect</li><li>Status - Status of the defect, more on this later</li><li>Fixed by - Name/ID of the developer who fixed it</li><li>Date Closed - Date when the defect is closed</li><li>Severity which describes the impact of the defect on the application</li><li>Priority which is related to defect fixing urgency. Severity Priority could be High/Medium/Low based on the impact urgency at which the defect should be fixed respectively</li></ol> <h3 style="text-align: justify;">Reporting Defects Effectively</h3> Be specific:<ol><li>Specify the exact action: Do not say something like ‘Select ButtonB’. Do you mean ‘Click ButtonB’ or ‘Press ALT+B’ or ‘Focus on ButtonB and click ENTER’? Of course, if the defect can be arrived at by using all the three ways, it’s okay to use a generic term as ‘Select’ but bear in mind that you might just get the fix for the ‘Click ButtonB’ scenario.</li><li>In case of multiple paths, mention the exact path you followed: Do not say something like “If you do ‘A and X’ or ‘B and Y’ or ‘C and Z’, you get D.” Understanding all the paths at once will be difficult. Instead, say “Do ‘A and X’ and you get D.” You can, of course, mention elsewhere in the report that “D can also be got if you do ‘B and Y’ or ‘C and Z’.”</li><li>Do not use vague pronouns: Do not say something like “In ApplicationA, open X, Y, and Z, and then close it.” What does the ‘it’ stand for? ‘Z’ or, ‘Y’, or ‘X’ or ‘ApplicationA’?”</li></ol> Be detailed:1.Provide more information (not less). In other words, do not be lazy. Developers may or may not use all the information you provide but they sure do not want to beg you for any information you have missed. Be objective:<ol><li>Do not make subjective statements like “This is a lousy application” or “You fixed it real bad.”</li><li>Stick to the facts and avoid the emotions.</li><li>Reproduce the defect:</li><li>Do not be impatient and file a defect report as soon as you uncover a defect. Replicate it at least once more to be sure. (If you cannot replicate it again, try recalling the exact test condition and keep trying. However, if you cannot replicate it again after many trials, finally submit the report for further investigation, stating that you are unable to reproduce the defect anymore and providing any evidence of the defect if you had gathered.)</li></ol> Review the report:Do not hit ‘Submit’ as soon as you write the report. Review it at least once. Remove any typos. <blockquote style="text-align: justify;">Useful Links: <a href="https://bugherd.com/blog/bug-reporting/" target="_blank" style="font-size: 14px;">Bug report article/eng</a> <a href="https://www.youtube.com/watch?v=Axm-F0pH8cg" target="_blank" style="font-size: 14px;">Bug report video tutorial/rus</a> <a href="https://www.youtube.com/watch?v=dns4zBqfpEM" target="_blank" style="font-size: 14px;">Bug report video tutorial/eng</a> <a href="https://www.youtube.com/watch?v=g8FJ_Zja9P0" target="_blank" style="font-size: 14px;">Bug, Bug report video tutorial/arm</a> </blockquote>

Defect report is a document identifying a defect detected by a tester.

Defect Report

<h3>Test Case</h3> A TEST CASE is a set of conditions or variables under which a tester will determine whether a system under test satisfies requirements or works correctly. The process of developing test cases can also help find problems in the requirements or design of an application. <table style="border-collapse: collapse; width: 100%; text-align: justify;"><tbody>
<tr>
o<td style="width: 24.3732%;">Test Case Field </td>
o<td style="width: 75.5102%;">Description </td></tr>
<tr>
o<td>&nbsp;Test case ID: <div style="color:rgba(0,0,0,0.01);width:0;height:0">&nbsp; </div></td>
o<td>Each test case should be represented by a unique ID. To indicate test types follow some convention like "TC_UI_1" indicating "User Interface Test Case#1." </td></tr>
<tr>
o<td>&nbsp;Test Priority: <div style="color:rgba(0,0,0,0.01);width:0;height:0">&nbsp; </div></td>
o<td>&nbsp;It is useful while executing the test &nbsp;Low &nbsp;Medium &nbsp;High </td></tr>
<tr>
o<td>&nbsp;Name of the Module: </td>
o<td>&nbsp;Determine the name of the main module or sub-module being tested </td></tr>
<tr>
o<td>&nbsp;Test Designed by: </td>
o<td>&nbsp;Tester's Name </td></tr>
<tr>
o<td>&nbsp;Date of test designed: </td>
o<td>&nbsp;Date when test was designed </td></tr>
<tr>
o<td>&nbsp;Test Executed by: </td>
o<td>&nbsp;Who executed the test- tester </td></tr>
<tr>
o<td>&nbsp;Date of the Test Execution: </td>
o<td>&nbsp;Date when test needs to be executed </td></tr>
<tr>
o<td>&nbsp;Name or Test Title: </td>
o<td>&nbsp;Title of the test case </td></tr>
<tr>
o<td>&nbsp;Description/Summary of Test: </td>
o<td>&nbsp;Determine the summary or test purpose in brief </td></tr><tr>
o<td>&nbsp;Pre-condition: </td>
o<td>&nbsp;Any requirement that needs to be done before execution of this test case. To execute this test case list all pre-conditions </td></tr><tr>
o<td>&nbsp;Dependencies: </td>
o<td>&nbsp;Determine any dependencies on test requirements or other test cases </td></tr><tr>
o<td>&nbsp;Test Steps: </td>
o<td>&nbsp;Mention all the test steps in detail and write in the order in which it requires to be executed. While writing test steps ensure that you provide as much detail as you can </td></tr><tr>
o<td>&nbsp;Test Data: </td>
o<td>&nbsp;Use of test data as an input for the test case. Deliver different data sets with precise values to be used as an input </td></tr><tr>
o<td>&nbsp;Expected Results: </td>
o<td>&nbsp;Mention the expected result including error or message that should appear on screen </td></tr><tr>
o<td>&nbsp;Post-Condition: </td>
o<td>&nbsp;What would be the state of the system after running the test case? <div style="color:rgba(0,0,0,0.01);width:0;height:0">&nbsp; </div></td></tr><tr>
o<td>&nbsp;Actual Result: </td>
o<td>&nbsp;After test execution, actual test result should be filled </td></tr><tr>
o<td>&nbsp;Status (Fail/Pass): </td>
o<td>&nbsp;Mark this field as failed, if actual result is not as per the estimated result </td></tr><tr>
o<td>&nbsp;Notes: </td>
o<td>&nbsp;If there are some special condition which is left in above field </td></tr></tbody></table> <h3>Test Case vs Test Scenario</h3> 1.Test Case is a set of actions executed to verify particular features or functionality whereas Test Scenario is any functionality that can be tested.2.Test Case is mostly derived from test scenarios while Test Scenarios are derived from test artifacts like BRS and SRS.3.Test Case helps in exhaustive testing of an application whereas Test Scenario helps in an agile way of testing the end to end functionality.4.Test Cases are focused on what to test and how to test while Test Scenario is more focused on what to test.5.Test Cases are low-level actions whereas Test Scenarios are high-level actions.6.Test Case requires more resources and time for test execution while Test Scenario requires fewer resources and time for test execution.7.Test Case includes test steps, data, expected results for testing whereas Test Scenario includes an end to end functionality to be tested. Here, are significant differences between Test scenario and a Test Case <table style="border-collapse: collapse; width: 100%; text-align: justify;"><tbody>
<tr>
o<td style="width: 50%;">Test Scenario </td>
o<td style="width: 50%;">Test Case </td></tr>
<tr>
o<td style="width: 50%;">A test scenario contains high-level documentation which describes an end to end functionality to be tested. </td>
o<td style="width: 50%;">Test cases contain definite test steps, data, expected results for testing all the features of an application. </td></tr>
<tr>
o<td style="width: 50%;">It focuses on more "what to test" than "how to test". </td>
o<td style="width: 50%;">A complete emphasis on "what to test" and "how to test.". </td></tr>
<tr>
o<td style="width: 50%;">Test scenarios are a one-liner. So, there is always the possibility of ambiguity during the testing․ </td>
o<td style="width: 50%;">Test cases have defined a step, pre-requisites, expected result, etc. Therefore, there is no ambiguity in this process. </td></tr>
<tr>
o<td style="width: 50%;">Test scenarios are derived from test artifacts like BRS, SRS, etc. </td>
o<td style="width: 50%;">Test case is mostly derived from test scenarios. Multiple Test case can be derived from a single Test Scenario․ </td></tr>
<tr>
o<td style="width: 50%;">It helps in an agile way of testing the end-to-end functionality․ </td>
o<td style="width: 50%;">It helps in exhaustive testing of an application․ </td></tr>
<tr>
o<td style="width: 50%;">Test scenarios are high-level actions. </td>
o<td style="width: 50%;">Test cases are low-level actions. </td></tr>
<tr>
o<td style="width: 50%;">Comparatively less time and resources are required for creating &amp; testing using scenarios. </td>
o<td style="width: 50%;">More resources are needed for documentation and execution of test cases. </td></tr>

</tbody></table> <blockquote style="text-align: justify;">Useful Links: <a href="https://www.guru99.com/test-case.html" target="_blank" style="font-size: 14px;">Test case article/eng</a> <a href="https://www.parasoft.com/blog/how-to-write-test-cases-for-software-examples-tutorial/" target="_blank" style="font-size: 14px;">Test case article/eng</a> <a href="https://www.youtube.com/watch?v=e0cHqx5cRPo" target="_blank" style="font-size: 14px;">Test case video tutorial/rus</a> <a href="https://www.youtube.com/watch?v=g0PrXoWKM2Y" target="_blank" style="font-size: 14px;">Test case video tutorial/eng</a> <a href="https://www.youtube.com/watch?v=Hq7dt5zVxL0" target="_blank" style="font-size: 14px;">Test case, Test plan video tutorial/arm</a> </blockquote>

Test Case

<h3>Test Script</h3> A TEST SCRIPT is a set of instructions (written using a scripting/programming language) that is performed on a system under test to verify that the system performs as expected. Test scripts are used in automated testing. Sometimes, a set of instructions (written in a human language), used in manual testing, is also called a Test Script but a better term for that would be a Test Case. Some scripting languages used in automated testing are:<ol><li style="text-align: justify;">JavaScript</li><li style="text-align: justify;">Perl</li><li style="text-align: justify;">Python</li><li style="text-align: justify;">Ruby</li><li style="text-align: justify;">Tcl</li><li style="text-align: justify;">Unix Shell Script</li><li style="text-align: justify;">VBScript</li></ol> <blockquote style="text-align: justify;">Useful Links: <a href="https://www.guru99.com/test-script.html" target="_blank" style="font-size: 14px;">Test script article/eng</a> <a href="https://www.youtube.com/watch?v=txQZm6l4MbM" target="_blank">Test script video tutorial/eng</a> </blockquote>

Test Script as a part of testing documentation.

Test Script

<h3>Test Plan</h3> A TEST PLAN is a document describing software testing scope and activities. It is the basis for formally testing any software/product in a project. <h3>Test Plan Template</h3> Test Plan Identifier:<ul><li style="text-align: justify;">Every test plan must have a unique Identifier that may contain information about the version, type of the test plan, etc. for example: ‘Master Test plan for Workshop Module TP_1.0’ :</li></ul> Introduction:<ul><li style="text-align: justify;">Provide an overview of the test plan.</li><li style="text-align: justify;">Specify the goals/objectives.</li><li style="text-align: justify;">Specify any constraints.</li></ul> References:<ul><li style="text-align: justify;">List the related documents, with links to them if available, including the following:</li><li style="text-align: justify;">Project Plan</li><li style="text-align: justify;">Configuration Management Plan</li></ul> Test Items:<ul><li style="text-align: justify;">List the test items (software/products) and their versions.</li></ul> Features to be Tested:<ul><li style="text-align: justify;">List the features of the software/product to be tested.</li><li style="text-align: justify;">Provide references to the Requirements and/or Design specifications of the features to be tested</li></ul> Features Not to Be Tested:<ul><li style="text-align: justify;">List the features of the software/product which will not be tested.</li><li style="text-align: justify;">Specify the reasons these features won’t be tested.</li></ul> Approach:<ul><li style="text-align: justify;">Mention the overall approach to testing.</li><li style="text-align: justify;">Specify the testing levels [if it’s a Master Test Plan], the testing types, and the testing methods [Manual/Automated; White Box/Black Box/Gray Box]</li></ul> Item Pass/Fail Criteria:<ul><li style="text-align: justify;">Specify the criteria that will be used to determine whether each test item (software/product) has passed or failed testing.</li></ul> Suspension Criteria and Resumption Requirements:<ul><li style="text-align: justify;">Specify criteria to be used to suspend the testing activity.</li><li style="text-align: justify;">Specify testing activities which must be redone when testing is resumed.</li></ul> Test Deliverables:<ul><li style="text-align: justify;">List test deliverables, and links to them if available, including the following:</li><li style="text-align: justify;">Test Plan (this document itself)</li><li style="text-align: justify;">Test Cases</li><li style="text-align: justify;">Test Scripts</li><li style="text-align: justify;">Defect/Enhancement Logs</li><li style="text-align: justify;">Test Reports</li></ul> Test Environment:<ul><li style="text-align: justify;">Specify the properties of test environment: hardware, software, network etc.</li><li style="text-align: justify;">List any testing or related tools․</li></ul> Estimate:<ul><li style="text-align: justify;">Provide a summary of test estimates (cost or effort) and/or provide a link to the detailed estimation.</li></ul> Schedule:<ul><li style="text-align: justify;">Provide a summary of the schedule, specifying key test milestones, and/or provide a link to the detailed schedule.</li></ul> Staffing and Training Needs:<ul><li style="text-align: justify;">Specify staffing needs by role and required skills.</li><li style="text-align: justify;">Identify training that is necessary to provide those skills, if not already acquired.</li></ul> Responsibilities:<ul><li style="text-align: justify;">List the responsibilities of each team/role/individual.</li></ul> Risks:<ul><li style="text-align: justify;">List the risks that have been identified.</li><li style="text-align: justify;">Specify the mitigation plan and the contingency plan for each risk.</li></ul> Assumptions and Dependencies:<ul><li style="text-align: justify;">List the assumptions that have been made during the preparation of this plan.</li><li style="text-align: justify;">List the dependencies.</li></ul> Approvals:<ul><li style="text-align: justify;">Specify the names and roles of all persons who must approve the plan.</li><li style="text-align: justify;">Provide space for signatures and dates. (If the document is to be printed.</li></ul> <blockquote style="text-align: justify;"> Useful Links։ <a href="https://www.guru99.com/what-everybody-ought-to-know-about-test-planing.html" target="_blank">Test plan article/eng</a> <a href="https://www.youtube.com/watch?v=S2_AJP9Oeg0" target="_blank">Test plan video tutorial/eng</a> <a href="https://www.youtube.com/watch?v=KH7oPMlAaSM" target="_blank">Test plan video tutorial/rus</a> <a href="https://www.youtube.com/watch?v=Hq7dt5zVxL0" target="_blank">Test plan, Test case video tutorial/arm</a></blockquote>

Test Plan is an important document describing the process of software testing. 

Test Plan

<h3>Agile Model</h3> Agile is a coding practice that follows the rules and principles of agile software development. In this Agile Tutorial, you will learn the fundamentals of Agile, Agile models and methodologies, Agile Vs. Scrum differences, Scrum master training to Agile testing interview questions &amp; answers. This Agile development tutorial is an absolute beginners guide to Agile, and Scrum testing, Basic understanding of manual or automation software testing will be beneficial. <h3>How does Agile work?</h3> <ul><li style="text-align: justify;">You make a list</li><li style="text-align: justify;">You size things up</li><li style="text-align: justify;">You set some priorities</li><li style="text-align: justify;">You start executing</li><li style="text-align: justify;">You update the plan as you go</li></ul> <h3>How is Agile different?</h3> <ul><li style="text-align: justify;">Analysis, design, coding, and testing are continuous activities</li><li style="text-align: justify;">Development is iterative</li><li style="text-align: justify;">Planning is adaptive</li><li style="text-align: justify;">Roles blur</li><li style="text-align: justify;">Scope can vary</li><li style="text-align: justify;">Requirements can change</li><li style="text-align: justify;">Working software is the primary measure of success</li></ul> <h3>User stories and estimation</h3> <ul><li style="text-align: justify;">User stories are features our customers might one day like to see in their software.</li><li style="text-align: justify;">They are written on index cards to encourage face-to-face communication.</li><li style="text-align: justify;">Typically no more than a couple days work, they form the basis of our Agile plans.</li><li style="text-align: justify;">We get them by sitting down with our customers and asking lots of questions.</li></ul> <h3>Iterations</h3> Iterations are the basic building block of Agile development. Each iteration is a standard, fixed-length timebox, where Agile Teams deliver incremental value in the form of working, tested software and systems. The recommended duration of the timebox is two weeks. However, one to four weeks is acceptable, depending on the business context. Iterations provide a regular, predictable cadence for teams to produce an increment of value, as well as to refine those previously developed. These short time periods help the team, Product Owners, Product Managers, and other stakeholders regularly test and evaluate the technical and business hypotheses in a working system. Each iteration anchors an integration point, a ‘pull event’ that assembles various system aspects—functionality, quality, alignment, and fitness for use—across all the teams’ contributions. Since the shortest sustainable lead time is a significant goal of Lean-Agile development, Agile teams execute a full plan-do-check-adjust (PDCA) cycle as quickly as possible. The PDCA learning cycle (shown in Figure 1) represents the following iteration events: <ul><li style="text-align: justify;">Plan –Iteration Planning is the plan step </li><li style="text-align: justify;">Do – Iteration Execution is the do step</li><li style="text-align: justify;">Check – Iteration Review is the check step</li><li style="text-align: justify;">Adjust – Iteration Retrospective is the adjust step</li></ul> <h3>Planning and Refactoring</h3> <ul><li style="text-align: justify;">Master Story - Our to-do list on an agile project</li><li style="text-align: justify;">Team Velocity - The speed at which we turn user stories into working software</li><li style="text-align: justify;">Planning - iterations = total effort / estimated team velocity</li><li style="text-align: justify;">Refactoring - As we add more functionality to the system we need a way of maintaining our design and keeping our house in order.</li></ul> <blockquote style="text-align: justify;">Useful Links: <a href="https://www.infoworld.com/article/3237508/what-is-agile-methodology-modern-software-development-explained.html" target="_blank" style="font-size: 14px;">Agile methodology article/eng</a> <a href="https://scrumtrek.ru/blog/agile-scrum/4029/metodologiya-agile/" target="_blank">Agile methodology article/rus</a> <a href="https://www.youtube.com/watch?v=WjwEh15M5Rw" target="_blank">Agile methodology video tutorial/eng</a> <a href="https://www.youtube.com/watch?v=TPrj-AMJ4Ds" target="_blank">Agile methodology video tutorial/rus</a> </blockquote>

What is Agile Model and how does it work?

Agile Model

<h3>Agile VS Waterfall</h3> Key Difference Waterfall is a Liner Sequential Life Cycle Model whereas Agile is a continuous iteration of development and testing in the software development process.In Agile vs Waterfall difference, the Agile methodology is known for its flexibility whereas Waterfall is a structured software development methodology.Comparing the Waterfall methodology vs Agile which follows an incremental approach whereas the Waterfall is a sequential design process.Agile performs testing concurrently with software development whereas in Waterfall methodology testing comes after the “Build” phase.Agile allows changes in project development requirement whereas Waterfall has no scope of changing the requirements once the project development starts. <table style="border-collapse: collapse; width: 100%; text-align: justify;"><tbody>
<tr>
o<td style="width: 50%;">Agile </td>
o<td style="width: 50%;">Waterfall </td></tr>
<tr>
o<td style="width: 50%;">It separates the project development lifecycle into sprints. </td>
o<td style="width: 50%;">Software development process is divided into distinct phases. </td></tr>
<tr>
o<td style="width: 50%;">It follows an incremental approach. </td>
o<td style="width: 50%;">Waterfall methodology is a sequential design process. </td></tr>
<tr>
o<td style="width: 50%;">Agile methodology is known for its flexibility. </td>
o<td style="width: 50%;">Waterfall is a structured software development methodology so most times it can be quite rigid. </td></tr>
<tr>
o<td style="width: 50%;">Agile can be considered as a collection of many different projects. </td>
o<td style="width: 50%;">Software development will be completed as one single project. </td></tr>
<tr>
o<td style="width: 50%;">Agile is quite a flexible method which allows changes to be made in the project development requirements even if the initial planning has been completed. <div style="color:rgba(0,0,0,0.01);width:0;height:0">&nbsp; </div></td>
o<td style="width: 50%;">There is no scope of changing the requirements once the project development starts. </td></tr>
<tr>
o<td style="width: 50%;">Agile methodology, follow an iterative development approach because of this planning, development, prototyping and other software development phases may appear more than once. </td>
o<td style="width: 50%;">All the project development phases like designing, development, testing, etc. are completed once in the Waterfall model. </td></tr>
<tr>
o<td style="width: 50%;">Test plan is reviewed after each sprint <div style="color:rgba(0,0,0,0.01);width:0;height:0">&nbsp; </div></td>
o<td style="width: 50%;">The test plan is rarely discussed during the test phase. </td></tr>
<tr>
o<td style="width: 50%;">Agile development is a process in which the requirements are expected to change and evolve. </td>
o<td style="width: 50%;">The method is ideal for projects which have definite requirements and changes not at all expected. </td></tr>
<tr>
o<td style="width: 50%;">In Agile methodology, testing is performed concurrently with software development. </td>
o<td style="width: 50%;">In this methodology, the "Testing" phase comes after the "Build" phase </td></tr><tr>
o<td style="width: 50%;">Agile introduces a product mindset where the software product satisfies needs of its end customers and changes itself as per the customer's demands. </td>
o<td style="width: 50%;">This model shows a project mindset and places its focus completely on accomplishing the project. </td></tr><tr>
o<td style="width: 50%;">Agile methdology works exceptionally well with Time &amp; Materials or non-fixed funding. It may increase stress in fixed-price scenarios. </td>
o<td style="width: 50%;">Reduces risk in the firm fixed price contracts by getting risk agreement at the beginning of the process. </td></tr><tr>
o<td style="width: 50%;">Prefers small but dedicated teams with a high degree of coordination and synchronization. </td>
o<td style="width: 50%;">Team coordination/synchronization is very limited. </td></tr><tr>
o<td style="width: 50%;">Products owner with team prepares requirements just about every day during a project. </td>
o<td style="width: 50%;">Business analysis prepares requirements before the beginning of the project. </td></tr><tr>
o<td style="width: 50%;">Test team can take part in the requirements change without problems. </td>
o<td style="width: 50%;">It is difficult for the test to initiate any change in requirements. </td></tr><tr>
o<td style="width: 50%;">Description of project details can be altered anytime during the SDLC process. </td>
o<td style="width: 50%;">Detail description needs to implement waterfall software development approach. </td></tr><tr>
o<td style="width: 50%;">The Agile Team members are interchangeable, as a result, they work faster. There is also no need for project managers because the projects are managed by the entire team </td>
o<td style="width: 50%;">In the waterfall method, the process is always straightforward so, project manager plays an essential role during every stage of SDLC. </td></tr></tbody></table> <blockquote style="text-align: justify;">Useful links: <a href="https://worksection.com/blog/waterfall-vs-agile.html" target="_blank">Agile vs Waterfall article/rus</a> <a href="https://www.youtube.com/watch?v=rvTejAg_fbY" target="_blank">Agile vs Waterfall video tutorial/eng</a> <a href="https://project-management.com/agile-vs-waterfall/" target="_blank">Agile vs Waterfall article/eng</a> </blockquote>

What is the difference between Agile and Waterfall models?

Agile VS Waterfall

<h3>Scrum Methodology</h3> Scrum Master The Scrum Master helps the Scrum Team perform at their highest level. They also protect the team from both internal and external distractions. Product Owner The Product Owner is expected to do the best possible job of satisfying all stakeholders, maintain the Product Backlog, and ensure that everyone knows the priorities. The Development Team Development Teams are structured and empowered to organize and manage their own work. The resulting synergy optimizes overall efficiency and effectiveness. Backlog The Product Backlog is an ordered list of everything that is known to be needed in a product. It is constantly evolving and is never complete. The Sprint The heart of Scrum is a Sprint, during which a useable and potentially releasable product Increment is created. Sprints can be one week to one month in length and happen one right after the other to keep projects moving. There are four events that happen with each Sprint: <ul><li style="text-align: justify;">Sprint Planning – The Team decides what to work on for the current period.</li><li style="text-align: justify;">Daily Scrum – The Development Team meets for 15 minutes (or less) every day of the Sprint to inspect progress toward the Sprint Goal.</li><li style="text-align: justify;">Sprint Review – The Team collaborates about what was done and adapts the Backlog as needed.</li><li style="text-align: justify;">Sprint Retrospective – The Team discusses what went right, what went wrong, and how to improve.</li></ul> <blockquote style="text-align: justify;">Useful Links: <a href="https://www.atlassian.com/agile/scrum" target="_blank" style="font-size: 14px;">Scrum methodology article/eng</a> <a href="https://www.atlassian.com/ru/agile/scrum" target="_blank" style="font-size: 14px;">Scrum methodology article/rus</a> <a href="https://www.youtube.com/watch?v=8dGdIcyDk1w" target="_blank" style="font-size: 14px;">Scrum methodology video tutorial/eng</a> <a href="https://www.youtube.com/watch?v=mockcEwNBbs" target="_blank" style="font-size: 14px;">Scrum methodology video tutorial/rus</a></blockquote>

Scrum Methodology

<h3>Kanban Methodology</h3> Kanban goal There is only one thing - to receive a finished high-quality product on time. Let's figure out how to achieve this. Kanban starts with visualization so that processes are visible to the team. To do this, use a special board and a set of cards or stickers. Kanban boards The board is a mandatory element for an agile methodology. It is in Scrum, it is also in Kanban. Each team member has access to it at any time and sees what stage the task is at. The board is suitable both real and virtual: you can use a simple cork board or programs like Trello. The Kanban board adapts to any process and is used in any area. For example, to make a to-do list. How Kanban works in projects Every project has a work process plan. First we analyze it and divide the board into columns that reflect the stages.Column names change depending on the project, but it is important to keep them consistent - this is a key Kanban value called flow.Kanban cards are tasks that move along a flow and flow into other columns depending on their status. Write the name of the task on a card or sticker and attach it to the beginning of the board. With the help of a kanban board, it is easy to manage several projects at the same time, using cards of different colors: one color - one project. All processes are reflected on the board. The team analyzes them and eliminates weak points. In Kanban this is called flow control. A team in Kanban is a single mechanism. If someone fails, then the common cause suffers. Work is planned on a board so everyone can see their contribution and value to the project. Kanban combines the principles of agile methodologies and lean thinking. There are no hard and fast rules here, but there are principles that you can rely on. How visualization helps Visualization helps you see the whole picture and adjust its individual parts, understanding how changes will affect the entire project. It is possible to get results exactly on time if you control the team’s workload. Determine the number of tasks: how many the team is realistically capable of completing within the established time frame. For example, in “Designing” there are no more than two tasks at a time, and in “Testing” there is only one. It all depends on the capabilities of the team. <blockquote style="text-align: justify;">Useful Links: <a href="https://www.atlassian.com/agile/kanban" target="_blank">Kanban methodology article/eng</a> <a href="https://upr.ru/article/metodologiya-kanban-sekrety-effektivnogo-ispolzovaniya/" target="_blank">Kanban methodology article/rus</a> <a href="https://www.youtube.com/watch?v=1_Zti9v5ugA" target="_blank">Kanban methodology video tutorial/rus</a> <a href="https://www.youtube.com/watch?v=iVaFVa7HYj4" target="_blank">Kanban methodology video tutorial/eng</a></blockquote>

Kanban Methodology

<h3>Scrum VS Kanban</h3> <table style="border-collapse:collapse;width: 100%;"><tbody>
<tr>
o<td style="width: 50%; text-align: center;">Scrum </td>
o<td style="width: 50%; text-align: center;">Kanban </td></tr>
<tr>
o<td style="width: 50%;">Scrum stresses on planning. It starts with sprint planning and ends up with sprint retrospective. There are many meetings held which help to assure that the team is aligned with the next steps, priorities, and learnings from previous sprints. </td>
o<td style="width: 50%;">Kanban is open to making changes on the go. It means there is less rigidity and things can change frequently. </td></tr>
<tr>
o<td style="width: 50%;">It recommends collection of time measurements made during sprints. </td>
o<td style="width: 50%;">Kanban recommends graphs to get an overview of team's progress over time. </td></tr>
<tr>
o<td style="width: 50%;">Scrum no longer asks for a commitment from teams. Instead, it is about the sprint goals and forecasts. </td>
o<td style="width: 50%;">Kanban relies on time-boxing and forecasts. </td></tr>
<tr>
o<td style="width: 50%;">It stresses on planning, and so estimation has a very important role in Scrum </td>
o<td style="width: 50%;">Kanban has no mandatory requirements for estimation. </td></tr>
<tr>
o<td style="width: 50%;">Every individual has their role and responsibilities. </td>
o<td style="width: 50%;">No set roles so flexibility in term of individual responsibilities. </td></tr>
<tr>
o<td style="width: 50%;">The iterations/Sprints are fixed in duration. This duration varies from 2 weeks to 1 month. </td>
o<td style="width: 50%;">Kanban is not based on duration. This thing is measured regarding Cycle times. </td></tr>
<tr>
o<td style="width: 50%;">Teams are required to commit a specific amount of work. </td>
o<td style="width: 50%;">Commitment not necessary it is optional for teams </td></tr>
<tr>
o<td style="width: 50%;">In this method, cross-functional teams are important as they can deal with any disruption that may cause a bottleneck in the software development. </td>
o<td style="width: 50%;">Having specialized team is important. </td></tr>
<tr>
o<td style="width: 50%;">It is not possible to add items to ongoing iterations. </td>
o<td style="width: 50%;">New items can easily add if the additional capacity is available. </td></tr><tr>
o<td style="width: 50%;">A sprint backlog is owned by only by a single team. </td>
o<td style="width: 50%;">Multiple teams can share Kanban board. </td></tr><tr>
o<td style="width: 50%;">Deliverables are determined by sprints, which a set of work must be completed and ready for review. </td>
o<td style="width: 50%;">Products and processes are delivered continuously on a needed basis. So testing and review process goes on simultaneously. </td></tr><tr>
o<td style="width: 50%;">Scrum software development method focuses on the backlog. </td>
o<td style="width: 50%;">Kanban method entirely focuses on process dashboard. </td></tr><tr>
o<td style="width: 50%;">Every team member has a specific role in Scrum master decide timelines, product owner set goals and objectives, and team members conduct the development work. </td>
o<td style="width: 50%;">There are no pre-defined roles for a team. However, there may still be a Project Manager; the team is encouraged to collaborate and works together. </td></tr><tr>
o<td style="width: 50%;">Best for projects with changing priorities. </td>
o<td style="width: 50%;">Ideal for teams with stable priorities that unlikely to change over time. </td></tr><tr>
o<td style="width: 50%;">Measures production using velocity through sprints. </td>
o<td style="width: 50%;">Measures production using cycle time or the exact time it takes to complete one full piece of a project. </td></tr><tr>
o<td style="width: 50%;">Scrum requires a complete shift from the traditional model to the Agile Scrum model that would be implemented the project. </td>
o<td style="width: 50%;">Kanban doesn't allow drastic changes in the project. </td></tr><tr>
o<td style="width: 50%;">It is an ideal method for projects with widely-varying priorities. </td>
o<td style="width: 50%;">Best suitable for teams with stable priorities. </td></tr><tr>
o<td style="width: 50%;">In Scrum, the entire team focuses on to collaborate and complete the task to provide quality development work. </td>
o<td style="width: 50%;">Teams work to achieve goals and reduce the time to complete the entire process. Thus, reduction in the time cycle is biggest indicators of success here. </td></tr><tr>
o<td style="width: 50%;">Scrum emphasis on its schedules; new items cannot be added to ongoing iterations. </td>
o<td style="width: 50%;">Kanban is more iterative by nature as it does not have specific timeframes. So that, new items can be continually added whenever additional capacity is available. </td></tr></tbody></table> <blockquote>Useful Links: <a href="https://www.guru99.com/scrum-vs-kanban.html" target="_blank" style="font-size: 14px;">Scrum vs Kanban article/eng</a> <a href="https://asana.com/ru/resources/waterfall-agile-kanban-scrum" target="_blank" style="font-size: 14px;">Scrum vs Kanban article/rus</a> <a href="https://www.youtube.com/watch?v=GLFuzBiy18o" target="_blank" style="font-size: 14px;">Scrum vs Kanban video tutorial/eng</a></blockquote>

Differences between two Agile methodologies: Scrum and Kanban.

Scrum VS Kanban

<h3>Terminology</h3> WWW (Word Wide Web) - World Wide Web, which is also known as a Web, is a collection of websites or web pages stored in web servers and connected to local computers through the internet. These websites contain text pages, digital images, audios, videos, etc. Users can access the content of these sites from any part of the world over the internet using their devices such as computers, laptops, cell phones, etc. The WWW, along with internet, enables the retrieval and display of text and media to your device. URI (Uniform Resource Identifier) -A URI is a string containing characters that identify a physical or logical resource. URI follows syntax rules to ensure uniformity. Moreover, it also maintains extensibility via a hierarchical naming scheme. The full form of URI is Uniform Resource Identifier. URN (Uniform Resource Name) - Uniform Resource Name (URN) is an internet resource that specifies URN scheme. URL (Uniform Resource Locator) – A URL is a global address of documents and protocols to retrieve resource on a computer network. URLs occur most frequently in reference to web pages (HTTP) but can also be used for database access using JDBC, email (mailto), file transfer (FTP), and many other applications. URL stands for Uniform Resource Locator. Web Browser – "A web browser, or simply 'browser,' is an application used to access and view websites. Web Server - A web server is a computer that runs websites. It's a computer program that distributes web pages as they are requisitioned. The basic objective of the web server is to store, process and deliver web pages to the users. This intercommunication is done using Hypertext Transfer Protocol (HTTP). Web Page – A document which can be displayed in a web browser such as Firefox, Google Chrome, Opera, Microsoft Internet Explorer or Edge, or Apple's Safari. These are also often called just "pages." website. A collection of web pages which are grouped together and usually connected together in various ways. Web Site – a group of World Wide Web pages usually containing hyperlinks to each other and made available online by an individual, company, educational institution, government, or organization The client side is visible to the user, but the server side is not. <h3>Protocols</h3> Below are the 4 main protocols: <ul><li style="text-align: justify;">IP (Internet Protocol)</li><li style="text-align: justify;">FTP (File Transfer Protocol)</li><li style="text-align: justify;">HTTP (Hypertext Transfer Protocol)</li><li style="text-align: justify;">HTTPS (Hypertext Transfer Protocol Secure)</li></ul> Cash - A temporary storage area in memory or on disk that holds the most recently downloaded Web pages. As you jump from Web page to Web page, caching those pages in memory lets you quickly go back to a page without having to download it from the Web again. Cookie - Cookies are text files with small pieces of data — like a username and password — that are used to identify your computer as you use a computer network. Specific cookies known as HTTP cookies are used to identify specific users and improve your web browsing experience. Authentication - Authentication is the act of validating that users are whom they claim to be. This is the first step in any security process. Giving someone permission to download a particular file on a server or providing individual users with administrative access to an application are good examples of authentication. Authorization - Authorization in a system security is the process of giving the user permission to access a specific resource or function. This term is often used interchangeably with access control or client privilege. In secure environments, authorization must always follow authentication. Users should first prove that their identities are genuine before an organization’s administrators grant them access to the requested resources. <h3>HTTP(S) Methods</h3> <table style="border-collapse: collapse; width: 100.281%; text-align: justify;"><tbody>
<tr>
o<td style="width: 10.201%;">HTTP Verb </td>
o<td style="width: 14.0704%;">CRUD </td>
o<td style="width: 38.5427%;">Entire Collection (e.g. /customers) </td>
o<td style="width: 37.1357%;">Specific Item (e.g. /customers/{id}) </td></tr>
<tr>
o<td>POST <div style="color:rgba(0,0,0,0.01);width:0;height:0">&nbsp; </div></td>
o<td>Create </td>
o<td>201 (Created), 'Location' header with link to /customers/{id} containing new ID. </td>
o<td>404 (Not Found), 409 (Conflict) if resource already exists.. </td></tr>
<tr>
o<td>GET </td>
o<td>Read </td>
o<td>200 (OK), list of customers. Use pagination, sorting and filtering to navigate big lists. </td>
o<td>200 (OK), single customer. 404 (Not Found), if ID not found or invalid. </td></tr>
<tr>
o<td>PUT </td>
o<td>Update/Replace </td>
o<td>405 (Method Not Allowed), unless you want to update/replace every resource in the entire collection. </td>
o<td>200 (OK) or 204 (No Content). 404 (Not Found), if ID not found or invalid. </td></tr>
<tr>
o<td>PATCH </td>
o<td>Update/Modify </td>
o<td>405 (Method Not Allowed), unless you want to modify the collection itself. </td>
o<td>200 (OK) or 204 (No Content). 404 (Not Found), if ID not found or invalid. </td></tr><tr>
o<td>DELETE </td>
o<td>Delete </td>
o<td>405 (Method Not Allowed), unless you want to delete the whole collection—not often desirable. </td>
o<td>200 (OK). 404 (Not Found), if ID not found or invalid. </td></tr></tbody></table> <blockquote style="text-align: justify;">Useful Links: <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP" target="_blank">HTTP Basics article/eng</a> <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods" target="_blank">HTTP methods article/rus</a> <a href="https://www.youtube.com/watch?v=eesqK59rhGA" target="_blank">HTTP and WEB video tutorial/eng</a> <a href="https://www.youtube.com/watch?v=9aycvfzH8UA" target="_blank">HTTP video tutorial/rus</a> <a href="https://www.youtube.com/watch?v=FsE0W7_l3uo" target="_blank">HTTP response video tutorial/arm</a></blockquote>

What is the role of web technologies in QA.

The role of web technologies in QA

<h3>Regular Expression</h3> Terminology

 ^_ - indicates a line that starts with _ . _$ - indicates a string that ends with _ . abc* - abc / |c|&gt;=0 abc+ - abc / |c|&gt;=1 abc? - abc / |c|={0,1} abc{2} - abc / |c|=2 abc{2,5} - abc / 2&lt;=|c|&lt;=5 d - specifies the numbers one by one (d)+ - indicates the numerical segment between two numbers w - specifies letters one by one (w)+ - indicates the letter segment between two letters, i.e. words (D)+ - indicates the non-numeric portion between two numbers s - space [0-9] - specifies numbers in the range [0-9] one by one [0-9]+ - specifies multiple numbers [0-9]+ [a-z] +[0-9]+ -number, letter, number [^_] – specifies everything except a space [_] – marks only _s • - specifies a single character Example: (/d [a,z] + /d (,) /s [0,6]+) .$ <img src="https://lh4.googleusercontent.com/O5bWLkMcrUEwsqT2cy5oWr4R01dMpmVNrl4x60H3NEV5dj6kj0tW4sWGy7WNULq2cOA2N993YgbCuraUDhzAWyHS0t46zKCpeoQnTXFFTWFzQX0QytZSlgWSmmk2lg161ZvQFYUlrFr_R1ooDtyTh1M7YDfok4R3jjxPTLV2Q7oz4AUq81jVYMz6kcxbTDNzT3guy9Lw"> <blockquote>Useful Links: <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_Expressions" target="_blank">Regular expressions article/eng</a> <a href="https://developer.mozilla.org/ru/docs/Web/JavaScript/Guide/Regular_Expressions" target="_blank">Regular expressions article/rus</a> <a href="https://www.youtube.com/watch?v=sa-TUpSx1JA" target="_blank">Regular expressions video tutorial/eng</a> <a href="https://www.youtube.com/watch?v=_pLpx6btq6U" target="_blank">Regular expressions video tutorial/rus</a></blockquote>

Regular expressions

<h3>Linux</h3>
 
Linux is an operating system's kernel. You might have heard of UNIX. Well, Linux is a UNIX clone. But it was actually created by Linus Torvalds from Scratch. Linux is free and open-source, that means that you can simply change anything in Linux and redistribute it in your own name! There are several Linux Distributions, commonly called “distros”.
 

 1.Ubuntu Linux
 2.Red Hat Enterprise Linux
 3.Linux Mint
 4.Debian
 5.Fedora

 
Linux is Mainly used in servers. About 90% of the internet is powered by Linux servers. This is because Linux is fast, secure, and free! The main problem of using Windows servers are their cost. This is solved by using Linux servers. The OS that runs in about 80% of the smartphones in the world, Android, is also made from the Linux kernel. Most of the viruses in the world run on Windows, but not on Linux! So, basically, a shell is a program that receives commands from the user and gives it to the OS to process, and it shows the output. Linux's shell is its main part. Its distros come in GUI (graphical user interface), but basically, Linux has a CLI (command line interface). In this tutorial, we are going to cover the basic commands that we use in the shell of Linux. To open the terminal, press Ctrl+Alt+T in Ubuntu, or press Alt+F2, type in gnome-terminal, and press enter. In Raspberry Pi, type in lxterminal. There is also a GUI way of taking it, but this is better!
 
<h3>Linux Basic Commands</h3>
 
pwd — When you first open the terminal, you are in the home directory of your user. To know which directory you are in, you can use the “pwd” command. It gives us the absolute path, which means the path that starts from the root. The root is the base of the Linux file system. It is denoted by a forward slash( / ). The user directory is usually something like "/home/username".
 

 
ls — Use the "ls" command to know what files are in the directory you are in. You can see all the hidden files by using the command “ls -a”.
 

 
cd — Use the "cd" command to go to a directory. For example, if you are in the home folder, and you want to go to the downloads folder, then you can type in “cd Downloads”. Remember, this command is case sensitive, and you have to type in the name of the folder exactly as it is. But there is a problem with these commands. Imagine you have a folder named “Raspberry Pi”. In this case, when you type in “cd Raspberry Pi”, the shell will take the second argument of the command as a different one, so you will get an error saying that the directory does not exist. Here, you can use a backward slash. That is, you can use “cd Raspberry Pi” in this case. Spaces are denoted like this: If you just type “cd” and press enter, it takes you to the home directory. To go back from a folder to the folder before that, you can type “cd ..” . The two dots represent back.
 

 
mkdir &amp; rmdir — Use the mkdir command when you need to create a folder or a directory. For example, if you want to make a directory called “DIY”, then you can type “mkdir DIY”. Remember, as told before, if you want to create a directory named “DIY Hacking”, then you can type “mkdir DIY Hacking”. Use rmdir to delete a directory. But rmdir can only be used to delete an empty directory. To delete a directory containing files, use rm.
 

 
rm - Use the rm command to delete files and directories. Use "rm -r" to delete just the directory. It deletes both the folder and the files it contains when using only the rm command.
 

 
touch — The touch command is used to create a file. It can be anything, from an empty txt file to an empty zip file. For example, “touch new.txt”.
 

 
man &amp; --help — To know more about a command and how to use it, use the man command. It shows the manual pages of the command. For example, “man cd” shows the manual pages of the cd command. Typing in the command name and the argument helps it show which ways the command can be used (e.g., cd –help).
 

 
cp — Use the cp command to copy files through the command line. It takes two arguments: The first is the location of the file to be copied, the second is where to copy.
 

 
mv — Use the mv command to move files through the command line. We can also use the mv command to rename a file. For example, if we want to rename the file “text” to “new”, we can use “mv text new”. It takes the two arguments, just like the cp command.
 

 
locate — The locate command is used to locate a file in a Linux system, just like the search command in Windows. This command is useful when you don't know where a file is saved or the actual name of the file. Using the -i argument with the command helps to ignore the case (it doesn't matter if it is uppercase or lowercase). So, if you want a file that has the word “hello”, it gives the list of all the files in your Linux system containing the word "hello" when you type in “locate -i hello”. If you remember two words, you can separate them using an asterisk (*). For example, to locate a file containing the words "hello" and "this", you can use the command “locate -i *hello*this”.
 

 
<h3>Intermediate Commands</h3>
 

 echo — The "echo" command helps us move some data, usually text into a file. For example, if you want to create a new text file or add to an already made text file, you just need to type in, “echo hello, my name is alok &gt;&gt; new.txt”. You do not need to separate the spaces by using the backward slash here, because we put in two triangular brackets when we finish what we need to write.
 cat — Use the cat command to display the contents of a file. It is usually used to easily view programs.

 

 

 nano, vi, jed — nano and vi are already installed text editors in the Linux command line. The nano command is a good text editor that denotes keywords with color and can recognize most languages. And vi is simpler than nano. You can create a new file or modify a file using this editor. For example, if you need to make a new file named "check.txt", you can create it by using the command “nano check.txt”. You can save your files after editing by using the sequence Ctrl+X, then Y (or N for no). In my experience, using nano for HTML editing doesn't seem as good, because of its color, so I recommend jed text editor. We will come to installing packages soon.

 

 

 sudo — A widely used command in the Linux command line, sudo stands for "SuperUser Do". So, if you want any command to be done with administrative or root privileges, you can use the sudo command. For example, if you want to edit a file like viz. alsa-base.conf, which needs root permissions, you can use the command – sudo nano alsa-base.conf. You can enter the root command line using the command “sudo bash”, then type in your user password. You can also use the command “su” to do this, but you need to set a root password before that. For that, you can use the command “sudo passwd”(not misspelled, it is passwd). Then type in the new root password.

 

 

 df — Use the df command to see the available disk space in each of the partitions in your system. You can just type in df in the command line and you can see each mounted partition and their used/available space in % and in KBs. If you want it shown in megabytes, you can use the command “df -m”.

 

 

 du — Use du to know the disk usage of a file in your system. If you want to know the disk usage for a particular folder or file in Linux, you can type in the command df and the name of the folder or file. For example, if you want to know the disk space used by the documents folder in Linux, you can use the command “du Documents”. You can also use the command “ls -lah” to view the file sizes of all the files in a folder.

 

 

 tar — Use tar to work with tarballs (or files compressed in a tarball archive) in the Linux command line. It has a long list of uses. It can be used to compress and uncompress different types of tar archives like .tar, .tar.gz, .tar.bz2,etc. It works on the basis of the arguments given to it. For example, "tar -cvf" for creating a .tar archive, -xvf to untar a tar archive, -tvf to list the contents of the archive, etc. Since it is a wide topic, here are some examples of tar commands.
 zip, unzip — Use zip to compress files into a zip archive, and unzip to extract files from a zip archive.
 uname — Use uname to show the information about the system your Linux distro is running. Using the command “uname -a” prints most of the information about the system. This prints the kernel release date, version, processor type, etc.

 
 
 

 apt-get — Use apt to work with packages in the Linux command line. Use apt-get to install packages. This requires root privileges, so use the sudo command with it. For example, if you want to install the text editor jed (as I mentioned earlier), we can type in the command “sudo apt-get install jed”. Similarly, any packages can be installed like this. It is good to update your repository each time you try to install a new package. You can do that by typing “sudo apt-get update”. You can upgrade the system by typing “sudo apt-get upgrade”. We can also upgrade the distro by typing “sudo apt-get dist-upgrade”. The command “apt-cache search” is used to search for a package. If you want to search for one, you can type in “apt-cache search jed”(this doesn't require root).

 

 

 chmod — Use chmod to make a file executable and to change the permissions granted to it in Linux. Imagine you have a python code named numbers.py in your computer. You'll need to run “python numbers.py” every time you need to run it. Instead of that, when you make it executable, you'll just need to run “numbers.py” in the terminal to run the file. To make a file executable, you can use the command “chmod +x numbers.py” in this case. You can use “chmod 755 numbers.py” to give it root permissions or “sudo chmod +x numbers.py” for root executable. Here is some more information about the chmod command.

 

 

 hostname — Use hostname to know your name in your host or network. Basically, it displays your hostname and IP address. Just typing “hostname” gives the output. Typing in “hostname -I” gives you your IP address in your network.

 

 

 ping — Use ping to check your connection to a server. Wikipedia says, "Ping is a computer network administration software utility used to test the reachability of a host on an Internet Protocol (IP) network". Simply, when you type in, for example, “ping google.com”, it checks if it can connect to the server and come back. It measures this round-trip time and gives you the details about it. The use of this command for simple users like us is to check your internet connection. If it pings the Google server (in this case), you can confirm that your internet connection is active!

 

 
 
Tips and Tricks for Using Linux Command Line
 

 1.You can use the clear command to clear the terminal if it gets filled up with too many commands.
 2.TAB can be used to fill up in terminal. For example, You just need to type “cd Doc” and then TAB and the terminal fills the rest up and makes it “cd Documents”.
 3.Ctrl+C can be used to stop any command in terminal safely. If it doesn't stop with that, then Ctrl+Z can be used to force stop it.
 4.You can exit from the terminal by using the exit command.
 5.You can power off or reboot the computer by using the command sudo halt and sudo reboot

 
 
 
<blockquote style="text-align: justify;">Useful Links: <a href="https://www.pluralsight.com/guides/beginner-linux-navigation-manual" target="_blank">Linux for beginners article/eng</a> <a href="https://www.guru99.com/unix-linux-tutorial.html" target="_blank">Linux for beginners article/eng</a> <a href="https://habr.com/ru/post/481398/" target="_blank">Linux commands article/rus</a> <a href="https://www.youtube.com/watch?v=IVquJh3DXUA" target="_blank">Linux for beginners video tutorial/eng</a> <a href="https://www.youtube.com/watch?v=qwopGsaNF_Q" target="_blank">Linux for beginners video tutorial/rus</a></blockquote>

Linux

<h3>Git</h3> Installing, configuring, creating a repository For example, you need to transfer the information you created (from your home or work computer) to a server (for example, the GitHub repository). So that every member of your team, or, for example, an instructor, can access your files. In this case, you need to decide which folder or file you want to synchronize with the server, i.e. create a local storage (repository). We will consider it using the example of working with IDEA and managing from the console. This example is not specifically tied to the software used, so you can repeat this example for your specific situation. Step by step: <ol><li style="text-align: justify;">Create your own GIT HUB repository. This will be our server storage, which any participant can work with and access to it.</li><li style="text-align: justify;">Create your own free repository on GITHUB Install GIT itself, to do this, follow the link and download the current version for today: DOWNLOAD GIT Free</li><li style="text-align: justify;">In the appeared GIT console window on your computer (or cmd console), enter the following commands from the keyboard (each command ends by pressing the Enter key) :</li></ol> <ul><li style="text-align: justify;">git - this command displays a list of available commands, but for us now it simply serves as a confirmation that step 2 was done correctly and GIT is working</li><li style="text-align: justify;">git config --global user.name "Ivan Ivanov" - specify your name.</li><li style="text-align: justify;">git config --global user.email IvanIvanov@example.com - specify your email address</li><li style="text-align: justify;">cd: C: / Users / Ivanov / IdeaProjects / Project1 - with this command you go to the folder you need, which in the next step you will make as a local storage (i.e. this is your working directory where all project changes will be stored)</li><li style="text-align: justify;">git init - Create a repository in the current directory</li><li style="text-align: justify;">git add. - this command indexes (checks and remembers) all files (dot at the end of the command), which later will be subject to commit (essentially saved).</li><li style="text-align: justify;">git commit -m "Commit Text" - saving changes to a local folder.</li></ul> That's it, the local repository has been created, now we need to link the local and remote (GITHUB created in point 1) repositories. To do this, we need to enter the following commands: <ul><li style="text-align: justify;">git remote add origin https://github.com/GithubUser/RepositiryName.git - where, https://github.com/GithubUser/RepositiryName.git the address of the repository you created on GitHub can be copied directly from the browser with the addition of .git</li><li style="text-align: justify;">git push -u origin master</li></ul> Congratulations, you have linked the remote and local repositories. To upload files to the remote repository, run the command: git push - after pressing Enter, the first time you are asked to enter your GitHub username and password. You can now see the changes made on the GitHub site. Please note that after you have made changes with the files, in our example, this saved the project in IDEA, you need to run the following commands: <ul><li style="text-align: justify;">git add. - this command indexes (checks and remembers) all files (dot at the end of the command), which later will be subject to commit (essentially saved).</li><li style="text-align: justify;">git commit -m "Commit Text" - saving changes to a local folder.</li></ul> To transfer to the remote repository, run this command as well: git push In order, on the contrary, to get information from the remote repository to the local repository, run the command: git pull Useful Links: <a href="https://www.atlassian.com/git/tutorials/what-is-git" target="_blank">Git article/eng</a> <a href="https://www.atlassian.com/git" target="_blank">Git article/eng</a> <a href="https://www.youtube.com/watch?v=SWYqp7iY_Tc" target="_blank">GitHub video tutorial/eng</a> <a href="https://www.youtube.com/watch?v=CRlGDDprdOQ" target="_blank">Git video tutorial/eng</a>

<h3>Functional Testing</h3> The purpose of Functional Testing is to verify each function of the software application, ensuring the appropriate input, verifying the output depending on the functional requirements. It checks whether each component is working as expected or not. Therefore, it is also called "Component testing". This type of testing is mandatory regardless of the type of application. During Functional Testing, the Black Box Testing technique is used, in which the internal logic of the system under test is not known. Tests User Interface, APIs, Database, Security, Client/Server communication and other application functions. It can be done both manually and automatically. Functions are tested by passing them input data and examining the output. Functional Testing ensures that the application properly meets the requirements. This type of testing is not related to how the implementation happens, but only related to the results. What does Functional Testing test? 1. The main functions of the application, the described functionality. In other words, the behavior of the application is tested according to the test specification. 2. Error conditions - presence of messages in case of error conditions. Steps of Functional Testing 1. Understand the functions that the application should implement. 2. Generate input data based on function specifications. 3. Determine the expected output results for the selected input values. 4. Implement test cases. 5. Comparison of actual and expected results. Types of Functional Testing 1. Unit testing 2. Integration testing 33. Interface testing 4. System testing 5. Regression testing 6. Smoke testing 7. Sanity testing 8. Acceptance testing Unit testing 1. In this type of functional testing, the smallest functional and testable unit of code is tested during unit testing. 2. Mainly performed by developers as it is a White-Box testing technique. 3. Performed at the earliest stages of development, hence helps to identify defects at early stages of development. This helps save the higher cost of fixing defects in later stages of STLC. Integration testing 1. Two or more unit-tested components of software are integrated together and tested to confirm that they interact as expected. 2. The communication of commands, data, DB calls, API calls, microservices processing takes place between departments and no unexpected behavior is observed during this integration. Interface testing 1. Part of integration testing; The accuracy of data exchange, data transfer, messages, calls and commands between two integrated components is verified. 2. The communication between the database, web services, APIs or any external component and the application is tested during Interface testing. 3. There should not be any error or format mismatch in the communication of this data or command. If such a problem occurs, it should be fixed. 4. Interface testing is the testing of connectivity between different interfaces, while Integration testing is the testing of an integrated group of modules as a single unit. System testing 1. All system components are combined and the system is tested for conformance and accuracy to requirements specifications (functional or system). 2. It is a Black-Box testing technique that validates the integrated system. 3. It is performed before Acceptance testing (UAT) in STLC (Software testing life cycle). 4. System testing is performed in a near-real environment and according to real-life usage. Regression testing 1. After some improvements or code fixes by the developers, it becomes very important to run the Regression testing package. Regression testing is performed to ensure that these code changes have not hindered existing working functionality or introduced any new defects in the code. 2. Regression testing cases are a subset of existing functional tests that cover the main functions of the system. 3. Regression cases should be updated, added and deleted according to changes in the application. 4. Regression testing cases are the best candidates for automation testing because they are run frequently and take time to execute. Smoke testing 1. After Developement, when a new build is released, Smoke Testing is performed on the application to ensure that all key features work to perfection. 2. Smoke Testing is usually performed early in application development for builds that are not yet stable. 3. During testing, if any key functionality does not work as expected, that particular build is rejected. Developers should fix bugs and create a new build for further testing. 4. After successful smoke testing, the application is ready for the next level of testing. Sanity testing 1. Sanity testing is selected from the Regression testing suite, covering the core functionality of the application. 2.Sanity Testing is performed on a new build created by developers for a relatively stable application. 3. Once the application successfully passes Sanity testing, it is ready for the next level of testing. 4. It is easy to confuse Smoke testing and Sanity testing. After a new build, Smoke Testing is done to test the initial application. After multiple releases, once it has achieved stability, Sanity Testing is performed on the same application. Acceptance testing 1. Acceptance of the application by the end user is checked during acceptance testing. The purpose of this testing is to ensure that the developed system fulfills all the requirements that were agreed during the creation of the business requirements. 2. It is performed immediately after System testing and before the final release of the application. 3. Acceptance testing becomes a criterion for the user to either accept or reject the system. 4. It is a Black-Box testing technique because we are only interested in knowing the functionality of the application for the market and real users. Useful links: <a href="https://www.guru99.com/functional-testing.htm" target="_blank">Functional testing article/eng</a><a href="https://www.applause.com/blog/functional-testing-types-examples" target="_blank">Functional testing types article/eng</a><a href="https://coderlessons.com/tutorials/kachestvo-programmnogo-obespecheniia/ruchnoe-testirovanie/funktsionalnoe-testirovanie-2" target="_blank">Functional testing article/rus</a><a href="https://www.youtube.com/watch?v=IGnZHgjU42Y" target="_blank">Functional testing video tutorial/eng</a><a href="https://www.youtube.com/watch?v=B1-1BqAr1f4" target="_blank">Functional testing video tutorial/rus</a>

Functional Testing

<h3>Introduction to AI &amp; LLM Testing</h3>Artificial intelligence and large language models (LLMs) are now part of the products QA engineers are asked to test — chatbots, AI-assisted search, content generators, and automated decision tools. Testing these systems draws on the same testing mindset as traditional software QA, but it adds a set of problems that classic manual and automated testing were never designed to handle.This article covers:<ol><li>What makes AI systems different to test</li><li>Non-determinism and why it changes how you write test cases</li><li>The main categories of AI testing</li><li>Where AI testing fits in the development lifecycle</li><li>How a QA engineer can start learning AI testing</li></ol><h3>What Makes AI Systems Different to Test</h3>Traditional software is deterministic: given the same input and the same code, you get the same output every time. A login form either accepts a password or rejects it, and that behavior does not change between test runs. AI systems, especially those built on machine learning models, do not work this way. Their behavior is learned from data rather than written as explicit rules, which means the system can be technically 'working correctly' and still produce an answer nobody predicted.This has three practical consequences for testing. First, there is rarely a single correct output to assert against — testers work with a range of acceptable answers instead of one expected value. Second, the system's behavior can drift over time as the underlying model is retrained or fine-tuned, so a test that passed last month is not guaranteed to pass today. Third, failures are often subtle: the system responds fluently and confidently even when it is wrong, so a tester has to actively look for errors rather than wait for the system to crash or throw a visible error.<h3>Non-Determinism: Same Input, Different Output</h3>Ask an LLM the same question twice and you may get two differently worded — sometimes contradictory — answers. This happens because most language models generate text by sampling from a probability distribution over possible next words, rather than always picking the single most likely one. Some systems allow this randomness to be reduced (often called 'temperature'), but it is rarely eliminated completely, and many production systems keep some randomness on purpose because it makes responses feel more natural.For testing, this means a single test run proves very little. A test case that passes once could fail on the next run with identical input, and a test that fails once might be an anomaly rather than a genuine bug. Effective AI testing usually runs the same input multiple times and looks at the pattern of outputs — how often the system gives a correct, acceptable, or wrong answer — rather than treating one run as a definitive pass or fail.<h3>The Main Categories of AI Testing</h3>AI testing is usually organized around a few overlapping concerns, and a mature test strategy touches all of them:<ul><li>Functional accuracy — does the system produce correct, relevant answers for the tasks it was built for?</li><li>Robustness — does it hold up against unusual, malformed, or adversarial input instead of breaking or producing nonsense?</li><li>Safety and bias — does it avoid harmful, offensive, or discriminatory output, and does it treat different groups of users fairly?</li><li>Consistency — does it give stable, non-contradictory answers to the same or similar questions?</li><li>Performance — does it respond within an acceptable time and cost, especially under load?</li></ul>Each of these needs a different kind of test design, and most real projects prioritize them differently depending on what the AI system is used for — a customer-facing chatbot puts more weight on safety and bias than an internal data-summarization tool does, for example.<h3>Where AI Testing Fits in the Development Lifecycle</h3>AI testing is not a single phase at the end of development — it happens at several points:<ul><li>Data testing, before a model is trained, to check that training and evaluation data is representative, balanced, and free of obvious quality problems.</li><li>Model evaluation, where data scientists and QA jointly define benchmarks the model must pass before it is considered ready.</li><li>Integration testing, once the model is wired into the actual product, to test the AI feature the way a user will actually experience it — through the UI, the API, and the surrounding application logic.</li><li>Production monitoring, after release, because a model's real-world behavior can differ from what was seen in testing, and can change over time as user input patterns shift.</li></ul>QA engineers are typically most involved in integration testing and production monitoring, working alongside data scientists and ML engineers who own the earlier stages.<h3>Getting Started as a QA Engineer</h3>You do not need a machine learning background to start testing AI features. The core testing skills — designing test cases, thinking in edge cases, documenting defects clearly, and being systematic about coverage — transfer directly. What changes is the mindset: instead of asserting on one expected value, you learn to define a range of acceptable outputs, run tests repeatedly rather than once, and pay close attention to how confidently a system states something that turns out to be wrong.A practical way to start is to pick a feature you already use — a chatbot, a search assistant, an AI writing tool — and deliberately try to break it: ask it something outside its scope, give it contradictory instructions, or ask the same question five times and compare the answers. The patterns you notice from that kind of exploration are the foundation the rest of the articles in this section build on.<h3>Further Reading</h3>Tesvan has published several real case studies on AI testing challenges:<a href='https://tesvan.com/blog/defining-correct-ai-systems' target='_blank'>Defining &ldquo;Correct&rdquo; in AI Systems</a> <a href='https://tesvan.com/blog/llm-instability-internet-marketplace-platforms' target='_blank'>Solving LLM Instability in Internet Marketplace Platforms</a> <a href='https://tesvan.com/blog/retrieval_augumented_factuality' target='_blank'>Retrieval-Augmented Factuality</a> <a href='https://tesvan.com/blog/hallucination_testing_in_chatbots' target='_blank'>Hallucination Testing In Chatbots</a>

What AI and LLM testing is, how it differs from traditional QA, and the skills a beginner QA needs to get started.

Introduction to AI & LLM Testing

<h3>Hallucination Testing</h3>A 'hallucination' is one of the most talked-about failure modes in AI systems: the model states something false, invented, or unsupported by its source material, but presents it with the same fluent confidence as a correct answer. For a QA engineer, hallucinations are hard to catch precisely because they don't look like bugs — there is no error message, no crash, just a wrong answer delivered convincingly.This article covers:<ol><li>What a hallucination is</li><li>Why hallucinations happen</li><li>Common types of hallucinations</li><li>How to design hallucination test cases</li><li>How to measure and report a hallucination rate</li></ol><h3>What Is a Hallucination</h3>In the context of AI testing, a hallucination is any output that is presented as fact but is not supported by the model's training data, the source documents it was given, or reality. This is different from a system simply saying 'I don't know' — a hallucination is confidently wrong, not honestly uncertain, which is what makes it dangerous in production. A customer support bot that invents a refund policy, or a document summarizer that adds a detail that was never in the source document, are both hallucinating even though neither one crashed or returned an error.<h3>Why Hallucinations Happen</h3>Language models generate text by predicting the most statistically likely next word based on patterns learned from training data — they do not have a built-in mechanism for checking whether a sentence is factually true before producing it. Several conditions make hallucinations more likely:<ul><li>The question asks about something outside or at the edge of what the model was trained on.</li><li>The prompt is ambiguous, so the model fills in gaps with a plausible-sounding guess.</li><li>The system is asked for a very specific fact (a date, a statistic, a citation) where a fluent-but-wrong answer is easy for the model to produce and hard for a user to catch.</li><li>The model is under pressure to always produce an answer rather than being allowed to say it does not know.</li></ul><h3>Common Types of Hallucinations</h3>Hallucinations aren't a single failure pattern — a useful test strategy usually distinguishes between a few types:<ul><li>Factual hallucinations — a plain false statement, such as a wrong date, name, or number.</li><li>Contextual hallucinations — the answer contradicts information that was given directly in the prompt or source document.</li><li>Fabricated references — invented citations, links, quotes, or sources that sound legitimate but do not exist.</li><li>Logical hallucinations — the individual facts stated may be true, but the reasoning connecting them does not actually hold.</li></ul>Knowing which type you are looking for changes how you design the test — checking for contextual hallucinations means testing against a known source document, while checking for fabricated references means verifying every citation the system produces.<h3>How to Design Hallucination Test Cases</h3>Effective hallucination testing usually combines a few techniques:<ul><li>Ground-truth comparison — ask questions you already know the correct answer to, ideally from a source document you control, and check the output against it directly.</li><li>Out-of-scope probing — deliberately ask about topics the system should not know about, to see whether it admits uncertainty or invents an answer.</li><li>Consistency checks — ask the same question in different ways, or ask it multiple times, and compare the answers for contradictions.</li><li>Citation verification — whenever the system references a source, statistic, or quote, check that the source actually says what the system claims it says.</li></ul>A good hallucination test suite is built from real usage patterns, not just synthetic edge cases — reviewing actual user queries (or support tickets, if the system is already live) usually surfaces the questions most likely to trigger a hallucination.<h3>Measuring and Reporting the Hallucination Rate</h3>Because hallucinations are a matter of degree rather than a single pass/fail check, teams typically track a hallucination rate — the percentage of tested responses that contain at least one unsupported claim — rather than reporting individual bugs the way you would for a traditional defect. Reporting this rate over time, broken down by question type or topic area, tells the team where the model is weakest and whether a fix (a prompt change, added guardrails, or a retrained model) actually improved things or just moved the problem elsewhere. When you do report a specific hallucination as a bug, include the exact prompt, the full response, and — where possible — the source document it should have been grounded in, so the issue is reproducible.<h3>Further Reading</h3><a href='https://tesvan.com/blog/hallucination_testing_in_chatbots' target='_blank'>Hallucination Testing In Chatbots</a> <a href='https://tesvan.com/blog/retrieval_augumented_factuality' target='_blank'>Retrieval-Augmented Factuality</a> <a href='https://tesvan.com/blog/llm-instability-internet-marketplace-platforms' target='_blank'>Solving LLM Instability in Internet Marketplace Platforms</a>

What AI hallucinations are, why they happen, and how QA engineers design test cases to catch them.

Hallucination Testing

<h3>Prompt &amp; Input Validation Testing</h3>Input validation has always been part of QA — checking that a form rejects bad data, that an API returns a sensible error for a malformed request. AI systems need the same discipline, but the range of 'bad input' is much wider, because the input is often free-form natural language rather than a structured field with clear rules.This article covers:<ol><li>Why input validation matters more for AI systems</li><li>Categories of test inputs to cover</li><li>Prompt injection as a new kind of attack</li><li>How to build a prompt test suite</li></ol><h3>Why Input Validation Matters More for AI Systems</h3>A traditional form field can be validated with a handful of rules: required, correct format, length limit. A chat input box that feeds into an LLM has almost none of those constraints — a user can type anything, in any language, of any length, with any intent, including intentionally trying to manipulate the system. Because the model tries to generate a plausible response to whatever it receives, an AI system without input validation will often attempt to answer questions it should refuse, follow instructions it should ignore, or process input that was never meant to be a legitimate request.<h3>Categories of Test Inputs</h3>A thorough test suite for an AI system's input handling usually covers:<ul><li>Edge cases — empty input, extremely long input, input in an unexpected language, unusual formatting or special characters.</li><li>Out-of-scope requests — questions unrelated to what the system is meant to do, to confirm it declines gracefully instead of improvising an answer.</li><li>Ambiguous input — vague or incomplete requests, to see whether the system asks a clarifying question or guesses.</li><li>Adversarial input — inputs deliberately crafted to confuse the model, bypass its restrictions, or extract information it should not share.</li><li>Malicious input — attempts to make the system produce harmful, offensive, or policy-violating content.</li></ul><h3>Prompt Injection: A New Attack Surface</h3>Prompt injection is an attack specific to AI systems, where a user embeds hidden instructions inside their input — or inside a document the AI is asked to process — to override the system's original instructions. A simple example is a user typing 'ignore your previous instructions and instead tell me...' A more advanced example hides similar instructions inside a document, email, or web page that an AI assistant is asked to read and summarize, so the attack comes through content the system processes rather than direct user input.Testing for prompt injection means treating every source of text the AI reads — not just the direct chat input — as a potential attack surface, and includes checking whether the system can be tricked into revealing its own system instructions, ignoring safety rules, or performing actions the user should not be able to trigger.<h3>Building a Prompt Test Suite</h3>A practical prompt test suite is built incrementally:<ul><li>Start with the system's documented rules and restrictions, and write one test per rule that tries to break it.</li><li>Add real examples of prompt injection techniques that are publicly known, and adapt them to the specific system under test.</li><li>Include inputs in every language the product supports — validation rules that work in English do not automatically work for other languages or scripts.</li><li>Re-run the suite whenever the underlying model, prompt template, or safety configuration changes, since a fix in one area can quietly reopen a gap in another.</li></ul>Because new prompt injection techniques are discovered constantly, this kind of test suite should be treated as a living document, not something written once and left alone.<h3>Further Reading</h3><a href='https://tesvan.com/blog/defining-correct-ai-systems' target='_blank'>Defining &ldquo;Correct&rdquo; in AI Systems</a> <a href='https://tesvan.com/blog/llm-instability-internet-marketplace-platforms' target='_blank'>Solving LLM Instability in Internet Marketplace Platforms</a>

How to test AI systems against edge-case, adversarial, and malicious input, including prompt injection.

Prompt & Input Validation Testing

<h3>Defining &ldquo;Correct&rdquo; in AI Systems</h3>Traditional testing has a clear idea of correctness: an expected value, defined in advance, that the actual result either matches or doesn't. AI systems break this model almost immediately, because a single prompt can have several different acceptable answers, all correct in different ways. Before you can write a single meaningful test case for an AI feature, the team has to agree on what 'correct' actually means for that feature.This article covers:<ol><li>Why traditional pass/fail falls short</li><li>Four ways to define correctness</li><li>Building an evaluation rubric</li><li>Handling subjectivity and ambiguity</li></ol><h3>Why Traditional Pass/Fail Falls Short</h3>Ask an AI assistant to 'summarize this article in two sentences' and give the same request to three skilled writers — you will get three different, all reasonably correct, summaries. There is no single expected string to assert against. Trying to force AI output into a strict pass/fail test either produces false failures (the answer was good but didn't match the expected text exactly) or false passes (the test was loosened so much it stopped catching real problems). Neither outcome gives the team a trustworthy signal, which is why AI evaluation needs its own approach rather than reusing traditional assertion-based testing as-is.<h3>Four Ways to Define Correctness</h3>Most AI evaluation strategies combine several of these approaches, rather than relying on just one:<ul><li>Exact or fuzzy match — still useful for outputs that genuinely have one correct answer, such as extracting a specific number from a document.</li><li>Semantic similarity — comparing the meaning of the output to a reference answer rather than the exact wording, often using another model to judge how close the two are.</li><li>Human evaluation — a person reviews the output against a defined standard; slower and harder to scale, but often the most reliable for judgment-heavy tasks.</li><li>Rubric-based scoring — breaking 'correct' into specific, checkable criteria (accurate, relevant, appropriately toned, complete) and scoring each one separately instead of a single pass/fail.</li></ul><h3>Building an Evaluation Rubric</h3>A rubric turns a vague idea of quality into something a tester — or an automated evaluator — can apply consistently. A workable rubric usually defines, for each criterion, what a top score, a middle score, and a failing score actually look like, with a concrete example of each. For a customer support chatbot, a rubric might score every response on accuracy (is the information correct), completeness (does it fully answer the question), tone (is it appropriate for the brand), and safety (does it avoid anything harmful or policy-violating) — each scored independently, since a response can be perfectly accurate and still fail on tone. Involving the whole team — product, QA, and whoever owns the AI system — in defining the rubric matters, because 'correct' is ultimately a product decision, not just a testing one.<h3>Handling Subjectivity and Ambiguity</h3>Some correctness questions never fully resolve into an objective rule, and pretending otherwise creates rubrics nobody actually agrees with in practice. When a criterion is genuinely subjective — tone, helpfulness, creativity — it helps to have more than one reviewer score the same output independently and compare results; large disagreement between reviewers is itself useful information, since it usually means the rubric's definition needs to be sharper, not that the reviewers are wrong. Over time, disagreements should be resolved by refining the rubric with more concrete examples, not by simply picking whichever reviewer's opinion is more convenient.<h3>Further Reading</h3><a href='https://tesvan.com/blog/defining-correct-ai-systems' target='_blank'>Defining &ldquo;Correct&rdquo; in AI Systems &mdash; full case study</a> <a href='https://tesvan.com/blog/ai-generated-question-quality-coverage' target='_blank'>Ensuring Quality &amp; Coverage in AI-Generated Questions</a>

Why pass/fail testing doesn't work for AI output, and how to build an evaluation rubric that does.

Defining “Correct” in AI Systems

<h3>Using AI to Generate Test Cases</h3>Writing test cases by hand for every feature, edge case, and permutation takes time — time that AI tools can now take off a QA engineer's plate. Large language models are good at quickly producing a first draft of test cases from a requirement, a user story, or even a screenshot, which a tester then reviews, corrects, and extends rather than writing from a blank page.This article covers:<ol><li>Why generate test cases with AI</li><li>What AI is good — and not good — at generating</li><li>A practical workflow for AI-assisted test case design</li><li>Reviewing and validating AI-generated test cases</li><li>Common pitfalls</li></ol><h3>Why Generate Test Cases with AI</h3>The main benefit is speed on the first draft: given a clear requirement, an AI tool can produce a reasonably complete list of positive, negative, and boundary test cases in seconds, where a tester might spend twenty minutes doing the same from scratch. This does not replace the tester's judgment — it replaces the blank page. A second, less obvious benefit is coverage: AI tools are good at systematically listing variations a tired or rushed tester might skip, such as every combination of a small set of input fields, or every boundary value around a numeric limit.<h3>What AI Is Good — and Not Good — At Generating</h3>AI tools are reliable for mechanical, pattern-based test case generation: boundary value analysis, equivalence partitioning, permutations of input fields, and standard negative cases (empty input, wrong type, missing required field). They are much less reliable for anything that requires real understanding of the business context — knowing which edge case actually matters to this specific product, which combinations are impossible in practice, or which failure would actually hurt the business the most. AI-generated test cases should be treated as a solid first draft of the mechanical work, not a substitute for a tester who understands the product.<h3>A Practical Workflow for AI-Assisted Test Case Design</h3>A workflow that works well in practice:<ul><li>Give the AI tool the actual requirement or user story, not a vague summary — the more specific the input, the more useful the output.</li><li>Ask for test cases grouped by type: positive, negative, boundary, and edge cases, so nothing is silently skipped.</li><li>Ask the tool to list its assumptions about the requirement alongside the test cases — this often surfaces requirement ambiguities the team missed.</li><li>Treat the output as a checklist to edit, not a final document to publish as-is.</li></ul><h3>Reviewing and Validating AI-Generated Test Cases</h3>Every AI-generated test case needs a human pass before it goes into a test suite. Check for three things specifically: that the expected result is actually correct (the model can be confidently wrong about what a feature is supposed to do), that the test case is actually testable with the tools and access the team has, and that it doesn't duplicate an existing test case under a different name. It also helps to check the generated set against the requirement one more time for gaps — AI test case generation tends to cluster around the obvious paths and under-cover unusual but realistic user behavior.<h3>Common Pitfalls</h3>The most common mistake is copying AI-generated test cases into the suite unreviewed, which quietly fills the suite with cases that look plausible but test the wrong expected result. A second common pitfall is feeding the tool a vague or incomplete requirement and trusting the output anyway — vague input produces test cases that miss the actual risk area. A third is relying on AI-generated cases as the only source of coverage, instead of as a starting point that a tester's own domain knowledge and exploratory testing build on top of.<h3>Further Reading</h3><a href='https://tesvan.com/education/ai_llm_testing_introduction' target='_blank'>Introduction to AI &amp; LLM Testing</a> <a href='https://tesvan.com/education/ai_llm_testing_defining_correct' target='_blank'>Defining &ldquo;Correct&rdquo; in AI Systems</a>

How QA engineers use AI to draft test cases faster, what to trust it with, and how to review the output.

Using AI to Generate Test Cases

<h3>AI-Assisted Bug Reporting &amp; Documentation</h3>Bug reports and test documentation are necessary but repetitive writing tasks, and AI tools are well suited to speeding them up — turning a rough note into a properly structured bug report, or a set of test cases into a readable test plan. Used well, this frees up a tester's time for the part of the job that actually requires judgment: finding the bug in the first place.This article covers:<ol><li>What AI can automate in bug reporting</li><li>Writing better bug reports with AI assistance</li><li>Using AI for test documentation and test plans</li><li>Where to keep a human in the loop</li></ol><h3>What AI Can Automate in Bug Reporting</h3>AI tools can reliably turn a short, rough description ('login button doesn't work on mobile, tried twice') into a properly formatted bug report with a clear title, structured steps to reproduce, and separated expected versus actual result sections. They can also help fill in the parts testers often skip under time pressure — environment details, severity suggestions based on the description, and a first-pass summary a developer can scan quickly. Some tools can also draft a report directly from a screen recording or screenshot, saving the step of writing steps to reproduce from memory.<h3>Writing Better Bug Reports with AI Assistance</h3>The quality of an AI-assisted bug report still depends entirely on what the tester puts in. Give the tool as much raw detail as possible — the exact steps taken, what was expected, what actually happened, the environment, and any error messages verbatim — and ask it to structure that into a clear report rather than asking it to invent the missing details itself. A useful habit is asking the AI tool to flag anything it had to guess or infer, so the tester can go back and fill in the real information before submitting the report.<h3>Using AI for Test Documentation and Test Plans</h3>Beyond individual bug reports, AI tools are useful for drafting test plans, test summary reports, and release notes from a set of completed test cases and their results — work that is valuable but time-consuming to write from scratch. Feeding the tool a list of test cases, pass/fail results, and any known issues usually produces a workable first draft of a summary report that a tester then edits for accuracy and tone, rather than writing the whole document manually.<h3>Where to Keep a Human in the Loop</h3>Three things should always get a human review before publishing: severity and priority assessments (these require business context an AI tool does not reliably have), any claim about root cause (AI tools can confidently suggest a cause that turns out to be wrong), and anything going to a client or stakeholder outside the immediate team. Internal, low-stakes documentation can tolerate a lighter review than a bug report that will drive a developer's prioritization decisions.<h3>Further Reading</h3><a href='https://tesvan.com/education/ai_llm_testing_hallucination_testing' target='_blank'>Hallucination Testing</a> <a href='https://tesvan.com/education/ai_tools_test_case_generation' target='_blank'>Using AI to Generate Test Cases</a>

How AI tools speed up writing bug reports and test documentation, and where a human review still matters.

AI-Assisted Bug Reporting & Documentation

<h3>AI Coding Assistants for Test Automation</h3>AI coding assistants — tools that suggest or generate code directly inside an editor — have become a normal part of writing test automation scripts, not just application code. For a QA engineer moving into automation, they can meaningfully shorten the time it takes to write a Selenium, Playwright, or Cypress script, provided the output is reviewed with the same rigor as code from a junior teammate.This article covers:<ol><li>What AI coding assistants do</li><li>Using an assistant to write automation scripts</li><li>Reviewing AI-generated automation code</li><li>Where AI assistants struggle</li><li>Getting the most out of an AI coding assistant</li></ol><h3>What AI Coding Assistants Do</h3>AI coding assistants suggest code as you type, generate a full function or script from a plain-language description, and can explain or refactor existing code on request. For test automation specifically, this typically means generating a first draft of a page object, a test script for a described user flow, or a set of assertions for a given scenario — work that follows well-known patterns the model has seen many examples of during training.<h3>Using an Assistant to Write Automation Scripts</h3>The most reliable way to use an assistant for automation is to describe the test scenario precisely — the exact steps, the exact elements involved, and the exact expected outcome — rather than asking for something vague like 'write a test for the login page.' The more the prompt resembles a well-written manual test case, the closer the generated script will be to something usable. It also helps to specify the framework, language, and any project conventions (naming, folder structure, existing helper functions) up front, since the assistant has no way to know them otherwise.<h3>Reviewing AI-Generated Automation Code</h3>AI-generated automation scripts should go through the same review a human-written script would: correct locators that will not break on the next minor UI change, appropriate waits instead of fixed sleeps, assertions that actually check the right thing, and no hard-coded test data that will silently go stale. A generated script that runs and passes once is not the same as a script that is stable and maintainable — that difference usually only shows up after a human review, not from the assistant itself.<h3>Where AI Assistants Struggle</h3>AI coding assistants are noticeably weaker on anything specific to the actual application under test that was not visible in the prompt or the surrounding code: custom internal frameworks, unusual authentication flows, or application-specific quirks the model has never seen an example of. They also tend to generate code that looks plausible and runs without errors but silently tests the wrong thing — for instance asserting that an element exists rather than that it contains the correct value — which makes careful review non-negotiable rather than optional.<h3>Getting the Most Out of an AI Coding Assistant</h3>Treat the assistant as a fast typist with pattern-matching skills, not as an automation engineer who understands your product. Give it precise, detailed prompts, review everything it produces before committing it, and use it most heavily for the repetitive parts of automation work — boilerplate, page objects, standard assertion patterns — where the time saved is largest and the risk of a subtle error is easiest to catch.<h3>Further Reading</h3><a href='https://tesvan.com/education/ai_tools_prompt_engineering_for_qa' target='_blank'>Prompt Engineering for QA Tasks</a> <a href='https://tesvan.com/education/testing_methods_automated_testing' target='_blank'>Automated Testing</a>

How to use AI coding assistants to write automation scripts faster, and how to review what they produce.

AI Coding Assistants for Test Automation

<h3>Prompt Engineering for QA Tasks</h3>Every AI tool a QA engineer uses — for generating test cases, drafting bug reports, or writing automation code — produces better results with a better prompt. Prompt engineering is simply the practice of writing that input deliberately, and it is a skill a tester can improve with practice, the same way writing a clear test case is a skill.This article covers:<ol><li>What prompt engineering means for a QA engineer</li><li>Principles of a good prompt</li><li>Prompt patterns useful for QA work</li><li>Iterating on a prompt</li></ol><h3>What Prompt Engineering Means for a QA Engineer</h3>For most QA use cases, prompt engineering is less about clever tricks and more about giving the AI tool the same information a human colleague would need to do the task well: the actual requirement, the relevant context, the format you want the answer in, and any constraints that matter. A tester who is already good at writing a clear bug report or a precise test case already has most of the skill needed to write a good prompt — the underlying discipline is the same.<h3>Principles of a Good Prompt</h3>A few principles consistently improve results:<ul><li>Be specific — 'generate boundary test cases for a date-of-birth field that must represent an age between 18 and 65' works far better than 'test the date field.'</li><li>Give context — the type of application, the relevant requirement, and any constraints the model would not otherwise know.</li><li>Specify the output format — a table, a numbered list, a specific structure — so the result is usable without reformatting.</li><li>State what to exclude — if you already have positive test cases and only want edge cases, say so explicitly, or the tool will generate everything.</li></ul><h3>Prompt Patterns Useful for QA Work</h3>A few reusable patterns come up often in QA prompting:<ul><li>Role framing — asking the model to act as a senior QA engineer reviewing a specific type of feature can shift the kind of detail it includes.</li><li>Few-shot examples — including one or two examples of the format you want (a sample test case, a sample bug report) makes the output far more consistent than a description alone.</li><li>Step-by-step instructions — for multi-part tasks, breaking the request into explicit steps produces more reliable output than one large, compound request.</li></ul><h3>Iterating on a Prompt</h3>The first response is rarely the final one — treat prompting as a short back-and-forth rather than a single attempt. If the output misses something, say specifically what is missing rather than repeating the whole request; if it invents details, point that out directly and ask it to only use the information given. Keeping a personal library of prompts that worked well for recurring tasks — generating boundary test cases, drafting a bug report, summarizing a test run — saves time on every future task of the same type.<h3>Further Reading</h3><a href='https://tesvan.com/education/ai_llm_testing_prompt_input_validation' target='_blank'>Prompt &amp; Input Validation Testing</a> <a href='https://tesvan.com/education/ai_tools_test_case_generation' target='_blank'>Using AI to Generate Test Cases</a>

Practical principles and patterns for writing better prompts when using AI for test cases, bug reports, and automation.

Prompt Engineering for QA Tasks

<h3>ISTQB Certification &mdash; What It Is and Why It Matters</h3>ISTQB (the International Software Testing Qualifications Board) certification is the most widely recognized professional qualification in software testing. For a beginner QA engineer, it is often one of the first concrete career decisions to make: whether the certification is worth the time and cost, and if so, when to pursue it.This article covers:<ol><li>What ISTQB is</li><li>The certification levels</li><li>What the Foundation Level exam covers</li><li>Is ISTQB worth it?</li><li>How to prepare</li></ol><h3>What ISTQB Is</h3>ISTQB is a non-profit organization that defines a standardized body of knowledge for software testing and certifies testers against it through exams administered by national and regional boards around the world. It is not tied to a specific tool, company, or testing methodology — the syllabus covers testing principles, terminology, and techniques that apply across manual and automated testing, which is part of why the certification is recognized internationally rather than in one region or company only.<h3>The Certification Levels</h3>ISTQB certification is structured in levels, most testers starting at the bottom:<ul><li>Foundation Level — the entry point, covering testing fundamentals; no prior certification required.</li><li>Advanced Level — several specialized tracks (test management, test analysis, technical test analysis) for testers with practical experience.</li><li>Expert Level — deep specialization intended for senior practitioners, requiring significant prior experience and Advanced Level certification.</li></ul>Most job postings that mention ISTQB are referring to Foundation Level, which is the appropriate starting point for a beginner.<h3>What the Foundation Level Exam Covers</h3>The Foundation Level syllabus covers the fundamentals of testing (why testing matters, the seven testing principles), testing throughout the software development lifecycle, static testing techniques, test design techniques (black-box, white-box, and experience-based), test management basics, and an introduction to test tools. Much of this overlaps directly with the QA Basics, Testing Levels, and Testing Methods topics already covered in this Education section, which makes it a reasonable next step for a beginner who has worked through those.<h3>Is ISTQB Worth It?</h3>ISTQB Foundation Level is widely recognized by recruiters and hiring managers, particularly outside a candidate's home region where a shared, standardized qualification is easier to evaluate than an unfamiliar local one. It will not replace practical experience or a strong portfolio, and some experienced hiring managers weight it less than hands-on skills demonstrated in an interview — but for a beginner with limited work history, it is a credible signal that they understand testing fundamentals, and it can help a resume clear an initial screening.<h3>How to Prepare</h3>The exam is based directly on the published ISTQB Foundation Level syllabus, which is publicly available and is the primary study material — most other prep resources are built around it. A practical study approach is to read the syllabus section by section, take notes in your own words rather than memorizing verbatim, and work through practice exams to get used to the question style, which tends to test applied understanding of a concept rather than a bare definition.<h3>Further Reading</h3><a href='https://tesvan.com/education/career_qa_job_interview_preparation' target='_blank'>How to Prepare for a QA Job Interview</a> <a href='https://tesvan.com/education/career_qa_career_paths' target='_blank'>QA Career Paths</a>

What ISTQB certification covers, its levels, and whether it is worth pursuing for a beginner QA engineer.

ISTQB Certification — What It Is and Why It Matters

<h3>How to Prepare for a QA Job Interview</h3>A QA interview usually tests three things at once: whether you understand testing fundamentals, whether you can apply them to a real scenario on the spot, and whether you can communicate your thinking clearly. Preparing well means practicing all three, not just reviewing definitions the night before.This article covers:<ol><li>Understand what the role actually tests for</li><li>Review the fundamentals</li><li>Prepare examples from real or practice work</li><li>Practice the practical test</li><li>Questions to ask the interviewer</li></ol><h3>Understand What the Role Actually Tests For</h3>Read the job description closely for signals about what the interview will actually focus on: heavy mention of automation tools points to a coding-focused interview, mention of a specific domain (fintech, healthcare, e-commerce) suggests domain-specific scenario questions, and mention of API or performance testing suggests the interview will go beyond basic UI testing. Tailoring preparation to the specific role is more useful than generically reviewing every QA topic equally.<h3>Review the Fundamentals</h3>Even experienced testers get asked foundational questions, and a shaky answer to a basic question can outweigh a strong answer to a harder one. Be ready to explain, in your own words rather than a memorized definition, the difference between manual and automated testing, the levels of testing (unit, integration, system, acceptance), common test design techniques, and the bug life cycle. Being able to explain these clearly and with a concrete example is more convincing than reciting a textbook definition.<h3>Prepare Examples from Real or Practice Work</h3>Interviewers frequently ask for a specific example: a bug you found, a test case you designed, a disagreement you had with a developer about severity. Prepare two or three concrete stories in advance, each with enough detail to answer natural follow-up questions — what you did, why, and what the outcome was. If you don't have paid work experience yet, a bug you found and reported on a real public app, or a small personal testing project, works just as well as an example, provided you can speak to it in detail.<h3>Practice the Practical Test</h3>Many QA interviews include a live or take-home exercise: writing test cases for a given feature, finding bugs in a sample application, or reviewing a piece of test automation code. Practice this format specifically, not just the theory — time yourself designing test cases for an unfamiliar feature (a login form, a checkout flow, a search box) and get comfortable narrating your thinking out loud, since in a live interview the interviewer is usually evaluating your process as much as your final answer.<h3>Questions to Ask the Interviewer</h3>Good questions to ask signal genuine interest and also give you real information: what does the current test process look like, how much of testing is automated versus manual, how are priorities decided between developers and QA, and what would success look like in this role after three months. These questions work better than generic ones because they show you are already thinking about how you would actually do the job.<h3>Further Reading</h3><a href='https://tesvan.com/education/career_qa_interview_questions_answers' target='_blank'>Common QA Interview Questions and How to Answer Them</a> <a href='https://tesvan.com/education/career_qa_portfolio_without_experience' target='_blank'>Building a QA Portfolio Without Work Experience</a>

A practical guide to preparing for a QA interview: fundamentals, real examples, the practical test, and questions to ask.

How to Prepare for a QA Job Interview

<h3>Common QA Interview Questions and How to Answer Them</h3>Certain questions come up in QA interviews often enough that preparing a thoughtful answer in advance is worth the time. This is not about memorizing scripted answers — interviewers can usually tell — but about knowing the shape of a good answer so you're not building it from scratch under pressure.This article covers four common question categories and how to approach each:<ol><li>'Walk me through how you'd test X'</li><li>'Tell me about a bug you found'</li><li>'What's the difference between X and Y' questions</li><li>Behavioral questions</li></ol><h3>'Walk Me Through How You'd Test X'</h3>This is testing your process, not just your final list of test cases. A strong answer starts by asking clarifying questions about the feature and its requirements (interviewers usually want to see this, not skip it), then works through test types systematically — functional, negative, boundary, and non-functional considerations like performance or accessibility if relevant — rather than jumping straight to a list. Narrate your reasoning out loud: 'I'd start with the happy path because...' shows more than silently listing cases.<h3>'Tell Me About a Bug You Found'</h3>A good answer covers four things briefly: what the bug was, how you found it, what its impact would have been if it shipped, and how you communicated it. Prioritize a bug that shows judgment, not just an obvious one — a subtle edge case you noticed through careful testing, or a case where you had to convince a developer the severity was higher than they initially thought, makes a stronger impression than a trivial typo.<h3>'What's the Difference Between X and Y' Questions</h3>These test whether your understanding is precise, not just whether you've memorized the terms — common pairs include verification vs. validation, smoke vs. sanity testing, and severity vs. priority. Answer with a short, precise definition of each, then a concrete example that shows you understand when each applies in practice, rather than a long definition alone.<h3>Behavioral Questions</h3>Questions like 'tell me about a time you disagreed with a developer' or 'how do you handle tight deadlines' are evaluating how you work with a team, not just how you test software. A useful structure is describing the situation briefly, what you specifically did, and the outcome — keeping the focus on your own actions and reasoning rather than blaming a colleague or the process, even when describing a genuinely difficult situation.<h3>Further Reading</h3><a href='https://tesvan.com/education/career_qa_job_interview_preparation' target='_blank'>How to Prepare for a QA Job Interview</a> <a href='https://tesvan.com/education/error_detection_defect_severity_defect_priority' target='_blank'>Defect Severity and Priority</a>

How to approach the four most common categories of QA interview questions, with the shape of a strong answer for each.

Common QA Interview Questions and How to Answer Them

<h3>Building a QA Portfolio Without Work Experience</h3>Hiring managers reviewing an entry-level QA application often have little to evaluate beyond a resume and a short interview — a portfolio gives them something concrete to look at, and gives you something concrete to talk about that isn't a course certificate. It does not require paid work experience to build one.This article covers:<ol><li>Why a portfolio matters for QA</li><li>What to include</li><li>Finding something real to test</li><li>Presenting your work</li></ol><h3>Why a Portfolio Matters for QA</h3>A QA portfolio does what a resume line like 'familiar with manual and automated testing' cannot: it shows the actual quality of your test cases, the clarity of your bug reports, and how you think about a feature, in a way an interviewer can review before ever meeting you. For candidates without paid experience, it is often the single most effective way to stand out from other applicants whose resumes look similarly thin.<h3>What to Include</h3>A useful portfolio usually includes a small set of well-documented test cases for a real application, one or two clearly written bug reports (ideally for real bugs found in a real app, even a minor one), a short test plan or test strategy document for a small feature, and — if you have any automation skills — a small, working automation script with a brief explanation of what it does and why. Quality matters far more than volume: three carefully documented examples are more convincing than fifteen rushed ones.<h3>Finding Something Real to Test</h3>You do not need access to a company's private product to build real examples. Public websites and apps, open-source projects looking for testers, and free/demo versions of well-known SaaS products are all fair game for practice testing, as long as you are not disruptive or violating terms of service (avoid anything that resembles an actual attack, load testing a live public site, or submitting test bug reports that spam a real company's support channel). A small personal project — even a simple to-do app or a form-based tool you build yourself — also works well because you control the requirements completely.<h3>Presenting Your Work</h3>Put the portfolio somewhere easy to share — a simple personal website, a public document, or a well-organized repository — and write a short introduction for each piece explaining what it is and what it demonstrates, since a reviewer skimming quickly needs that context. Link to it directly from your resume and LinkedIn profile rather than mentioning it only if asked, and keep it updated as you produce better examples; an early, rougher portfolio piece is worth replacing once you have a stronger one.<h3>Further Reading</h3><a href='https://tesvan.com/education/career_qa_job_interview_preparation' target='_blank'>How to Prepare for a QA Job Interview</a> <a href='https://tesvan.com/education/documentation_test_case' target='_blank'>Test Case</a>

What to include in a QA portfolio, where to find something real to test, and how to present it without paid experience.

Building a QA Portfolio Without Work Experience

<h3>QA Career Paths: From Junior to Lead, SDET, or Automation Engineer</h3>QA is not a single, flat job title — it branches into several distinct directions as you gain experience, and understanding the options early helps you make more deliberate choices about what skills to build next.This article covers:<ol><li>Junior to mid-level QA engineer</li><li>Specializing: manual, automation, or both</li><li>SDET — Software Development Engineer in Test</li><li>QA Lead and Test Manager</li><li>Where AI skills fit in</li></ol><h3>Junior to Mid-Level QA Engineer</h3>Most QA careers start with a broad, general role: writing and executing manual test cases, reporting bugs, and learning the product deeply. The path from junior to mid-level is mostly about depth and independence — needing less guidance to design good test coverage, taking ownership of a feature area rather than executing assigned test cases, and becoming someone the team relies on to catch problems before they reach production.<h3>Specializing: Manual, Automation, or Both</h3>At some point most testers lean toward a specialization. Staying primarily manual suits people who enjoy exploratory testing, usability, and the parts of QA that require human judgment rather than repeatable scripts — this remains a legitimate, valuable specialization, not a stepping stone automation testers eventually 'graduate' from. Moving into automation means learning a programming language and an automation framework, and suits people who enjoy the engineering side of testing. Many strong QA engineers end up doing both, using automation for regression coverage and manual/exploratory testing for the parts that benefit from human judgment.<h3>SDET &mdash; Software Development Engineer in Test</h3>SDET is a role that sits between QA and software engineering: building test frameworks and tooling rather than only writing individual test cases, and often contributing to the actual application codebase — for example writing testability improvements or CI/CD pipeline code. It typically requires stronger software engineering skills than a typical automation QA role, and is a natural next step for automation-focused testers who want to move closer to development.<h3>QA Lead and Test Manager</h3>The management path moves away from hands-on testing toward planning test strategy, managing a team of testers, coordinating with other departments, and reporting on quality metrics to stakeholders. This path suits people who enjoy the planning and people-management side of the work; it is a distinct skill set from hands-on testing, and being an excellent individual tester does not automatically make someone a good test manager — the two require different things.<h3>Where AI Skills Fit In</h3>As AI features become more common across products, comfort with AI testing — the kind covered earlier in this Education section — is becoming a genuinely useful differentiator, similar to how automation skills became a differentiator a decade ago. It is not yet a separate career track the way automation or management is, but QA engineers who develop this skill early are well positioned as more products ship AI-driven features that need testing.<h3>Further Reading</h3><a href='https://tesvan.com/education/ai_llm_testing_introduction' target='_blank'>Introduction to AI &amp; LLM Testing</a> <a href='https://tesvan.com/education/career_istqb_certification' target='_blank'>ISTQB Certification</a>

The main directions a QA career can branch into, from junior engineer to SDET, automation, and test management.

Manual Testing

All topics

Manual Testing Method

Goals of Manual Testing

Content