Practice Quiz Links

Here are some websites that have practice quizzes for the ISTQB certification exam.
Most of these have full practice tests meant to simulate the number of tests on the real test.  There are supposed to be 40 questions on the real test and you need to get at least 65% to pass.


http://istqb.patshala.com/
This site has several full practice tests, as well as tests for the individual chapters for the ISTQB book although they are labeled as the main concepts that each chapter teaches as opposed to Chapter 1, 2, 3, 4, 5, 6. 
CH 1: Fundamentals of Testing
CH 2: Testing through the software life cycle
CH 3: Static Techniques
CH 4: Test design techniques
CH 5: Test Management
CH 6: Tool support for testing
These exams don't have a time limit so there is plenty of time to take notes or look for the answers if you're not sure what the right answer is.  However on the real test you won't be allowed to look for answers so you probably shouldn't do it too often for practice tests.


http://www.testingexcellence.com/istqb-quiz/istqb-foundation-practice-exam-1/
This has 2 full practice exams and a bunch of other related practice tests for stuff like testing fundamentals, management, and white box testing.  The practice exams aren't timed on this site so you can take your time.

Code Metrics and Cyclomatic Complexity

Code Metrics are a tool for static testing it has a section about it in Section 3.3.2 in chapter 3 of the ISTQB book where they also briefly introduce the concept of Cyclomatic Complexity.  Since questions on Cyclomatic Complexity and code metrics are found in practice tests I thought it would be good to know.
Code metrics are the measurement scales and methods used in software testing, and Cyclomatic complexity is one example of a code metric used in static testing.  When performing static code analysis, code metrics can be used to calculate numerous attributes of the code such as comment frequency, depth of nesting, cyclomatic number and number of lines of code. Code metrics can not only compute these attributes but can also be done as the design and code are being created and as changes are made to a system, to see if the design or code is becoming bigger, more complex and more difficult to understand and maintain.
Cyclomatic complexity is a code metric used on static testing when the testers take all of the expected statements and decisions and compile them into a diagram or map of the system.  It involves an equation defined by the ISTQB book as L-N+2P. L is the number of edges or lines connecting nodes, N is the number of nodes or steps in the process flow reached when decisions are made, P is the number of connected components (usually the entire process is connected and therefore this is usually equal to 1) and example of this is below.



In this example there are 9 edges or lines, 8 nodes, and the entire thing is connected meaning P=1
the cyclomatic complexity equation would look like: 9-8+2*1=3

Designing Tests

For this post I have decided to write about how to design tests.  Testers design tests whether they are using Static or dynamic testing techniques.  To design a test you need 3 things according to ISTQB test conditions, test cases and test procedures (Scripts).  Each of these things are specified in their own documents created from information given by the developers and the tester's own interpretations of the provided info.  Testing is also designed and executed with varying degrees of formality depending on the customer's or testing team's preferences.


The designing process usually begins with the testers looking through something that they can derive test info from which is also known as a test basis.  A test basis can be many different things from an experienced user's knowledge, a business process, system requirements, specifications or the code.  Through test basis we find test conditions or the things we could test, because test conditions could come from anything they are usually vague.


Unlike test conditions, test cases are more specific.  Test cases will mean entering specific inputs into a system, and will also require some understanding of how the system works.  This mean knowing what the system should do and therefore the correct behavior of the system which is also referred to as a Test Oracle.  After choosing an input the tester needs to figure out what the expected result is and put it into the test case.  Expected results are what appears on the screen in response to the input values as well of changes to data or states and consequences.


The next and last step of the process is to put the test cases into a way that makes sense and the steps needed to run the test.  This is a test procedure or test script.  These procedures are then put into an execution schedule to determine which procedures are run first and whom runs them.


There are also many different categories of design techniques that I will get into later.

White Box vs. Black Box testing

Black box and White box testing are mentioned a lot in Chapter 4 of the ISTBQ book.  The text book definition of black box in the ISTQB book states  that it is "testing either functional or non-functional, without reference to the internal structure of the component or system".  Basically Black box testing is when a tester knows what the software does from having access to things like requirements, but has no knowledge as to how the software does these things, or anything about the branching logic.  Black box testing tends to involve a lot of exploratory testing as the tester goes through the system to understand how the system works.  Techniques of black box testing include but are not limited to equivalence partitioning, and boundary value analysis, the use of data tables, and state transition testing


Meanwhile White box testing is defined as "Testing based on an analysis of the internal structure of the component or system".  In other words this type of testing is when the tester knows all the details about not only what the software supposed to do, but how it works and does what it's supposed to do.  These kinds of tests allow tester to increase their test coverage by finding new tests that haven't been created.  It uses techniques like statement coverage, decision coverage, and branch coverage.


Black box testing is good when the tester is starting to run tests on a software they know little about, while white box testing is good for going more in depth into understanding the system.