Kimberly's ISTQB (International Software Testing Qualifications Board) Overview

---

Here's A Basic Overview Of Software Testing, Which is Of Course Needed, and is The Foundation Necessary For ISTBQ

Appropriate test techniques, applied with appropriate level of test expertise, in appropriate test levels, and at appropriate points in the software development cycle.

Having testers involved in requirements reviews or user story refinement could detect defects in the work products.

Having testers work closely with system designers while the system is being designed can increase each party's understanding of the design and how to test it.

Having testers work closely with developers while the code is under development can increase each party's understanding of the code and how to test it.

Having testers verify and validate the software prior to release can detect failures that might otherwise have been missed, and support the process of removing defects that caused the failures (i.e., debugging).

a. What Are The Tasks Of A Tester?

• Review and contribute to test plans.

• Analyze, review, assess requirements, user stories, and acceptance criteria, specs, and models for testability (i.e., the test basis).

• Identify and document test conditions, capture traceability between test cases, test conditions, and the test basis.

• Design, set up, and verify test environment(s), often coordinating with system administration and network management.

• Design and implement test cases and test procedures.

• Prepare and acquire test data.

• Create the detailed test execution schedule.

• Execute tests, evaluate the results, and document deviations from expected results.

• Use appropriate tools to facilitate the test process.

• Automate tests as needed.

• Evaluate non-functional characteristics such as performance efficiency,reliability, usability, security,compatibility, and portability.

• Review tests developed by others.

b. Causes of Software Defects

Time pressure

Human error

Inexperienced or otherwise insufficiently skilled project participants

Miscommunication

Complexity of code and/or technologies used

New or unfamiliar technologies

c. Importance of Test Organization -

• A certain amount of independence makes the tester more effective at finding defects/failures. Degrees of independence from lower to higher level include:

No independent testers; the only form of testing available is developers testing their own code.

Independent developers or testers within the development teams or the project team; this could be developers testing their colleagues' products.

Independent test team or group within the organization, reporting to project management or executive management.

Independent testers from the business organization or user community, or with specializations in specific test types such as usability, security, performance,regulatory/compliance, or portability.

Independent testers external to the organization, either working on-site (insourcing) or off-site (outsourcing).

d. The Review Process

• Roles And Responsibilities Of A Formal Review

Facilitator (Moderator):

• • Ensures effective running of review meetings (when held).
  • Mediates, if necessary, between the various points of view.
  • Is often the person upon whom the success of the review depends.

Review Leader:

• • Takes overall responsibility for the review.
  • Decides who will be involved and organizes when and where it will take place.

Reviewers:

• • May be subject matter experts, persons working on project, stakeholders with interest in work product, and/or individuals with specific technical or business backgrounds.
  • Identify potential defects found found in the work product under review.
  • May represent different perspectives (e.g., tester, programmer, user, operator, business analyst, usability expert, etc.).

Scribe (Recorder): *Collates potential defects found during the individual review activity.

• • Records new potential defects, open points, and decisions from the review meeting (when held)

So… What Is ISTBQ?

The International Software Testing Qualifications Board (ISTQB) is a software testing certification board that operates internationally. Founded in Edinburgh in November 2002, the ISTQB is a non-profit association legally registered in Belgium.

• There are three levels as follows:
  • Foundation level
  • Advanced level
  • Expert level

Why is the ISTBQ Important?

• ISTBQ certification is important for the following reasons, to name a few:
  • Increase one's marketability throughout the industry.
  • Have greater career opportunities and increased earning potential.
  • Can add the "ISTQB® Certified Tester" logo and credential to a resume.
  • Being recognized as having subscribed to a Code of Ethics.

How long is the ISTBQ exam?

• • 60 minutes

How is the exam comprised?

