News

According to the ISTQB® Effectiveness survey approximately 70% of survey participants attribute a significant part of their certification success to the courses they undertook from accredited training providers. See the full report 

According to the ISTQB® Effectiveness survey there is strong demand for Agile certification throughout the world and across all major industries.

See the full report 

This short presentation answers questions including: what is the ISTQB®? how many questions are there in an Advanced Test Manager exam? what is an "Extension"?

"ISTQB® in a Nutshell" is available for download at the following page: www.istqb.org/about-istqb/istqb-slides 

KEREVAL has joined the program at the Gold partnership level.

According to the ISTQB® Effectiveness survey the new Expert Level certifications are generating a significant amount of interest. See the full report.

Systech Limited has joined the program at the Silver partnership level. 

Advanze Consulting Group has joined the program at the Silver partnership level. See http://www.advanze.se

Linkedin: http://www.linkedin.com/groups/ISTQB-International-Software-Testing-Qualifications-4064826

Join now and stay tuned. See more in http://www.istqb.org/ (Click icons in the top-right corner of our website).

According to the ISTQB® Effectiveness survey the ISTQB® Foundation Level certification exams are seen as providing a reliable assessment of candidate knowledge. See the full report here.

The ISTQB® General Assembly meeting of San Francisco on 28 March approved the ISTQB® Expert Level Syllabus Test Automation engineering, version Beta 2014 to be released.

According to the ISTQB® Effectiveness survey Test Engineers and Test Managers alike are highly satisfied with the ISTQB® CTFL certifications and happy to recommend these to their colleagues.
See the full report here

The ISTQB^® General Assembly meeting of San Francisco on 28 March approved the ISTQB^® Glossary Version 2.3 to be released.

According to the ISTQB® Effectiveness survey the majority of Test Managers believe that participating in the ISTQB® certification scheme will positively impact testing quality in their projects and will enable them to provide a positive career path to their employees. See the full report here

The ISTQB^® General Assembly meeting of San Francisco on 28 March approved the admission of Ethiopia as a new ISTQB^® Member.

According to the ISTQB® Effectiveness survey approximately 70% of Test Managers consider it important to obtain Advanced Level certifications, and this opinion is shared by 63% of Test Engineers. See the full report.

Teamwork is a fundamental principle in Agile development. Agile emphasizes the whole-team approach consisting of developers, testers, and business representatives working together. The following are team organizational and behavioral best practices in Scrum teams:de in the team, how to organize themselves and how to divide their work. There could be teams with only developers (also doing all their needed testing), only one tester, or two or more dedicated testers. It is an advantage having two or more testers as they can work more efficiently together in so called “pair testing”.

• Cross-functional: The team works efficiently together on the test strategy, test planning, test specification, test execution, test evaluation, and test results reporting.
• Self-organizing: The team may consist only of programmers, but, as noted in Section 2.1.5, ideally there would be one, two, or more testers. It is an advantage to have two or more testers, as they can do pair testing.
• Collocated: Testers sit together with the programmers and the product owner.
• Collaborative: Testers collaborate with their team members, other teams, the stakeholders, the product owner, and the scrum master.
• Empowered: Technical decisions regarding design and testing are made by the team as a whole (programmers, testers, and scrum master), in collaboration with the product owner and other teams if needed.
• Committed: The tester is committed to question and evaluate the product's behavior and characteristics, with respect to the expectations and needs of the customers and users.
• Transparent: Programming and testing progress is visible on the Agile task board (see Section 2.2.1).
• Credible: The tester must ensure the credibility of the strategy for testing, its implementation, and execution, otherwise the stakeholders will not trust the test results. This is often done by providing information to the stakeholders about the testing process.
• Open to feedback: Feedback is an important aspect of being successful in any project, especially in Agile projects. Retrospectives allow teams to learn from successes and from failures.
• Resilient: Testing must be able to respond to change, like all other activities in Agile projects.

  These best practices maximize the likelihood of successful testing in Scrum projects.

The text above is a sample from the upcoming Agile Tester Extension that will be released in early 2014. Please note that Agile Tester Extension is in its Beta phase, which means that its content may change. Visit www.istqb.org to get latest information.

