What is Testing? – Foundation Level 2018 ISTQB

1.1 What is testing?

What is testing according to ISTQB (International Software Testing Qualification Board) Syllabus?

I’ll go through each section and each snip part of the syllabus with you so you can process the information rather than simply read it.

“Software systems are an integral part of life, from business applications (e.g., banking) to consumer products (e.g., cars). Most people have had an experience with software that did not work as expected. Software that does not work correctly can lead to many problems, including loss of money, time, or business reputation, and even injury or death. Software testing is a way to assess the quality of the software and to reduce the risk of software failure in operation.” – ISTQB 2018 Foundation Level Syllabus

We all use software in one way or another, even if we don’t use a computer or a mobile phone. Most of the day-to-day life these days is really on the use of software.

And I bet each one of us has at least a dozen of examples of when a software system (program, web app, mobile app, etc) has not worked properly.

When experiencing a situation such, can be a waste of time, waste of money and even an injury or worst death.

The way to mitigate this situation is by software testing. This course is all about. getting you in a position to get yourself certified so there’s consistency throughout the industry.

I’ll mention this quite a lot throughout any of my content sharing here: Knowledge + Process = Results

Continuing on the breakdown of the foundation level 2018 ISTQB syllabus…

“A common misperception of testing is that it only consists of running tests, i.e., executing the software and checking the results. As described in section 1.4, software testing is a process that includes many different activities; test execution (including checking of results) is only one of these activities. The test process also includes activities such as test planning, analyzing, designing, and implementing tests, reporting test progress and results, and evaluating the quality of a test object.” – ISTQB 2018 Foundation Level Syllabus

Just sitting tight waiting for testing, and then starting the activity when the change is implemented is not the right approach. There are many activities involved to achieve success in testing.

Test Planning

Verify the mission of testing. Monitor, check progress and take action.

Analysing and Designing Tests

Test analysis and test design are the testing objectives to create test conditions and test design as early as possible.

Implementing Tests

It is the activity where test procedures or scripts are in order, the environment is set up and tests are ready to run.

Reporting Test Progress and Results

This is the activity where test execution is assessed against the defined objectives.

Evaluating The Quality

The test closure activities occur at the project milestones such as release, completion, cancellation or maintenance release has been complete.

“Some testing does involve the execution of the component or system being tested; such testing is called dynamic testing. Other testing does not involve the execution of the component or system being tested; such testing is called static testing. So, testing also includes reviewing work products such as requirements, user stories, and source code.” – ISTQB 2018 Foundation Level Syllabus

Dynamic Testing

It is when you are using a part of an entire piece of software. When you get to access the code, a component, or the recently developed component in a dev or test environment. You get to see, click on things, and move around the application (software, app, web app, etc).

Kind of testing that exercises the program with some test data. Dynamic testing is performed by executing software under test and comparing actual and expected results.

Static Testing

Testing where code is not exercised; document specification analysis, review, even code itself. Can be done as a review by humans carrying out a manual examination of documents or static analysis of the code and software models by using automation tools.

This is when you get involved at the early stages of the development, in discussions with the development team, the requirements are brought into the discussion, where the most common tester question is, why, how, and what is asked, this is where you got. to think about, how am I going to test this. During the requirement review process, user stories are designed, breaking them down into smaller chunks, or pieces for the team to collaborate on what to do and in which stages. It is a great opportunity for testers to participate and contribute to an early solution even before it is coded.

The other part of static testing is by reviewing the code developed by the developer, it can be done on your own or by peer-reviewing, as it is talked through, it can come up with bugs, and code improvements. It is possible to find issues at this stage even before the code is executed.

“Another common misperception of testing is that it focuses entirely on verification of requirements, user stories, or other specifications. While testing does involve checking whether the system meets specified requirements, it also involves validation, which is checking whether the system will meet user and other stakeholder needs in its operational environment(s). Test activities are organized and carried out differently in different lifecycles (see section 2.1).” – ISTQB 2018 Foundation Level Syllabus

1.1.1 Identify typical objectives of testing

When working on a software development project, I would say of any size, but of course, the level of depth will vary depending on time constraints, budget and experience, I guess that’s the reason why the ISTQB Foundation Level 2018 include the word “…may include” in the statement with the list of the objectives.

You have to be mindful of the evaluation of the work you are going to get involved with, even before you start the dynamic tests when reading and understanding the requirements, getting involved in the collaboration of the user stories, the design and even in the code.

By getting involved at the early stages you will be in a better position to verify the specified requirements have indeed been fulfilled.