• • The Foundation Level exam comprises 40 multiple-choice questions, with a scoring of 1 point for each correct answer, a pass mark of at least 65% (26 or more points) and a duration of 60 minutes (or 75 minutes for candidates who have been allowed a time extension for disability or language reasons.

• • Advanced Level “Security Tester” has 45 questions to be completed in two hours. Advanced Level “Test Automation Engineer” has 40 questions to be completed in 1.5 hours (90 minutes).

• • Each Expert Level part exam has a duration of 135 minutes,duration about 3 hours(with an additional 34 minutes that can be granted.)

Static Vs. Dynamic Testing & Black Box/White Box Testing

https://www.codeproject.com/Tips/351122/What-is-software-testing-What-are-the-different-ty

• Main distinction is that static testing finds defects in work products directly; rather than identifying failures caused by defects when the software is run.

• Dynamic testing is testing that is performed when the system is running. Static testing is performed when the system is not running. Dynamic testing can be Black Box or White Box Testing.

• Under Static Testing code is not executed. Rather it manually checks the code, requirement documents, and design documents to find errors. Hence, the name "static". Under Dynamic Testing code is executed. It checks for functional behavior of software system , memory/cpu usage and overall performance of the system. Hence the name "Dynamic".

• Static/Dynamic refers to the state of system under test (running/dynamic, or stopped/static).

• Black-box testing probes the outside of a running system without any knowledge of its internal implementation. A lot of functional testing falls into this category.

• Some black-box testing is dynamic, as you can test a system while it is running without any knowledge of its internals (e.g., when using the end-user interface or public API).

• White-box testing can be done dynamically (for example, security testers with knowledge of the internal workings of the system performing penetration testing) or statically, such as running tools like AppScan, FxCop, JavaCop, etc. looking for guideline violations and potential security vulnerabilities in the source code.

*Compared to Dynamic Testing, typical defects that are easier and cheaper to find and fix through Static Testing include:

• • Requirement Defects

inconsistencies ambiguities contradictions omissions inaccuracies redundancies

• • Design Defects

inefficient algorithms or database structures high coupling low cohesion

• • Coding Defects

variables with undefined values variables that are declared but never used unreachable code duplicate code

• • Deviations From Standards* e.g., lack of adherence to standards

• • Incorrect Interface Specifications* e.g., different units of measurement used by the calling system than by the called system

• • Security Vulnerabilities* e.g., susceptibility to buffer overflows

• • Gaps Or Inaccuracies In Test Basis Traceability Or Coverage* e.g., missing tests for an acceptance criterion

Some Testing Techniques

• Usually Black Box Testing is considered Dynamic Testing. When we think of software testing, we usually think of people running the code and recording problems they find. This is classic Dynamic Black-Box Testing. However, there is Black-Box Static Testing. When you examine the spec or requirements looking for errors, this is Static, Black-Box Testing. Read the spec as if you're the customer - anything not make sense? Compare the spec to industry or company guidelines - any violations? Read the requirements to make sure each one is:

• Correct

• Feasible

• Necessary

• Prioritized

• Unambiguous

• Modifiable

• Complete

• Verifiable

Black Box Testing Techniques - aka Behavioral or Behavioral-based.

Equivalence Partition

• • It divides inputs into ranges (class or partition) where all the elements of a particular range are expected to behave in the same way.

Boundary Value Analysis (BVA)

• • BVA Tests on boundaries that the defect can lie near the boundaries as well
  • Values in valid range are 'valid boundary values'
  • Values from invalid range are 'invalid boundary values'
  • Boundary values are calculated as LB, LB-1, RB, RB+1 where LB and RB are the lower and upper boundaries given in the scenario

State Transition Testing

• • Exhibits various states of scenario/system and possible transition between them
  • The representation is called 'State Transition Diagram (STD)'
  • An STD shows all Valid Transitions
  • An STD consists of pair of transition between two states
  • If the pair is missing between two states, then the missing transition(s) is/are called 'Invalid Transitions'

Decision Table Testing

• • Captures system requirements that contain logical conditions
  • The specs are analyzed, and conditions and actions of the system are identified in a tabular form
  • The input conditions and actions are most often stated in a way that they must be true or false

Use Case Testing

• • Use cases describe interaction between actor and system
  • It's helpful for deriving test cases for the Integration testing, System testing, and Acceptance testing

• White Box Testing Techniques (aka Structural or Structural-based)White-box testing (also known as clear box testing, glass box testing, transparent box testing, and structural testing) is a method of software testing that tests internal structures or workings of an application, as opposed to its functionality (i.e. black-box testing).

• Statement Testing & Coverage
  • Tests the statement for a given fragment of code

• Decision Testing & Coverage
  • Also known as Branch Testing or Branch Coverage
  • Stronger than Statement Testing
  • 100% Decision Testing guarantees 100% Statement Coverage; but not vice versa

• Experience Based Techniques (EBT test conditions, test cases, test data, derived from a test basis that may include knowledge and experience of testers, developers, users and other stakeholders)EBT test techniques uses tester's skill, intuition and experience of similar applications and technologies. Useful in identifying special tests which aren't easily captured by formal techniques. These techniques are usually applied after applying formal techniques.

Error Guessing

• • Requires knowledge of defects and experience with application
  • Enumerates possible defects and designs tests that attack these defects
  • This systematic approach is: 'Fault Attack'
  • The defect/failure list can be built based on experience, typical defects, and failure data
  • Updating the result of execution and evaluating further the need of tests and their execution
  • Error Guessing is based on: How application has worked in the past, what types of mistakes the developers tend to make, and Failures that have occurred in other applications

Exploratory Testing

• • Allocation of a part of the application which is supposed to be explored
  • Informal (not pre-defined) tests are designed, executed, logged, and evaluated dynamically during test execution
  • Doesn't require preparation of test cases, instead a random or ADHOC approach is followed
  • 'Test Charter' containing test objectives are the basis to be followed for execution
  • The execution are 'time boxed' with a range between 30 minutes to 120 minutes; depending on size of application
  • Executions are called 'test sessions' or 'time boxed test sessions'

Checklist Based Testing

• • Testers design, implement, and execute tests to cover test conditions found in a checklist
  • As part of analysis, testers create a new checklist or expand an existing checklist, but testers may also use an existing checklist without modification
  • Checklists can be built based on experience, knowledge about what's important for the user, or an understanding of why and how software fails
  • In the absence of detailed test cases, checklist-based testing can provide guidelines and a degree of consistency
  • As these are high-level lists, some variability in the actual testing is likely to occur, resulting in potentially greater coverage but less repeatability

a. Test Planning And Estimation

A test strategy provides a generalized description of the test process, usually at the product or organizational level. Common types of test strategies include:

• Analytical (risk-based testing)
  • Refers to testing of those technologies and initiatives that involve data that is too diverse and fast-changing.

• Model-based
  • An application of model-based design for designing; and optionally also executing artifacts to perform software testing or system testing. Test cases derived from such a model are functional tests on the same level of abstraction as the model.

• Methodical (predefined, taxonomy based)
  • A test strategy whereby the test team uses a predetermined set of test conditions such as a quality standard, a checklist, or a collection of generalized, logical test conditions which may relate to a particular domain, application or type of testing.

• Process Compliant (Standard compliant)
  • Also know as Conformance Testing, it is a nonfunctional testing technique which is done to validate whether the system developed meets the organization's prescribed standards or not. There is a separate category of testing known as “Non-Functional Testing”.

• Directed (Consultative)
  • This testing technique uses consultations from key stakeholders as input to decide the scope of test conditions as in the case of user directed testing; against which they want the application to be tested.

• Regression Averse
  • Testing of a previously tested program following modification to ensure that defects have not been introduced or uncovered in unchanged areas of the software, as a result of the changes made. It is performed when the software or its environment is changed.

• Reactive (ongoing)
  • Testing that dynamically responds to the actual system under test and test results being obtained. Typically reactive testing has a reduced planning cycle and the design and implementation test phases are not carried out until the test object is received.

b. Test Planning and Estimation -

There are a number of estimation techniques used to determine the effort required for adequate testing. Two of the most common are:

Metrics-based. This means estimating the test effort based on metrics of former similar projects, or based on typical values.

Expert-based. Estimating the test effort based on the experience of the owners of the testing tasks or by experts.

The testing effort may be based on a number of factors:

Characteristics of the product.

Characteristics of the development process.

People characteristics.

Test results.

c. Test Planning and Estimation - Test Execution Schedule

• Once the various test cases and test procedures are produced and assembled into test suites, the test suites can be arranged in a test execution schedule that defines the order in which they are to be run.

• The test execution schedule should take into account such factors as prioritization, dependencies, confirmation tests,regression tests, and the most efficient sequence for execution of tests.

• Ideally, test cases would be ordered to run based on their priority levels, usually by executing the test cases with the highest priority first.

• But this practice may not work if the test cases have dependencies or the features being tested have dependencies

• If a test case with a higher priority is dependent on a test case with a lower priority test case, the lower priority test case must be executed first.

ISTBQ Advanced: Transitioning Manual Testing To Automation (overview)

Regression testing provides a great opportunity to use automation. A regression test bed grows as today's functional tests become tomorrow's regression tests. It's a matter of time before the number of regression tests becomes greater than the time and resources available to a traditional manual test team. Here are questions to ask in developing steps to prepare to automate regression tests:

• How frequently should the tests be run?
  • Tests that are executed often as part of regression testing are the best candidates for automation. These tests have already been developed , exercise known SUT functionality, and will have their execution time reduced a great deal through use of automation.

• What is each test's execution time, for the regression suite?
  • The time it takes to execute any given test or an entire test suite is an important parameter in evaluating the value of implementing automated testing within regression testing. One option is to start by implementing automation on time-consuming tests. This will allow for each test to run quicker and more efficiently, while adding additional cycles of automated regression test execution.

*Is there functional overlap between tests?

• • When automating existing regression tests, it's a good practice to identify and functional overlap that exists between and among test cases and, where possible, reduce that overlap in the equivalent automated test. This will bring further efficiencies in the automated test execution time. That is significant; as more and more automated test cases are executed.

• Do tests share data?
  • Tests do often share data. This can occur when tests use the same record of data to execute different SUT functionality. In an automated test, data which is shared should; where possible and feasible, be stored and accessed from a single source to avoid duplication, or introduction of errors.

• Are the tests dependent on each other?
  • When executing complex regression test scenarios, one test may have a dependency on one or more other tests.

• What preconditions are required before test execution?
  • Often a test can't be executed prior to setting initial conditions. These conditions may include selecting the correct database or the test data set from which to test, or setting initial values or parameters. Many of these initialization steps that are required to establish a test's precondition can be automated.

• What percent of SUT (system under test) coverage do the tests represent?
  • Every time tests are executed, part of an SUT's functionality is exercised. In order to ascertain overall SUT quality, tests need to be designed in order to havethe broadest and deepest coverage.

• Do the tests currently execute without failure?
  • Before converting a manual regression test into an automated test, it's important to verify that the manual test operates correctly. This provides the proper start point to ensure successful conversion to automation.

* What should happen when regression tests take too long?

• • The set of regression tests for an SUT can become very large, so large that the test set can't be completely executed overnight; or over the weekend. In that case, concurrent execution of test cases is a possibility if multiple SUTs are available.

ISTBQ Expert Level Overview

• To obtain Expert Level certification, candidates must have:

The Foundation Certificate.

An Advanced Certificate depending on the Expert Module desired. passed the Expert Level Exam.

At least 5 years of practical testing experience.

At least 2 years of industry experience in the specific Expert Level topic.

Ways To Study For The ISTBQ Exam

Watch Instructional Videos:

• • Instructional ISTBQ Videos

Thoroughly study the material.

• • Link to further reading

Practice on training papers many times.

• • Tips on Practice for ISTBQ

Carefully read every question and its options for several times to make sure everything is clear. Sometimes the placement of one key or 'trick' word can change the meaning of the whole question on the exam, therefore making the correct answer more obvious.

Read every option completely before deciding on an answer.

A Sample Multiple Choice Similar To Ones In The Exam Is Given Below:

• Black Box Techniques - Use Case Testing

QUESTION: Which of the following statements about the benefits of deriving test cases from use cases are True, and which are False?

1. Deriving test cases from use cases is helpful for system and acceptance testing. B. Deriving test cases from use cases is helpful only for automated testing. C. Deriving test cases from use cases is helpful for component testing. D. Deriving test cases from use cases is helpful for integration testing.

ANSWER SET:

1. A and D are True; B and C are False.
2. A is True; B, C, and D are False.
3. B and D are True; A and C are False.
4. A, C, and D are True; B is False.

THE ANSWER: 1. A and D are True; B and C are False.

Another Example of Q & A that is Typical To Those on The Exam:

*A fitness app measures the number of steps that are walked each day and provides feedback to encourage the user to keep fit.

The feedback for different numbers of steps should be:

• • Up to 1000 -Couch Potato!
  • Above 1000, up to 2000 -Lazy Bones!
  • Above 2000, up to 4000 -Getting There!
  • Above 4000, up to 6000 -Not Bad!
  • Above 6000 -Way to Go!

QUESTION: Which of the following sets of test inputs would achieve the highest Equivalence Partition coverage?

A

0, 1000, 2000, 3000, 4000

B

1000, 2001, 4000, 4001, 6000

C

123, 2345, 3456, 4567, 5678

D

666, 999, 2222, 5555, 6666

THE ANSWER: D: 666, 999, 2222, 5555, 6666

-- KimberlyTucker - 29 May 2020