A software system can and has to be tested on different levels of abstraction. Typical such levels are (see [ISTQB Foundation Level Syllabus, 2011, Chapter 2.2]): Component Testing, Integration Testing and System Testing. These levels of abstraction exist for every product/system, regardless whether the system was or is build following a traditional development model or an agile development approach. As a result a project team creates and maintains test cases on each of these levels. The interfaces to be called or stimulated by a specific test case can look quite different depending on the test level of the specific test case. So if a test case is automated the test tool in use must be appropriate for the level specific test interface. Usually component and integration level tests are automated using so called 'Unit Testing Frameworks' (see [Meszaros 07]). On system level functional tests are often automated using so called 'GUI-Testing Tools' to simulate interactions of a system end user with the system via the systems Graphical User Interface (GUI). But depending on the systems technical architecture and the test type (e.g. performance test) it could be necessary or possible to execute a system level test case via the systems API (e.g. a service API) rather than via its GUI and thus to automate such test cases using a specialized testing tool (e.g. for performance testing) or even to use a Unit Testing Framework (interfacing the system level API).

The text above is a sample from the upcoming Agile Tester Extension that will be released in early 2014. Please note that Agile Tester Extension is in its alpha phase, which means that its content may change. Visit www.istqb.org to get latest information.

Nokia Solutions and Networks Oy has joined the program at the Platinum partnership level. 

Métodos y Tecnologìa de Sistemas y Procesos S.L. (MTP) has joined the program at the Platinum partnership level. 

Q-leap S.A. has joined the program at the Silver partnership level. 

Test Driven Development (TDD) is more a development technique than a test technique. A developer may perform low level testing using the Test Driven Development, while a tester or product owner performs high level testing using Acceptance Test Driven Development (ATDD). Behavior Driven Development (BDD) can include both low level and high level tests.

Test Driven Development

Test driven development is a technique used to develop code guided by automated test cases. It is also known as test first programming, since test cases are written before the code. Test driven development includes:

• Add a test that captures the programmer’s concept of the desired functioning of a small piece of code
• Running the test, which should fail, since the code doesn’t exist
• Writing the code and running the test in a tight loop until the test passes
• Refactoring the code after the test is passed
• Repeating this process for the next small piece of code, running the previous tests as well as the added tests

The test cases written are primarily unit level and typically code-focused (white-box), though tests may also be written at the integration or system levels. Test driven development was popularized by Extreme Programming [Beck02] but is used in other agile methodologies and sometimes in sequential lifecycles. This development approach allows fixing coding defects as soon they are introduced.

Test driven development reduces the introduction of defects by helping the developer focus on the clearly defined expected results. The tests serve as a form of executed design specification for future maintenance efforts. The tests are automated and are used in continuous integration.

The text above is a sample from the upcoming Agile Tester Extension that will be released in early 2014. Please note that the Agile Tester Extension is in its beta phase, which means that its content may change. Visit www.istqb.org to get latest information.

Sogeti Belgium NV has joined the program at the Gold partnership level. 

Make it Work (Tecomoni Srl) has joined the program at the Silver partnership level.

Make it Work (Tecomoni Srl) has joined the program at the Silver partnership level.

In addition to Foundation and Advanced Level exams, Expert Level Test Manager exams will be offered during ASTQB Conference 2014!

These Expert Level exams will be held for the first time ever. See more information at the ASTQB Software Testing Conference page.

MTA S.p.A. has joined the program at the Silver partnership level.

The first Expert Level course "Improving the Testing Process - Module Assessing Test Processes" has started in Netherlands. See more information in www.bntqb.org

Telerik AD has joined the program at the Gold partnership level.

The agile project test strategy or test approach (the distribution of the test effort and coverage over the items to be tested) is defined during the planning event and included in the backlog. For example, during the planning stage, the agile team estimates, with the aid of planning poker, the size (often estimated in story points) for each story of a product backlog. Planning poker is the ideal way to formulate relative estimation size; i.e., where the estimations are related to one another. A reliable estimation is made by the whole team. By means of cards, everyone allocates story points to the estimated size of a backlog item. Aspects such as effort, complexity and the thoroughness of testing (in relation to the product risk) play a role in the estimation. Therefore, it is advisable to include the risk classification of a backlog item - particularly in the case of user stories - in addition to the priority specified by the product owner, before the planning poker is initiated. Differences in estimates are discussed, after which the card-playing is repeated until consensus arises. The discussion that produces this means of evaluation ensures that nothing is forgotten and that everyone is involved. This ensures a reliable estimation of the work — across the various disciplines — which is needed to complete a product item and to boost collective knowledge of what has to be done.

See also Kelly Waters article about this topic:

http://www.allaboutagile.com/estimating-in-agile-development/

The text above is a sample from the upcoming Agile Tester Extension that will be released in early 2014. Please note that Agile Tester Extension is in its alpha phase, which means that its content may change. Visit www.istqb.org to get latest information.