You must check the test object has been completed and validate if the system works as per users’ and stakeholders’ expectations.

Throughout the development and milestones stages, testing helps build confidence in the level of quality of the test object.

Finding defects and failures reduce the level of risk and getting inadequate software released for the users.

Stakeholders will rely on the information you are providing to be able to make informed decisions, especially on the quality of the system being delivered to the users.

Another important part of the testing process is to confirm the system complies with contractual, legal or regulatory requirements or standards, also compliance with such requirements and standards.

“For any given project, the objectives of testing may include:

• To prevent defects by evaluating work products such as requirements, user stories, design, and code
• To verify whether all specified requirements have been fulfilled
• To check whether the test object is complete and validate if it works as the users and other stakeholders expect
• To build confidence in the level of quality of the test object
• To find defects and failures thus reduce the level of risk of inadequate software quality
• To provide sufficient information to stakeholders to allow them to make informed decisions, especially regarding the level of quality of the test object
• To comply with contractual, legal, or regulatory requirements or standards, and/or to verify the test object’s compliance with such requirements or standards “

ISTQB 2018 Foundation Level Syllabus

What is in the context of testing? What is it really you are testing and which phase of the development of the system is at which? Those questions also are important to determine what approach you are going to take to find as many failures as possible and if the system works as expected and what to say to stakeholders from that point on.

The level of testing can be defined as:

• When at the component code level a good strategy is to create as many unit tests as possible during the component test and subsequently the integration tests are much better to early encounter any possible underlying issues with the code. That could be one of the main objectives.
• When in the acceptance testing the system customer verifies all requirements, meets all the expectations, or provides sufficient information to stakeholders about the risk(s) of that particular release. That could be also one of the main objectives.

“The objectives of testing can vary, depending upon the context of the component or system being tested, the test level, and the software development lifecycle model. These differences may include, for example:

• During component testing, one objective may be to find as many failures as possible so that the underlying defects are identified and fixed early. Another objective may be to increase code coverage of the component tests.
• During acceptance testing, one objective may be to confirm that the system works as expected and satisfies requirements. Another objective of this testing may be to give information to stakeholders about the risk of releasing the system at a given time.”

ISTQB 2018 Foundation Level Syllabus

1.1.2 Differentiate testing from debugging

Debugging is a process used to identify the causes of bugs in code and correct them.

Testing is the exploration of the system in order to find defects.

“1.1.2 Testing and Debugging Testing and debugging are different. Executing tests can show failures that are caused by defects in the software. Debugging is the development activity that finds, analyzes, and fixes such defects. Subsequent confirmation testing checks whether the fixes resolved the defects. In some cases, testers are responsible for the initial test and the final confirmation test, while developers do the debugging, associated component and component integration testing (continuous integration). However, in Agile development and in some other software development lifecycles, testers may be involved in debugging and component testing. ISO standard (ISO/IEC/IEEE 29119-1) has further information about software testing concepts.”

ISTQB 2018 Foundation Level Syllabus

Differences Between Testing and Debugging

The process of identifying errors in a system or software and then correcting them is called “testing”. Debugging, on the other hand, is the process of finding bugs during testing and fixing them. Here are some differences between debugging and testing- read ahead to know more!

What is Testing?

Software testing is the process of verifying and validating that an application or software is free of bugs, meets all the technical requirements, abides by development and design rules, and meets every user requirement. Testing ensures that your intended software/application does not have any bugs or malfunctions efficiently while handling all boundary cases (unusual conditions) as well as exceptional cases (rare events).

What is Debugging?

The process of debugging software or applications is very tedious and complex. It involves identifying, analyzing, and solving errors in every stage of execution. Debugging begins when the intended software fails during proper functionality. The end goal is to solve the problem through analysis and successfully test it with no remaining errors present on any level of operation.

Debugging works by pinpointing bugs and then fixing them; one bug at a time-comparing expected results against actual outcomes to see if there are discrepancies (errors). If an error does occur while performing this process we need to use different methods like adding more code snippets, modifying existing ones for better performance or designing alternative algorithms that will make these functions work smoothly without glitches among other things.

Debuggers often come across “impossible” errors which they cannot debug because their cause cannot be found even after intensive troubleshooting efforts have been made – what programmers call structural defects or design flaws.”.

If you prefer to watch the whole video about this section in one go instead of parts of the video as I have embedded them above, go and watch it here…

Don’t forget to subscribe, like and share. It will support this channel, will help others and will motivate me to create even more content for everyone.