This is a free module from my course ISTQB CTAL Technical Test Analyst revised to 2012 syllabus. If you need full training feel free to contact me by email (amraldo@hotmail.com) or by mobile (+201223600207).
Role Of Qa And Testing In Agile 1225221397167302 8a34sharm
The document discusses the role of QA and testing in agile software development, describing key differences between traditional and agile testing approaches and outlining agile testing practices like test-driven development, continuous integration, regression testing, and exploratory testing. It also covers the role of testers in agile projects and provides an example of how one company, GlobalLogic, implements agile testing through a unique Velocity method and platform.
The document provides an agenda for Day 2 of an ISTQB Foundation Level training which includes the following topics: test design techniques like test analysis, test design, equivalence partitioning, boundary value analysis, use case testing and experience-based testing. It also discusses test management topics like test leader and tester roles and responsibilities, test plan vs test strategy, estimation techniques, configuration management, risk based testing, exploratory testing and defect management. The last sections provide overviews of tool support for testing and an exercise on classifying different types of triangles based on side lengths.
This document discusses test automation approaches and best practices. It defines test automation as using software to perform test activities like execution and checking results. The document outlines how test automation fits into the software development lifecycle and notes that reducing manual testing and redundant tasks is key to success. It also discusses factors to consider for test automation, types of tests that can be automated, and technologies used for test automation like object-based and image-based recognition.
Chapter 4 - Quality Characteristics for Technical TestingNeeraj Kumar Singh
The document discusses quality characteristics for technical testing, focusing on reliability testing. It provides definitions and explanations of reliability sub-characteristics like maturity, fault tolerance, and recoverability. It describes approaches to measuring software maturity and reliability over time. Types of reliability tests discussed include fault tolerance testing, recoverability (failover and backup/restore) testing, and availability testing. General guidance is provided on planning and specifying reliability tests, noting the need for production-like environments and long test durations to obtain statistically significant results.
The document discusses fundamentals of software testing including definitions of testing, why testing is necessary, seven testing principles, and the test process. It describes the test process as consisting of test planning, monitoring and control, analysis, design, implementation, execution, and completion. It also outlines the typical work products created during each phase of the test process.
This is chapter 6 of ISTQB Advance Technical Test Analyst certification. This presentation helps aspirants understand and prepare the content of the certification.
The document discusses QA best practices in an Agile development environment. It describes key aspects of Agile like iterative delivery, self-organizing teams, and rapid feedback. It addresses challenges of fitting QA into short iterations and questions around testing approaches. The document advocates for testing to be collaborative, automated, and continuous throughout development. It provides recommendations for QA roles in activities like planning, stand-ups, retrospectives and acceptance testing. Overall it promotes testing practices in Agile that focus on early feedback, automation, and involvement of QA throughout the development process.
There are many types of tools that support testing across the entire software development lifecycle. While automation can help improve testing, automating and testing require separate skills. Effective use of tools requires identifying the appropriate tests to automate through planning and effort, while maintaining control over the test automation process. Tools should support requirements testing, static analysis, test design, test data preparation, test execution, comparison, debugging, and test management.
Test Case Design Techniques as chapter 4 of ISTQB Foundation. Topics included are Equivalence Partition, Boundary Value Analysis, State Transition Testing, Decision Table Testing, Use Case Testing, Statement Coverage, Decision Coverage, Error Guessing, Exploratory Testing, Checklist Based Testing
The document provides an overview of dynamic testing techniques used in software testing. It discusses black box and white box testing approaches and some common techniques used, including equivalence partitioning, boundary value analysis, decision tables, statement coverage, and branch/decision coverage. The techniques help testers select test cases in a more systematic and thorough manner to effectively find software faults.
This document provides guidelines for effective test automation at IBM Global Services. It discusses that automation is viewed as a silver bullet but can also frustrate if not implemented properly. The document recommends starting simple and increasing complexity as skills grow. It provides considerations for automation, such as tests that are long, repetitive, and non-subjective. The document outlines 10 guidelines for automation, including establishing standards, separating what from how, using a six phase process, and defining required skills. It also discusses functional decomposition and keyword-driven methodologies and provides an overview of automation tools.
Test Automation Frameworks: Assumptions, Concepts & ToolsAmit Rawat
The document discusses factors to consider when selecting a test automation framework. It describes how there are many options for frameworks available and outlines important criteria to evaluate, such as flexibility, ability to support different applications and interfaces, tool and language independence, parallel execution, and design patterns. The presentation provides examples of different types of frameworks and discusses strategies for building frameworks that can scale and evolve with changing needs.
This document provides an overview and agenda for a presentation on automation testing using IBM Rational Functional Tester. It discusses what automation testing is, why it is useful, and when it should be implemented. It also addresses common myths about automation testing and provides tips for successful automation. Finally, it covers features of IBM Rational Functional Tester, including how to set up a test environment and record scripts to automate testing.
Test Automation Best Practices (with SOA test approach)Leonard Fingerman
Today we hear a lot of buzz about the latest & greatest test automation tools like Selenium, Rational Functional Tester or HP LoadRunner but to make your test automation effort successful it might take more than just having the right tool. This presentation will try to uncover major pitfalls typically involved with test automation efforts. It will provide guidance on successful strategy as well as differences among third-generation frameworks like keyword-driven, data-driven and hybrid. It will also cover various aspects of SOA test automation
This document provides information on test management based on the ISTQB (International Software Testing Qualifications Board) syllabus. It discusses the importance of independent testing, test planning, estimation strategies, test progress monitoring, configuration management, risk management, and reporting test status. Key aspects covered include organizing independent versus integrated test teams, factors to consider in test planning, estimation techniques, test strategies, and test leader and tester roles and responsibilities.
Chapter 3 of ISTQB Foundation 2018 syllabus with sample questions. Answers about what is static testing, what is review, types of review, informal review, walkthrough, technical review, inspection.
The document discusses test management for software quality assurance, including defining test management as organizing and controlling the testing process and artifacts. It covers the phases of test management like planning, authoring, execution, and reporting. Additionally, it discusses challenges in test management, priorities and classifications for testing, and the role and responsibilities of the test manager.
This document summarizes Rex Black's book on risk-based testing strategies. It discusses:
- The two main types of risks in testing: product risks related to quality, and project risks related to management and schedules.
- How risk-based testing guides testing activities based on identified risks, prioritizing higher-risk items and allocating more testing effort to them.
- The benefits of risk-based testing over requirements-based testing, like having a more predictable reduction in risk over time and the ability to intelligently reduce testing if needed.
- The history of risk-based testing strategies dating back to the 1980s, and how modern approaches aim to systematically analyze and address risks.
The document describes Modified Condition/Decision coverage (MC/DC), a technique for structural test coverage. MC/DC requires that each condition outcome independently affects the decision outcome at least once. It uses a "neutral value" that does not affect the decision. For AND operations the neutral value is 1, while for OR it is 0. The document provides examples of applying MC/DC to conditions with AND and OR operators connecting multiple variables to a decision.
This is a free module introducing embedded systems. It covers C programming, microcontrollers and software design in 40 ours. Its free for use in universities and institutes on condition of prior notification. Please, do not use it for commercial purposes. If you need full set If you need accompanying labs and software tool feel free to contact me by email (amraldo@hotmail.com) or by mobile (+201223600207).
MC/DC testing requires focusing test cases on each condition individually to cover all possible outcomes of that condition, which can be done with fewer test cases than full pairwise testing. It works by fixing all other conditions while toggling the focused condition, resulting in test cases that ensure each condition alone can correctly affect the final decision. When all individual condition test cases are combined, the total number of test cases is less than that required for pairwise testing, providing coverage with fewer tests.
This is a free module from my course ISTQB CTFL Agile Tester revised to 2014 syllabus. If you need full training feel free to contact me by email (amraldo@hotmail.com) or by mobile (+201223600207).
This document provides an overview of using the Isim simulator to simulate VHDL designs. It describes creating a new project in Xilinx ISE, writing VHDL code, checking for syntax errors, and performing an interactive simulation. The simulation involves forcing clock and constant inputs, zooming the waveform display, and viewing variables within processes. The overall objective is to learn the basic flow for using the Isim simulator to compile and simulate a VHDL design.
This document introduces the STM32 microcontroller. It will cover the ARM Cortex processor, the STM32 system-on-chip, and its basic building blocks. The course outline includes introductions to the Cortex architecture, CMSIS standard, STM32 system architecture, peripherals, low power operation, safety features, flash memory, and development tools.
This document discusses FPGA programming using Xilinx ISE 7.1i. It covers creating a project, importing HDL files, assigning FPGA pins, generating a programming file, and configuring and programming the FPGA device. The document also notes that the content is copyrighted but users are granted access for personal non-commercial use provided proprietary notices remain intact.
The document outlines an Android internals course that will teach students how to develop embedded systems using Google Android. The course objectives are to customize and install Android for target platforms. Prerequisites include experience with C/C++, basic Java, Linux command line, and optionally embedded systems development. The course will cover topics like the Android source code, compiling and booting Android kernels, supporting new boards, and using ADB for development and debugging. Labs will provide hands-on experience with these topics.
This is my complete introductory course for Software Test Automation.If you need full training that includes different automation tools (Selenium, J-Meter, Burp, SOAP UI etc), feel free to contact me by email (amraldo@hotmail.com) or by mobile (+201223600207).
This document discusses various types of software testing techniques used in the software development lifecycle (SDLC). It begins by describing different SDLC models like waterfall, prototyping, RAD, spiral and V-models. It then discusses the importance of testing at different stages of SDLC and different types of testing like static vs dynamic, black box vs white box, unit vs integration etc. The rest of the document elaborates on specific black box and white box testing techniques like equivalence partitioning, boundary value analysis, cause-effect graphing, statement coverage and basis path testing.
This document provides an introduction to embedded systems. It begins with defining what an embedded system is and listing some key characteristics such as reliability, efficiency, dedicated functions, and meeting real-time constraints. The document then covers embedded hardware topics like CPUs, processors, system on chips, memory, I/O devices, and buses. It also discusses embedded software including programming languages, operating systems, middleware, applications, and development models. The document concludes with an outline of the course and exercises for students.
This document provides an overview of software testing concepts and processes. It discusses the importance of testing in the software development lifecycle and defines key terms like errors, bugs, faults, and failures. It also describes different types of testing like unit testing, integration testing, system testing, and acceptance testing. Finally, it covers quality assurance and quality control processes and how bugs are managed throughout their lifecycle.
Testing is the process of identifying bugs and ensuring software meets requirements. It involves executing programs under different conditions to check specification, functionality, and performance. The objectives of testing are to uncover errors, demonstrate requirements are met, and validate quality with minimal cost. Testing follows a life cycle including planning, design, execution, and reporting. Different methodologies like black box and white box testing are used at various levels from unit to system. The overall goal is to perform effective testing to deliver high quality software.
20050314 specification based regression test selection with risk analysisWill Shen
This document describes a specification-based regression test selection technique with risk analysis. It selects targeted tests to cover changes in code or specifications, and safety tests directed by risk analysis. Safety tests are chosen using a risk exposure model factoring probability and cost of faults. Scenarios simulating user profiles are also selected based on their risk exposure covering critical test cases. The approach was evaluated on an IBM project and found effective, cost-efficient, and sensitive to risk. Future work includes determining when to stop testing and implementing the approach in a production environment.
Technical analysts believe stock prices follow predictable patterns that can be seen in historical price charts. However, academic research shows prices behave randomly and past prices cannot reliably predict future movements once transaction costs are considered. Many technical trading strategies do not outperform a simple buy and hold approach. While technical analysis remains popular, the evidence suggests its predictions contain no useful information.
Dear Engineering students please contact for GATE | IES | PSUs / SSC-JE Preparation..
ENGINEERING CAREER TUTORIAL (ECT)
JAIPUR. H L Rajora. Mob. 9413394182
www.iesect.in
Best Way to Prepare for the ISTQB Technical Test Analyst (CTAL-TTA) Certifica...Meghna Arora
Start Here---> http://bit.ly/2WtdgTj <---Get complete detail on CTAL-TTA exam guide to crack Technical Test Analyst. You can collect all information on CTAL-TTA tutorial, practice test, books, study material, exam questions, and syllabus. Firm your knowledge on Technical Test Analyst and get ready to crack CTAL-TTA certification. Explore all information on CTAL-TTA exam with the number of questions, passing percentage, and time duration to complete the test.
This is chapter 2 of ISTQB Advance Technical Test Analyst certification. This presentation helps aspirants understand and prepare the content of the certification.
[2012] Empirical Evaluation on FBD Model-Based Test Coverage Criteria using M...Donghwan Shin
Shin, Donghwan, Eunkyoung Jee, and Doo-Hwan Bae. Empirical evaluation on FBD model-based test coverage criteria using mutation analysis. Springer Berlin Heidelberg, 2012.
Test design techniques: Structured and Experienced-based techniquesKhuong Nguyen
This document discusses different types of software testing techniques, including structured-based techniques like cyclomatic complexity and statement/decision coverage, as well as experience-based techniques like error guessing and exploratory testing. It explains how to calculate cyclomatic complexity and coverage percentages. Choosing the appropriate testing technique depends on factors like system type, standards, requirements, risk level, documentation, tester knowledge, time and budget. Testing usually involves combining different techniques.
White-box testing is a software testing technique that uses knowledge of the internal workings of a system to design test cases. It involves testing internal structures or workings of a program, such as code coverage. The document discusses different white-box testing techniques like statement coverage, decision coverage, condition coverage, and multiple condition coverage. It aims to execute every statement, decision path, condition, and combination of conditions in the code. White-box testing is more effective at finding defects earlier in the SDLC but also more expensive and difficult to implement than black-box testing.
This document summarizes a practical arc flash risk assessment strategy conducted on 174 high and low voltage switchboards at a mining site. The assessment included a physical condition assessment to determine the likelihood of arc faults occurring, and an arc flash evaluation to determine the consequences of arc faults. The results were combined into a risk matrix to prioritize upgrade and mitigation efforts. The assessment found 37 switchboards requiring replacement within 2 years and 58 requiring replacement within 5 years based on their poor condition and increased risk.
This test plan outlines GUI validation testing for the Renters Insurance Project Agent Module. The testing will validate field types, captions, and business rules before functional testing. Smoke, regression, and adhoc testing will also be conducted to find defects. Defects will be logged and prioritized in the defect tracking tool. Test cases will be designed based on requirements and reviewed before execution. Execution will continue until no high/critical defects remain. The plan details test approaches, resources, milestones, risks, and dependencies.
The document describes the phases of the Software Testing Life Cycle (STLC). It discusses the 6 main phases: 1) Requirement Analysis, 2) Test Planning, 3) Test Case Development, 4) Environment Setup, 5) Test Execution, and 6) Test Cycle Closure. Each phase has entry and exit criteria, activities, and deliverables. The STLC is a testing process executed in a systematic, planned manner, following the software development life cycle to ensure quality.
Minh Nguyen presented experiences applying model-based testing (MBT) for automated test case generation and execution. MBT uses models of requirements, rules, and test filters to automatically generate test cases from an MBT tool and execute them against a system under test via a test automation tool. Key benefits are adjustable test coverage tailored to changes, reduced maintenance costs, and traceability between requirements and tests. Completeness of models and domain knowledge are critical. The roadmap is to expand MBT use with tools like ReadyAPI and integrate with DevOps pipelines.
This document contains sample questions for ISTQB certification. It includes 28 multiple choice questions covering topics like test case design, test levels, test types, debugging, and tools. The questions are from past exams and are intended to help examinees prepare. More sample questions can be found at the listed websites.
This document contains sample questions for ISTQB certification. It includes 28 multiple choice questions covering topics like test case design, test levels, test types, debugging, and tools. The questions are from past exams and are intended to help examinees prepare. More sample questions can be found at the listed websites.
This document contains 10 sample questions from an ISTQB sample paper on software testing. The questions cover topics like test case design, test levels, test techniques, defect management, and test process activities. The document provides explanations and answers to the sample questions to help examinees prepare for the ISTQB certification exam.
This document discusses reliability testing and quality management techniques. It begins by outlining different types of product life testing, including failure-terminated testing, time-terminated testing, and sequential testing. It then describes accelerated life testing and how it can be used to optimize testing by compressing time periods. Finally, it discusses concepts like zero defects, quality circles, and steps that can be taken to ensure zero defects in manufacturing.
This session will demonstrate a new approach to LIMS implementations eliminates the complexities, excessive customization and lengthy associated validation requirements inherent with legacy LIMS—offering fast, “out-of-the-box” deployment capabilities, no custom coding, easy integration into existing software platforms and enterprise-wide data management capabilities.
Each Accelrys LIMS application comes with Workflow Editors that eliminate traditional software custom-coding processes, enabling your own internal system administrator to deploy needed applications, workflows and procedures using a simple drag-and-drop process and dialog interface.
When finished with the workflow editing, a single mouse click generates a complete validation document for the application, workflow or procedure created. Built-in compliance at the “core technology” level turns qualification/validation into a simple, fast document review with no need for external validation consultants, even in regulated environments.
The document contains 40 multiple choice questions related to software testing concepts and techniques:
1. The questions cover topics like test automation benefits, boundary value analysis, test levels, test types like unit testing and integration testing, test techniques like equivalence partitioning and boundary value analysis, test documentation standards like IEEE 829, and principles like regression testing and the pesticide paradox.
2. The questions test understanding of core testing concepts as well as ability to identify the correct application of techniques and principles in given code snippets or scenarios.
3. Agile development approaches and iterative life cycles are also touched upon, recognizing testing is an integral part of modern agile software development practices.
This document describes a process called "Scenario based Test Scoping" to optimize testing efforts for automation projects. It involves identifying and prioritizing test scenarios (Priority A and B) based on functionality criticality. Priority A scenarios must always be run, while Priority B would only be run during full regressions. Complexity factors are also assigned to scenarios. This allows estimating effort savings. The document provides an example where identifying Priority B scenarios across 11 functions found 20.39% could be omitted, potentially saving around 10% of testing effort. Implementing this scenario-based scoping approach helps optimize resources on important test cases.
When a test manager receives a project to work with, he would like to comprehend the scope of the project, the test objectives such as project timeline, project resources and budget. The Test Manager then needs to think about the test strategy. Selecting an appropriate test strategy is crucial for his project success. There are several test strategies for the Test Manager to select such as analytical, model-based, methodical, process or standard-compliant, dynamic, consultative or directed, and regression-averse. One of the most common and important test strategy is the analytical one that includes risk-based and specification-based testing. Comprehending analytical strategy and its methodologies will help the test manager guide software testing activities to reach the right targets to fulfill the testing objectives. That will make the customers happy and accept his company products. Then he and his company will get paid and great compensation from the customers. From there, his company business will continue to expand and everybody will be happy.
The talk will bring ideas about the analytical strategy and how to run risk-based and specification-based testing activities. Definitely the talk will bring good value to software testing audiences especially test managers. Testers, developers, project managers and higher management can benefit from the talk in the way that they understand and facilitate software testing methodologies in software development life cycle.
Application of theorem proving for safety-critical vehicle softwareAdaCore
The document discusses applying formal verification techniques like theorem proving to automotive software for safety-critical functions. It provides background on software safety requirements and discusses fault avoidance versus fault tolerance approaches. The document then presents a case study where theorem proving is used to verify a software function for autonomous vehicle control. It explains the process of breaking the software into portions and verifying each portion using logical proofs of pre and post conditions. The document highlights benefits of theorem proving over testing in providing a logical proof that software is bug-free, but also notes limitations like not verifying timing behavior.
- Swift Act LLC is an engineering consultancy established in 2017 with legal representation in Egypt and Germany and experience in industries like automotive, IoT, and consumer electronics.
- A state machine is a model used to describe the behavior of systems that can be in one of a finite number of states, triggered by external events to transition between the states.
- State machines have elements like states, transitions, events, and actions and can be represented graphically, tabularly, or textually. They are commonly used in software design and coding.
The document discusses embedded software testing and provides an overview of key concepts:
- It describes different testing levels from component to system acceptance testing and strategies like top-down and bottom-up.
- Important testing techniques are outlined for both black-box and white-box testing as well as static and dynamic analysis.
- The skills required of an embedded tester are discussed along with different embedded testing jobs.
- Examples of testing a display component and integrating components are demonstrated.
This document provides an outline for cracking the interview process. It discusses preparing for technical and HR interviews by understanding job requirements, customizing your resume, and practicing common interview styles and mistakes to avoid. The key steps are to research available jobs and companies, select target opportunities, and thoroughly prepare for both the technical and HR aspects of the interview.
The document discusses developing network device drivers for embedded Linux. It covers key topics like socket buffers, network devices, communicating with network protocols and PHYs, buffer management, and differences between Ethernet and WiFi drivers. The outline lists these topics and others like throughput and considerations. Prerequisites include C skills, Linux knowledge, and an understanding of networking and embedded driver development.
Hello,
Swift Act Services will be providing its first embedded summer boot camp. The total cost is EGP 3500 for all courses. Individual course costs are:
1- C Programming = EGP 1000
2- Device Drivers = EGP 1000
3- SW Design = EGP 2000
4- SW Testing = EGP 2000
5- Project = EGP 1000
You are free to attend individual courses or the other packages.
Course are planned starting Jun 29 every week Thursday, Friday and Saturday from 10 am till we finish the day content. It is serious training. Be ready.
For courses registeration, please use this form before End of May.
https://goo.gl/forms/a8205QCMVuXSkkzI2
This document is an introduction to C programming presentation. It covers topics like variables and data types, control flow, modular programming, I/O, pointers, arrays, algorithms, data structures and the C standard library. The presentation notes that C was invented in 1972 and is still widely used today for systems programming, operating systems, microcontrollers and more due to its efficiency and low-level access. It also provides examples of C code structure, comments, preprocessor macros and functions.
This document provides an overview of an introduction to STM32 course. The course covers the ARM Cortex processor, STM32 system on chip, STM32 building blocks, low power operation, safety features, the flash module, and development tools. The goal of the course is to help students understand what the ARM Cortex processor and STM32 SoC are, and identify the main components of the STM32 microcontroller.
This document provides an overview of using Xilinx ISE to synthesize a VHDL design unit. It begins with copyright information and objectives. It then outlines the basic synthesis flow, including creating a new project, setting project options, importing files, running synthesis, viewing the RTL schematic, and reviewing the synthesis report. The document provides step-by-step instructions on performing each step of the synthesis flow and analyzing results.
This document provides an overview of using ModelSim to simulate VHDL designs. It discusses compiling and simulating designs from the command line as well as interactively within ModelSim. Key steps covered include compiling VHDL files with vcom, simulating with vsim, adding signals to the waveform window, applying inputs, running simulations, generating makefiles, and creating and simulating designs within the ModelSim GUI. The document aims to teach basic ModelSim simulation commands and workflow.
This document provides an introduction to FreeRTOS V6.0.5. It outlines the course objectives, which are to understand FreeRTOS services and APIs, experience different FreeRTOS features, and understand the porting process. It then describes the course structure and labs covering the FreeRTOS kernel structure, task management, queue management, semaphore/mutex management, co-routine management, advanced features, and porting FreeRTOS.
This document provides an introduction and overview of queue management in FreeRTOS. It describes the different types of queue APIs for creation, deletion, sending messages, receiving messages, checking queue status, and more. It also distinguishes between regular and ISR-safe queue APIs, and notes there are alternative queue implementations. The document is presented as a course on FreeRTOS with multiple labs, including one focused on queue management.
This document provides an introduction to FreeRTOS version 6.0.5. It outlines the course objectives, which are to understand FreeRTOS services and APIs, experience different FreeRTOS features through labs, and understand the FreeRTOS porting process. The document describes key FreeRTOS concepts like tasks, task states, priorities, and provides an overview of task management APIs for creation, deletion, delaying, and querying tasks.
More from Amr Ali (ISTQB CTAL Full, CSM, ITIL Foundation) (12)
Quantum Communications Q&A with Gemini LLM. These are based on Shannon's Noisy channel Theorem and offers how the classical theory applies to the quantum world.
Measuring the Impact of Network Latency at TwitterScyllaDB
Widya Salim and Victor Ma will outline the causal impact analysis, framework, and key learnings used to quantify the impact of reducing Twitter's network latency.
論文紹介:A Systematic Survey of Prompt Engineering on Vision-Language Foundation ...Toru Tamaki
Jindong Gu, Zhen Han, Shuo Chen, Ahmad Beirami, Bailan He, Gengyuan Zhang, Ruotong Liao, Yao Qin, Volker Tresp, Philip Torr "A Systematic Survey of Prompt Engineering on Vision-Language Foundation Models" arXiv2023
https://arxiv.org/abs/2307.12980
Comparison Table of DiskWarrior Alternatives.pdfAndrey Yasko
To help you choose the best DiskWarrior alternative, we've compiled a comparison table summarizing the features, pros, cons, and pricing of six alternatives.
Coordinate Systems in FME 101 - Webinar SlidesSafe Software
If you’ve ever had to analyze a map or GPS data, chances are you’ve encountered and even worked with coordinate systems. As historical data continually updates through GPS, understanding coordinate systems is increasingly crucial. However, not everyone knows why they exist or how to effectively use them for data-driven insights.
During this webinar, you’ll learn exactly what coordinate systems are and how you can use FME to maintain and transform your data’s coordinate systems in an easy-to-digest way, accurately representing the geographical space that it exists within. During this webinar, you will have the chance to:
- Enhance Your Understanding: Gain a clear overview of what coordinate systems are and their value
- Learn Practical Applications: Why we need datams and projections, plus units between coordinate systems
- Maximize with FME: Understand how FME handles coordinate systems, including a brief summary of the 3 main reprojectors
- Custom Coordinate Systems: Learn how to work with FME and coordinate systems beyond what is natively supported
- Look Ahead: Gain insights into where FME is headed with coordinate systems in the future
Don’t miss the opportunity to improve the value you receive from your coordinate system data, ultimately allowing you to streamline your data analysis and maximize your time. See you there!
Understanding Insider Security Threats: Types, Examples, Effects, and Mitigat...Bert Blevins
Today’s digitally connected world presents a wide range of security challenges for enterprises. Insider security threats are particularly noteworthy because they have the potential to cause significant harm. Unlike external threats, insider risks originate from within the company, making them more subtle and challenging to identify. This blog aims to provide a comprehensive understanding of insider security threats, including their types, examples, effects, and mitigation techniques.
Support en anglais diffusé lors de l'événement 100% IA organisé dans les locaux parisiens d'Iguane Solutions, le mardi 2 juillet 2024 :
- Présentation de notre plateforme IA plug and play : ses fonctionnalités avancées, telles que son interface utilisateur intuitive, son copilot puissant et des outils de monitoring performants.
- REX client : Cyril Janssens, CTO d’ easybourse, partage son expérience d’utilisation de notre plateforme IA plug & play.
How Social Media Hackers Help You to See Your Wife's Message.pdfHackersList
In the modern digital era, social media platforms have become integral to our daily lives. These platforms, including Facebook, Instagram, WhatsApp, and Snapchat, offer countless ways to connect, share, and communicate.
INDIAN AIR FORCE FIGHTER PLANES LIST.pdfjackson110191
These fighter aircraft have uses outside of traditional combat situations. They are essential in defending India's territorial integrity, averting dangers, and delivering aid to those in need during natural calamities. Additionally, the IAF improves its interoperability and fortifies international military alliances by working together and conducting joint exercises with other air forces.
Are you interested in dipping your toes in the cloud native observability waters, but as an engineer you are not sure where to get started with tracing problems through your microservices and application landscapes on Kubernetes? Then this is the session for you, where we take you on your first steps in an active open-source project that offers a buffet of languages, challenges, and opportunities for getting started with telemetry data.
The project is called openTelemetry, but before diving into the specifics, we’ll start with de-mystifying key concepts and terms such as observability, telemetry, instrumentation, cardinality, percentile to lay a foundation. After understanding the nuts and bolts of observability and distributed traces, we’ll explore the openTelemetry community; its Special Interest Groups (SIGs), repositories, and how to become not only an end-user, but possibly a contributor.We will wrap up with an overview of the components in this project, such as the Collector, the OpenTelemetry protocol (OTLP), its APIs, and its SDKs.
Attendees will leave with an understanding of key observability concepts, become grounded in distributed tracing terminology, be aware of the components of openTelemetry, and know how to take their first steps to an open-source contribution!
Key Takeaways: Open source, vendor neutral instrumentation is an exciting new reality as the industry standardizes on openTelemetry for observability. OpenTelemetry is on a mission to enable effective observability by making high-quality, portable telemetry ubiquitous. The world of observability and monitoring today has a steep learning curve and in order to achieve ubiquity, the project would benefit from growing our contributor community.
How RPA Help in the Transportation and Logistics Industry.pptxSynapseIndia
Revolutionize your transportation processes with our cutting-edge RPA software. Automate repetitive tasks, reduce costs, and enhance efficiency in the logistics sector with our advanced solutions.
Sustainability requires ingenuity and stewardship. Did you know Pigging Solutions pigging systems help you achieve your sustainable manufacturing goals AND provide rapid return on investment.
How? Our systems recover over 99% of product in transfer piping. Recovering trapped product from transfer lines that would otherwise become flush-waste, means you can increase batch yields and eliminate flush waste. From raw materials to finished product, if you can pump it, we can pig it.
Fluttercon 2024: Showing that you care about security - OpenSSF Scorecards fo...Chris Swan
Have you noticed the OpenSSF Scorecard badges on the official Dart and Flutter repos? It's Google's way of showing that they care about security. Practices such as pinning dependencies, branch protection, required reviews, continuous integration tests etc. are measured to provide a score and accompanying badge.
You can do the same for your projects, and this presentation will show you how, with an emphasis on the unique challenges that come up when working with Dart and Flutter.
The session will provide a walkthrough of the steps involved in securing a first repository, and then what it takes to repeat that process across an organization with multiple repos. It will also look at the ongoing maintenance involved once scorecards have been implemented, and how aspects of that maintenance can be better automated to minimize toil.
Quality Patents: Patents That Stand the Test of TimeAurora Consulting
Is your patent a vanity piece of paper for your office wall? Or is it a reliable, defendable, assertable, property right? The difference is often quality.
Is your patent simply a transactional cost and a large pile of legal bills for your startup? Or is it a leverageable asset worthy of attracting precious investment dollars, worth its cost in multiples of valuation? The difference is often quality.
Is your patent application only good enough to get through the examination process? Or has it been crafted to stand the tests of time and varied audiences if you later need to assert that document against an infringer, find yourself litigating with it in an Article 3 Court at the hands of a judge and jury, God forbid, end up having to defend its validity at the PTAB, or even needing to use it to block pirated imports at the International Trade Commission? The difference is often quality.
Quality will be our focus for a good chunk of the remainder of this season. What goes into a quality patent, and where possible, how do you get it without breaking the bank?
** Episode Overview **
In this first episode of our quality series, Kristen Hansen and the panel discuss:
⦿ What do we mean when we say patent quality?
⦿ Why is patent quality important?
⦿ How to balance quality and budget
⦿ The importance of searching, continuations, and draftsperson domain expertise
⦿ Very practical tips, tricks, examples, and Kristen’s Musts for drafting quality applications
https://www.aurorapatents.com/patently-strategic-podcast.html
The DealBook is our annual overview of the Ukrainian tech investment industry. This edition comprehensively covers the full year 2023 and the first deals of 2024.
2. Objectives
Build on ISTQB CTFL in the area of technical test analysis
Prepare for the ISTQB CTAL – Technical Test Analyst exam
31/08/20122
ISTQB Advanced Level 2012 - Technical Test
Analyst
3. Prerequisites
ISTQB CTFL or equivalent
Practical experience in SW testing
31/08/20123
ISTQB Advanced Level 2012 - Technical Test
Analyst
4. Notes
Ask any time.
Turn your cell silent.
31/08/20124
ISTQB Advanced Level 2012 - Technical Test
Analyst
5. References
ISTQB CTAL – TTA syllabus version 2012
31/08/20125
ISTQB Advanced Level 2012 - Technical Test
Analyst
6. Outline
The Technical Test Analyst's Tasks in Risk-Based Testing
Structure-Based Testing
Analytical Techniques
Quality Characteristics for Technical Testing
Reviews
Test Tools and Automation
31/08/20126
ISTQB Advanced Level 2012 - Technical Test
Analyst
7. Outline
The Technical Test Analyst's Tasks in Risk-Based Testing
Structure-Based Testing
Analytical Techniques
Quality Characteristics for Technical Testing
Reviews
Test Tools and Automation
31/08/20127
ISTQB Advanced Level 2012 - Technical Test
Analyst
10. What is Structure-Based Testing?
AKA white box or code-based
testing
Uses the code, the data and the
architecture and/or system flow as
the basis for test design
Techniques used in structure-
based testing:
Derive test cases systematically
Focus on a particular aspect of
the structure
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
10
11. Examples of Structure-Based Testing
Test Basis
Component level
Code structure
Statements
Decisions
Conditions
Integration level
Call tree
System level
Menus structure
Business process
Web page structure
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
11
12. Why Structure-Based Testing?
Structure-based testing provides a coverage criteria.
A criteria can be measured and associated with an objective.
Achieving full coverage != Complete test
It only means technique being used no longer suggests any useful tests for
the structure under consideration.
Complete test is project context dependent.
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
12
13. When Structure-Based Testing should
be Used?
Specification-based testing will never test all the code.
Structure-based testing should be used on top of specification based
testing to measure the coverage and hence add extra tests to increase the
coverage.
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
13
14. Atomic Conditions vs. Decisions
A is an atomic condition.
B is a atomic condition.
C is a atomic condition.
(A &&B) || C is a decision.
Logical combination of atomic conditions makes a decision predicate.
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
14
if ((A && B) || C){
...
}
17. What is Condition Testing?
Considers how decisions are made rather than decision predicates
Answers the question “Could there be bugs hiding in the condition itself?”
Makes sure that each atomic condition is tested both ways, TRUE and
FALSE
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
17
18. Condition Testing Coverage
% of conditions possibilities exercised by a test suite
Condition coverage % = (# of conditions possibilities executed/total # of
conditions possibilities ) * 100
Example:
Program has 100 conditions, thus 200 conditions possibilities
Tests exercise 112 conditions possibilities
Condition coverage = 56%
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
18
19. How is Condition Testing Done?
1. Identify atomic conditions.
2. Find the minimal test cases to achieve 100% condition coverage for each
atomic condition.
3. Combine test cases of the atomic conditions to find the minimal test
cases to test the decision. Make sure all test cases identified in step 2 are
executed.
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
19
20. Exercise: Identify Min # of Test Cases
to Achieve 100% Condition Coverage
1. X
2. D && F
3. (A || B) && (C == D)
4. (A > B) || ( X + Y == - 1) && (! (D) == TRUE)
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
20
21. Condition Testing Applicability
Probably interesting only in the abstract
Understanding it is necessary to achieving greater levels of coverage that
build upon it.
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
21
22. Condition Testing Limitations
Achieving 100% condition coverage does not necessitate 100% decision
coverage.
100% condition coverage necessitates 100% decision coverage iff
decisions are consisted of single atomic expressions.
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
22
if (A && B){
...
} else {
...
}
if (X){
...
} else {
...
}
TC1: A = T and B = F
TC2: A = F and B = T
TC1: X = T
TC2: X = F
24. What is Decision Condition Testing?
Testing must achieve condition coverage and decision coverage.
100% decision condition coverage guarantees 100% statement
coverage, 100% decision coverage, and 100% condition coverage.
A thoughtful choice of test data values for atomic conditions may result in
achieving this level of coverage without adding extra test cases beyond
that needed to achieve condition coverage.
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
24
if (A && B){
...
} else {
...
}
TC1: A = T and B = T
TC2: A = F and B = F
26. How is Decision Condition Testing
Done?
1. Identify atomic conditions.
2. Find the minimal test cases to achieve 100% condition coverage for each
atomic condition.
3. Combine test cases of the atomic conditions to find the minimal test
cases to test the decision keeping in mind 100% decision coverage is
achieved. Make sure all test cases identified in step 2 are executed.
4. Add/Modify any test cases needed if 100% decision coverage is not
achieved while keeping the 100% condition coverage
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
26
27. Exercise: Identify Min # of Test Cases to Achieve
100% Decision Condition Coverage
1. X
2. D && F
3. (A || B) && (C == D)
4. (A > B) || ( X + Y == - 1) && (! (D) == TRUE)
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
27
28. Decision Condition Testing
Applicability
Code is important but not critical.
What is important and what is critical?!!!
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
28
29. Decision Condition Testing Limitations
May require more test cases compared to previous techniques
May consume more time compared to previous techniques
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
29
31. What is MC/DC Testing?
Created by Boeing for use when specific languages were to be used in
safety-critical programming
Provides a stronger level of control flow coverage
Guarantees 100% decision condition coverage and adds to it
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
31
32. MC/DC Coverage
1. At least one test where the decision outcome would change if the atomic
condition X were TRUE
2. At least one test where the decision outcome would change if the atomic
condition X were FALSE
3. Each different atomic condition has tests that meet requirements 1 and
2.
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
32
33. MC/DC Coverage in Other Words
1. 100% condition coverage
2. 100% decision coverage
3. Each atomic condition must affect the outcome decision independently
while the other atomic conditions are held fixed.
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
33
34. MC/DC Testing by Example
(A || B) && C
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
34
A B C
(A or B)
and C
Test 1 T F T T
Test 2 F T T T
Test 3 F F T F
Test 4 T F F F
35. C/C’s of MC/DC Testing
Number of test cases for a decision is unique.
There may be more than a test group fulfilling the MC/DC coverage.
Causes a lot of testing but not an exhaustive testing
Assuming N unique atomic conditions, MC/DC can usually be achieved in
N+1 unique test cases
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
35
36. Logical Expressions and their Truth
Tables
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
36
37. MC/DC Testing for an And Gate
N inputs and gate requires n+1 test cases.
All inputs are true.
Each input is set exclusively to false.
Exercise: Find test cases for (A && B && C)
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
37
38. MC/DC Testing for an Or Gate
N inputs or gate requires n+1 test cases.
All inputs are false.
Each input is set exclusively to true.
Exercise: Find test cases for (A || B || C)
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
38
39. MC/DC Testing for an Xor Gate
No rule
For a 2-input xor gate, any 3 out of the 4 possible combinations can
achieve the MC/DC coverage.
Only 1 combination can detect an OR mistyped as XOR.
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
39
40. MC/DC Testing for a Not Gate
Only 2 test cases
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
40
41. MC/DC Testing for Comparators
<, >, <=, >=, ==, !=
Needs 3 test cases:
Output is false and inputs are close to the boundary.
Output is true and inputs are close the boundary.
The inputs are at the boundary.
MC/DC + discovering typing mistakes
Exercise: Find test cases for x >= 25000
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
41
42. MC/DC Testing for an If-Else
Statement
Needs the following test cases:
Inputs to make decision true.
Inputs to force decision false.
Inputs to exercise any of the previous items in the decision.
Exercise: if(Z) statement 1; else statement 2;
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
42
43. MC/DC Testing for a While Loop
Needs the following test cases:
Inputs to make decision true.
Inputs to force decision false.
Inputs to exercise any of the previous items in the decision.
What about the for loop?
Exercise: while(Z) statement 1;
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
43
44. MC/DC Testing for a Do-While Loop
Needs the following test cases:
Inputs to make decision true.
Inputs to force decision false
Inputs to exercise any of the previous items in the decision.
Exercise: do statement 1; while(Z);
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
44
45. How is MC/DC Testing Done?
1. Represent source code graphically in terms of logic gates.
2. Identify test inputs and output relation.
1. Draw truth table
3. Identify observation point and control input(s), then eliminate masked
test cases.
4. Determine MC/DC for each logic gate starting from the input moving
towards the output.
Exercise: Determine MC/DC for (B && C) || D.
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
45
46. 1- Representing the Code Graphically
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
46
47. 2- I/O Relation
ID B C D A
1 F F F F
2 F F T T
3 F T F F
4 F T T T
5 T F F F
6 T F T T
7 T T F T
8 T T T T
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
47
48. 3- Observation Point, Control Input,
Masked Test Case
An observation point is the point at which we observe the output of
concern.
A control input is when its value is known, the value at the observation
point can be calculated regardless of the other inputs.
Masked test cases are test cases where the we care only for the control
input and others inputs are do not care. They are in the essence
equivalent.
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
48
49. 3- Observation Point, Control Input,
Masked Test Case cont’d
Masking tests rules:
W and true = W
W or false = W
W xor false = W
W xor true = !W
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
49
50. 3- Observation Point, Control
Input, Masked Test Case cont’d
ID B C D A
1 F F F F
2 F F T T
3 F T F F
4 F T T T
5 T F F F
6 T F T T
7 T T F T
8 T T T T
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
50
Observation Point
Control Input when =
T
Masked Test Cases
51. 4- Determining MC/DC for the Gates
By combining the results in the table, we can use any of the following tests
:
2, 3, 5, 7
3, 4, 5, 7
3, 5, 6, 7
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
51
Valid Inputs Missing Test Cases
And gate TT: row 7
TF: row 5
FT: row 3
Or gate FF: rows 1, 3, or 5
TF: row 7
FT: rows 2, 4, or 6
52. Exercise: Identify Min # of Test Cases
to Achieve 100% MC/DC Coverage
1. Z = (A || B) && (C || D)
2. Z = (A && !B) || (C || D)
3. A = (B || C) && D; E = (X && Y) || C; Z = A&& E
4. O = (O || I) && !R
5. Z = X & Y
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
52
53. MC/DC Testing Applicability
Aerospace SW industry
Safety-critical systems
In general, it is used when dealing with safety critical SW where any failure
may cause a catastrophe.
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
53
54. MC/DC Testing Limitations
Short-circuiting may affect the ability to attain MC/DC coverage since
some required tests may not be achievable.
Achieving MC/DC coverage may be complicated when the atomic
conditions are coupled in the expression.
Depending on the decision statement in the code, it may not be possible to
vary the value of the coupled term such that it alone causes the decision
outcome to change.
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
54
55. Short Circuiting
In some programming languages or some compiler options, the right hand
operand is evaluated iff it is needed to determine the expression value.
Q: If func() is never evaluated, the question then becomes, can we still
achieve MC/DC coverage?
A: May be as some tests may be not achievable at all.
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
55
if (A || func()){
...
}
56. Short Circuiting cont’d
Many organizations evaluated it in different ways.
If your project is subject to regulatory statutes, consult how that
regulatory body wants you to deal with the short circuiting.
For example, NASA claims that short circuit logic can be dealt with by
applying the masking MC/DC approach explained earlier, where a case-by-
case basis analysis of the decision is done.
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
56
57. Coupled Atomic Conditions
Multiple occurrences of a condition in an expression is called coupling.
A and !A can not be varied independently as required by MC/DC.
If your project is subject to regulatory statutes, consult how that
regulatory body wants you to deal with the short circuiting.
There are 2 approaches for facing such situation:
1. Unique Cause MC/DC approach, where the term condition in the definition of
MC/DC is deemed to mean uncoupled condition.
2. Masking MC/DC approach explained earlier, where a case-by-case basis
analysis of the decision is done.
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
57
if (A || (! A && B)){
...
}
59. What is Multiple Condition Testing?
Test every possible combination of atomic conditions in a decision!
Truly exhaustive testing
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
59
60. How is Multiple Condition Testing
Done?
Create a truth table with every combination.
Does not take much analysis
# of test cases = 2# of atomic conditions
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
60
61. Multiple Condition Testing by
Example
(A || B) && C
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
61
A B C
(A or B)
and C
Test 1 F F F F
Test 2 F F T F
Test 3 F T F F
Test 4 F T T T
Test 5 T F F F
Test 6 T F T T
Test 7 T T F F
Test 8 T T T T
62. Is it Really a Truth Table?
Short circuiting and coupling are still applicable.
If the language uses short-circuiting, the number of actual test cases will
often be reduced, depending on the order and grouping of logical
operations that are performed on the atomic conditions.
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
62
63. Exercise: Identify Min # of Test Cases to Achieve
100% Multiple Condition Coverage
Assume we have short circuit logic compiler
1. A && B && (C || (D && E))
2. ((A || B) && (C || D)) && E
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
63
64. Multiple Condition Testing
Applicability
Testing embedded software which was expected to run reliably without
crashing for long periods of time
Telephone switches that were expected to last 30 years
This type of testing is likely to be replaced by MC/DC testing in most
critical applications.
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
64
65. Multiple Condition Testing Limitations
Because the number of test cases can be derived directly from a truth
table containing all of the atomic conditions, this level of coverage can
easily be determined.
However, the sheer number of test cases required makes MC/DC coverage
more applicable to most situations.
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
65
67. What is Path Testing?
Identifying paths through the code and then creating tests to cover them
In some cases we will get some of the same tests we got through control-
flow testing.
On the other hand, we might come up with some other interesting tests.
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
67
68. Brute Force Path Testing
Test every independent path through the system.
Loops are the killers.
Needs infinite time and infinite resources!
However, it is realistic to perform some path testing.
Exercise: How many paths do exist in the shown figure?
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
68
69. How can Loops be Tested in Path
Testing?
A significant and meaningful reduction is needed.
1. Execute the loop zero times.
2. Execute the loop one time.
3. Execute the loop n times.
n is very small and typical loop value.
4. Execute the loop m times
m is the maximum number of loop times.
5. Test m-1, and m+1 times
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
69
70. Path Testing Coverage
% of paths exercised by a test suite
Path coverage % = (# of paths executed/total # of paths ) * 100
Example:
Program has 74 paths
Tests exercise 30 paths
Path coverage = 40%
Notes:
100% path coverage (disregarding loops) = 100 % statement coverage + 100%
decision coverage
Path testing provides more thorough testing than decision coverage, with a
relatively small increase in the number of tests .
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
70
71. How is Path Testing Done?
1. Beizer’s Method of Path Testing
2. Linear Code Sequence And Jump Testing – LCSAJ Testing
3. Basis Path/Cyclomatic Complexity Testing
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
71
72. Beizer’s Method
1. Pick the first path as the simplest, functionally sensible path from entry
to exit.
2. Pick each additional path as a small variation on the previous path.
Try to change only one branch in the path.
Favor short paths over long paths when possible.
Favor paths that make functional sense over ones that do not.
3. Pick paths that don't make functional sense only when required for
coverage.
Such paths might be extraneous and should be questioned.
4. Use intuition when choosing paths.
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
72
73. Notes about Beizer’s Method
Some path segments are likely to be executed more than once.
The key point is to test every possible branch through the code at least
once and possibly many times.
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
73
74. Exercise: Identify Min # of Test Cases to Achieve
100% Path Coverage Using Beizer’s Method
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
74
A = getchar();
B = getchar();
C = getchar();
if(A > 10) {
printf(“Case 1n”);
}
if((B > 1) || (C > 2)){
printf(“Case 1n”);
}
75. What is a LCSAJ Testing?
AKA as decision-to-decision testing
Concerned with testing a linear sequence of executable statements of
code followed by a jump to another executable statement of code. This
might happen after a decision or a goto statement in the code.
Devised by Professor Michael Hennell of the University of Liverpool in
1976
Relatively high overhead methodology for testing
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
75
76. What is a LCSAJ?
Small block of code that:
1. Has a start which can be a start of a module or a line of code jumped to from
another LCSAJ
2. Has an end which can be a module end or a line of code where a jump occurs
3. Has a target line of the jump
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
76
77. LCSAJ Testing Coverage
% of LCSAJs exercised by a test suite
LCSAJ coverage % = (# of LCSAJs executed/total # of LCSAJs ) * 100
Example:
Program has 42 LCSAJs
Tests exercise 30 LCSAJs
LCSAJ coverage = 71 %
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
77
79. Exercise: Identify Min # of Test Cases to
Achieve 100% LCSAJ Coverage
For the previous example, identify the min # of test cases to achieve 100%
LCSAJ coverage.
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
79
80. Notes About LCSAJ Testing
Not all LCSAJs are really executable.
They can be executed by special intervention using debuggers for example.
A lot of time may be spent to achieve 100% LCSAJ coverage.
LCSAJ testing is really brittle to code and requires expensive maintenance.
LCSAJs testing in most cases leads to a partial path coverage.
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
80
81. What is Basis Path/Cyclomatic
Complexity Testing?
Suggestion is to test the structure of the code to a reasonable amount
Devised by Thomas McCabe in 1976
Any SW module has a small # of unique, independent paths (excluding
iterations) called basis paths.
Code structure can be tested by testing the basis paths because all the
infinite different paths are just using/reusing the basis paths.
AKA minimal path testing
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
81
82. Basis Path and Basis Path Set
Basis path is a unique independent path through the module with no
iterations or loops allowed.
A basis path traverses at least one edge that no other path does.
Basis path set is the smallest # of basis paths that cover the structure of
the code.
100% basis path coverage = 100% statement coverage + 100% decision
coverage
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
82
83. Cyclomatic Complexity
Cyclomatic refers to an imaginary loop from the end of a module of code
back to the beginning of it.
Cyclomatic complexity # is the # of loops needed to cycle through the loop
until the structure of the code has been completely covered.
Depends on the decisions in the module not on the module size
Cyclomatic complexity # = # of test cases we need to test the set of basis
paths = # of basis paths
The higher the complexity, the more likely there will be a higher bug count
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
83
84. Example: Calculating Cyclomatic
Complexity
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
84
EuclidGCD (int a, int b){
int t;
if (a <= 0)
return -1;
if (b <= 0)
return -1;
if (b > a) {
t = a;
a = b;
b = t;
}
t = a % b;
while (t != 0) {
a = b;
b = t;
t = a % b;
}
return b;
}
End
Start a <= 0
b <= 0
b > a
t != 0
A B
C
D
E F
85. Example: Calculating Cyclomatic
Complexity cont’d
C = # of Regions + 1 = 4 + 1 = 5
C = # of Edges - # of Nodes + 2 x # of
Connected Components = 9 – 6 + 2 =
5
C = # of branching + # of looping + 1
= 3 + 1 + 1
Used for large code constructs and
does not need CFGs
if, for, while, or do-while constructs
count as 1.
case block counts as 1.
else and default block count as 0.
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
85
End
Start a <= 0
b <= 0
b > a
t != 0
A
C
D
E F
B
86. Example: Deriving Basis Paths and
Test Cases
Basis paths are:
ABF
ABCF
ABCDEF
ABCDEF
ABCDEEF
Basis tests are:
-5, 2 -1
2, -5 -1
16, 8 8
4, 8 4
20, 8 4
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
86
End
Start a <= 0
b <= 0
b > a
t != 0
A
C
D
E F
B
87. Exercise: Identify Min # of Test Cases to
Achieve 100% Basis Path Testing Coverage
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
87
int main(int MaxCols, int Iterations, int MaxCount){
int count = 0, totals[MaxCols], val = 0;
memset(totals, 0, MaxCols * sizeof(int));
if (MaxCount > Iterations){
while(count < Iterations){
val = abs(rand()) % MaxCols;
totals[val] += 1;
if(totals[val] > MaxCount){
totals[val] = MAXCOUNT;
}
count++;
}
}
return(0);
}
88. Path Testing Applicability
Partial path testing is often performed in safety critical SW.
It is a good addition to the other methods covered earlier because it looks
at paths through the SW rather than just at the way decisions are made.
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
88
89. Path Testing Limitations
While it is possible to use a control flow graph to determine the
paths, realistically a tool is required to calculate them for complex
modules.
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
89
91. What is an API?
An Application Programming
Interface (API) is code which
enables communication between
different processes, programs
and/or systems.
APIs are often utilized in a
client/server relationship where
one process supplies some kind of
functionality to other processes.
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
91
92. What is API Testing?
In certain respects API testing is quite similar to testing a GUI.
Though GUI is rarely involved.
The focus is on the evaluation of input values and returned data.
Setting (complex) initial environment as GUI is mostly not involved is very
common.
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
92
93. Aspects of API Testing
Aspect Description
-ve testing
Trying to use API interfaces in ways for which they
were not intended
Testing APIs robust error handling to avoid incorrect
operation
Combinatorial testing
Combining the APIs as well as their parameters in
different ways because APIs are often used in
conjunction with other APIs
Availability/Reliability testing
APIs are loosely coupled. Transactions can be lost or
timed-out.
Thorough testing of the recovery and retry
mechanisms to ensure that all services have a very
high availability
Requires reliability testing by the API author as well as
infrastructure support
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
93
94. API Testing Coverage
API testing is a type of testing rather than a measurement/coverage
technique.
No specific coverage level
Coverage example could be input/output coverage.
1. Use equivalence partitioning to determine valid/invalid input/output
partitions.
2. Use equivalence partitioning testing and boundary value testing to design test
cases that cover all valid/invalid input/output partitions.
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
94
95. API Testing Applicability
In distributed systems or remote processing
OS calls
SOA
RPC
Web services
Testing systems of systems
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
95
96. API Testing Limitations
Usage of specialized tools as there is no GUI involvement
Tools are needed for:
Initial environment setup
Data marshaling
API invocation
Result determination
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
96
98. Testing Principle #6: Testing is Context
Dependent
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
98
The context of the software system
under test should guide the technical
test analyst.
Code criticality α Level of coverage α
Time & resources
Sometimes the level of coverage
required may be derived from applicable
standards that apply to the software
system.
DO-178 B in USA (ED-12B in Europe)
IEC-61508
Code
Criticality
Level of
Coverage
Time &
Resources
99. Comparisons can Help the Selection
There are 3 ways of comparisons:
Pros and cons general summary
Subsumes
Check-list based
Note that API testing is not included as it is not relate to code.
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
99
100. Techniques Pros & Cons
Technique Pros Cons
Statement
Easy to understand & apply
Can isolate dead code
Low maintenance required
Limited value for decisions & loops
Many paths untested
Ad-hoc testing can achieve ~70% statement
coverage
Decision
Easy to understand & apply
Good cost-benefit ratio
Does not account for condition combinations
Condition No real advantage over decision testing May omit decisions if not carefully done
Decision/Condition
Easy to understand
Good cost-benefit ratio
Needs careful choice of test cases
MC/DC
Less test cases compared to multiple
condition
More difficult to understand
Multiple Condition High thoroughness
High # of test cases
Multiple conditions could have been coded as
consecutive single conditions
LCSAJ Gives different angle of path coverage
Difficult to apply
Highly brittle to code
Path
Very throughout
Good for procedure testing
Practically impossible to achieve high level of
coverage
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
100
101. Subsumes - Which Technique
Implicitly Includes Others?
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
101
Multiple
Condition
MC/DC
Decision
Condition
Decision
Condition
Statement
LCSAJ
Path
103. DO-178 B
Used in an airborne environment
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
103
Failure Level Description Testing Technique
A: Catastrophic
Failure may cause lack of critical function
needed to safely fly or land the plane
MC/DC
B: Hazardous
Failure may have a large –ve impact on safety
or performance
Decision Testing
and MC/DC
optional
C: Major
Failure is significant, but less serious than A or
B
Statement testing
@ minimum
D: Minor
Failure is noticeable, but with less impact than
C
E: No effect failure has no impact on safety
104. IEC-61508
For the functional safety of programmable, electronic,
safety-related systems (automotive, rail, manufacturing
process, nuclear power plants, and machinery)
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
104
SIL Testing Technique
1 (Least critical) Statement and branch coverage recommended
2
Statement coverage highly recommended, branch
coverage recommended
3 Statement and branch coverage highly recommended
4 (most critical) MC/DC highly recommended
105. Testing Multi-Systems
In modern systems, it is rare that all processing will be done on a single
system.
API testing should be instituted anytime some of the processing is going to
be done remotely.
The criticality of the system should determine how much effort should be
invested in API testing.
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
105
106. One Final Word
Dynamic techniques should not be used in isolation.
They should be mixed and combined.
Some techniques can be useful in identifying the test conditions, others
more suited for minimizing test conditions, while others are more suited
for deriving test cases from test conditions.
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
106
107. Combining Techniques Example
1. Using decision tables to identify test conditions from requirements.
Test conditions will be every column in this case.
2. Transform the decision table into a binary decision table.
This may result in the # of test conditions.
3. Identify a binary equation to relate actions to decisions.
4. Apply MC/DC to reduce the # of test conditions.
5. Identify valid/invalid ranges for every condition and action using equivalence
portioning.
6. Apply equivalence partitioning and boundary value analysis to derive test
cases to cover the test conditions.
31/08/2012
ISTQB Advanced Level 2012 - Technical Test
Analyst
107
Editor's Notes
A decision is made by a complex expression that eventually evaluates to TRUE or FALSE.An atomic condition is defined as “the simplest form of code that can result in a TRUE or FALSE outcome.”
The first 2 techniques are covered in the ISTQB CTFL. Starting from the 2nd technique till the 6th technique are based on decision predicates. They derive test cases based on control flow.Except the first 3 techniques, all techniques are rigorous (أدق). Starting from technique 3 to techniques 6, thoroughness (شمولية) of test increases. They require more tests to be defined in order to achieve their intended coverage and to find more subtle instances of this type of defect.
x, D, F, A, and B would each need a test case where it evaluated to TRUE and one where it evaluated to FALSE.(C==D) needs two test cases.(A>B) needs two test cases.(X+Y==-1) needs two test cases.(!(D)==TRUE) needs two test cases.
You can notice in the table that 100% decision coverage is achieved, 100% condition coverage is achieved, and that the independent effect of A, B, and C on the final decision outcome is shown.
4 test cases are needed: TTT, FTT, TFT, TTF.
4 test cases are needed: FFF, TFF, TFF, FFT.
Case 3 is an example of a grouped functionality.Case 4 is an example of a more complex construct where feedback is applied. Case 5 is an example of a bit-wise operation.
There may be a very serious bug issue with short circuiting. If an atomic condition is supplied by a called function and it is short-circuited out of evaluation, then any side effects that might have occurred through its execution are lost.
The code should be modeled as a CFG to deduce the following test cases: A = 11, B = 12, C = 13 A = 11, B = 0, C = 0A = 0, B = 12, C = 13A = 0, B = 0, C =0
LCSAJ 1 can only be executed if forced by a debugger.LCSAJ 2 will execute once at the start of the loop. It is concerned with the first iteration of the loop only. LCSAJ 3 can only be executed if forced by a debugger.LCSAJ 4 will execute only once at the end of the loop. LCSAJ 5 will execute many times in the loop as long as totals[val] != MAXCOUNT at the start of the iteration.LCSAJ 6 will execute if totals[val] == MAXCOUNT.LCSAJ 7 will execute 749 time.LCSAJ 8 will occur once after the loop ends.
Connected components is 1 in our examples. How it should be calculated is beyond our scope.
Create a CFG, calculate C (4), and finally find test cases.
The higher the level, the higher the confidence in the software