Istqb

Ctfl

Test

Testing

Manual Testing

ISTQB CTFL Syllabus Uncovered: Your Ultimate Guide Vol1

1.1. What is Testing?

Software systems are a big part of our daily lives. Sometimes, we’ve all dealt with software that didn’t work properly. When software doesn’t work as it should, it can cause problems like losing money, wasting time, damaging a business’s reputation, and in rare cases, even causing harm or accidents.

Software testing is a way to make sure software works well and reduces the chances of it failing when used. Software testing isn’t just about running tests to check if the software is okay. It includes various activities and has to fit into the software development process. Testing isn’t only about confirming that the software matches its requirements; it’s also about making sure it meets the needs of users and other stakeholders when it’s used in the real world.

There are two types of testing: dynamic (where the program is executed and tested) and static (where the code and documentation of the software are inspected without executing it). To develop test cases for dynamic testing, many approaches are used. Testing is more than simply a technical task; it needs careful planning, management, estimate, monitoring, and control. Although testers employ tools, it is mostly a thinking and problem-solving activity that necessitates specific knowledge and analytical abilities.

The ISO/IEC/IEEE 29119–1 standard gives more details about software testing concepts.

1.1.1. Test Objectives

The main goals of testing are:

• Checking Work: To review and assess different parts of the software like requirements, designs, and code.
• Finding Problems: To discover errors and defects in the software that could cause issues later.
• Covering Everything: To make sure all parts of the software are tested thoroughly.
• Reducing Risks: To lower the chances of the software having quality problems.
• Confirming Requirements: To check if the software does what it’s supposed to do according to the specifications.
• Meeting Legal Rules: To ensure that the software follows any legal or contractual rules.
• Informing Decisions: To give information to people involved in the project so they can make smart choices.
• Building Trust: To make sure everyone has confidence in the quality of the software.
• Checking Completeness: To make sure the software is finished and does what people expect it to do.

The specific goals of testing can change based on the situation, like what kind of software is being tested, what risks are involved, how the software is being developed, and other business factors like competition and deadline

1.1.2. Testing and Debugging

Testing and debugging are two different things.

Testing is like examining a car to see if it works correctly. Sometimes, while testing, you might discover that something is wrong (a defect) with the car. This could happen while you’re driving it (dynamic testing) or just by looking at it (static testing).

Debugging is what you do when you find something wrong during testing. It’s like fixing the car when you realize it has a problem.

When you find a problem while driving the car (dynamic testing), you do three things:

• Reproduction: You try to make the problem happen again to understand it better.
• Diagnosis: You figure out what’s causing the problem, like a flat tire or a broken engine part.
• Fixing: You repair the issue, like changing the tire or replacing the broken part.

After fixing it, you test the car again to be sure it’s working fine (confirmation testing). You might also check if fixing one thing didn’t break something else (regression testing).

But when you spot a problem just by looking at the car (static testing), you don’t need to do all these steps because you already know what’s wrong. So, you skip reproduction and diagnosis and go straight to fixing the problem.

In simple terms, testing is about finding problems in software, and debugging is about fixing those problems, whether they are found while using the software or just by looking at it.

1.2. Why is Testing Necessary?

Testing is like making sure a project, like building a treehouse, goes according to plan. It helps find and fix mistakes to make sure the project turns out how everyone wants it. It’s not just the job of a specific team; anyone involved can help by checking and improving things. Testing is like a quality check to keep the project on track and successful.

1.2.1. Testing’s Contributions to Success

Testing and Quality Assurance (QA) are different but related.

Testing is like checking a product to find and fix mistakes. It’s part of Quality Control (QC), which is about making the product better.

QA, on the other hand, is like making sure you follow the right steps to create a good product from the beginning. It’s more about the processes you use. If you do things right, you’ll get a good product.

Both testing and QA use test results but in different ways. Testing uses results to fix problems in the product. QA uses results to see how well the processes are working and improve them. Everyone on a project is responsible for QA.

1.2.3. Errors, Defects, Failures, and Root Causes

People make mistakes, which can lead to problems in what they’re doing. These problems are called defects or bugs. These defects can be in things like documents, computer code, or other stuff that’s part of a project. If these defects aren’t caught and fixed early, they can cause bigger problems later on.

When a defect in computer code gets used, it can make the whole system not work right, or even do things it’s not supposed to do, which is a failure.

Sometimes, things like radiation or electrical fields can also cause defects in computer stuff.

A root cause is the main reason behind a problem. To stop similar problems from happening again, we figure out what caused it in the first place and try to fix that main reason. This is called root cause analysis.

1.3. Testing Principles

There are some important rules for testing:

• Testing shows the presence, not the absence of defects (Testing Shows Defects, Not Perfection): Testing can find problems in something, but it can’t guarantee that there are no problems at all. Even if no problems are found, it doesn’t mean everything is perfect.
• Exhaustive testing is impossible (Testing Everything is Impossible): Trying to test everything is too hard and takes too long. Instead, we use techniques and priorities to focus on the most important parts.
• Early testing saves time and money (Start Testing Early): It’s better to find and fix problems early in a project. This saves time and money because it prevents more problems later.
• Defects cluster together (Problems Tend to Stick Together): Most problems are usually in a small part of the project. This helps us know where to focus our testing efforts.
• Tests wear out (Tests Get Less Effective Over Time): Repeating the same tests too many times doesn’t help find new problems. Sometimes we need to change our tests or make new ones.
• Testing is context dependent (Testing Depends on the Situation): There’s no one-size-fits-all way to test things. Testing is different for different projects.
• Absence-of-defects fallacy (No Defects Doesn’t Mean Success): Just because we fixed all the problems doesn’t mean the project will be successful. We also need to make sure it meets users’ needs and business goals. So, testing is only part of making something good.

4. Test Activities, Testware, and Test Roles

Testing is like a recipe, and there are common steps we follow to make sure we do it right. But we can change the recipe based on what we’re cooking and how we’re cooking it. These steps make up the testing process.

The testing process has different activities, like checking what needs to be tested, how to do it, and who does it. We decide on these activities when we plan our testing for a specific project.

So, while testing depends on the situation, we have a basic process to follow, and we adjust it as needed. There’s also a standard called ISO/IEC/IEEE 29119–2 that gives more details about this testing process.

1.4.1. Test Activities and Tasks

Testing a software project is like following a recipe. There are different steps you need to take to make sure the software works correctly. Here are the main steps:

• Test Planning: This is like deciding what you want to cook and how you’re going to do it. You set goals and a plan for testing.
• Test Monitoring and Control: While cooking, you keep an eye on things to make sure they’re going as planned. If something isn’t right, you take action to fix it.
• Test Analysis: This is like checking all your ingredients to make sure they’re good to use. You also think about what might go wrong and how to check for it.
• Test Design: Just like deciding how to chop and mix things, you figure out how to test the software. What steps to follow and what to look for?
• Test Implementation: This is where you actually prepare the tests and get everything ready. It’s like setting up your cooking area and getting your ingredients ready.
• Test Execution: This is where you start cooking or testing. You follow your plan and see if the software works as expected.
• Test Completion: After cooking, you clean up and learn from your experience. In testing, you finish up any unfinished work, save useful information, and learn what you can do better next time.

So, testing is like cooking, and these steps help make sure the software comes out just right.

1.4.2. Test Process in Context

Testing is like making sure a cake turns out perfect, and it’s not done in isolation. It’s part of the whole baking process. Similarly, in a company, testing is just one part of making software work well. How we test depends on a lot of things:

• What the Users Want: We consider what the people who will use the software need and expect.
• Team Skills: We think about the skills and knowledge of the people on the team. Are they experienced or do they need more training?
• Type of Software: Is the software for something really important, like medical equipment, or for fun, like a video game? This affects how carefully we test it.
• Project Limits: How much time, money, and resources do we have for testing.
• Company Rules: The company’s policies and practices also influence how we test.
• How We Make the Software: The way we build the software, the tools we use, and the methods we follow all affect testing.

So, like baking a cake, testing is part of a bigger process, and how we do it depends on many things like what the users want, our team, the type of software, project limits, company rules, and how we make the software.

1.4.3. Testware

When we’re testing software, we create different kinds of paperwork and materials to help us do the testing properly. These things are called “testware.” How we organize and manage these materials can vary from one organization to another. We use a system called “configuration management” to make sure everything is consistent and correct.

Here are some of the things we create as part of our testing work:

• Test Planning: This is like making a plan before starting a project. We create documents like a test plan (a plan for testing), a schedule (a timetable), a risk register (a list of possible problems and how to deal with them), and entry and exit criteria (conditions that must be met to start and finish testing).
• Test Monitoring and Control: This is like keeping an eye on things while testing is going on. We make reports to show how testing is progressing, write down instructions for controlling the testing process, and keep track of any risks that might come up.
• Test Analysis: This is where we figure out what we need to test and what problems we might find. We create lists of things to test and reports about any issues we find in the stuff we’re testing.
• Test Design: We plan out how we’re going to test things in detail. This involves making detailed test cases (steps to follow), test charters (a plan for what to test), and other requirements for what we need to do our testing.
• Test Implementation: This is like getting everything ready to start testing. We create documents like test procedures (step-by-step guides), and automated test scripts (instructions for computers to test), and organize our testing materials.
• Test Execution: This is where we actually run the tests. We keep logs of what we do and report any problems we find.
• Test Completion: After all the testing is done, we make a report to show what happened during testing, what we learned, and any improvements we suggest for future projects.

So, testware is like all the paperwork and materials we use for testing, and it helps us keep track of what we’re doing and make sure everything is done correctly.

1.4.4. Traceability between the Test Basis and Testware

In testing, it’s important to keep track of everything we do and find. This is called “traceability,” and it helps us in many ways.
Imagine you’re building a puzzle. Each piece of the puzzle (like the corners, edges, and middle parts) corresponds to different parts of the software we’re testing. Traceability is like making sure all the puzzle pieces fit together correctly.
Here’s why traceability is important:
* Coverage: It helps us see if we’ve tested everything we should. If we have a list of what to test (like requirements), we can check that our tests cover all of those points.
* Risk: It helps us measure how risky the software still is. If we know where we found problems (like in certain tests or parts), we can see if there’s still a risk in those areas.
* Changes: When things change in the project, traceability helps us understand how those changes affect the tests and the puzzle pieces.
* Communication: It makes it easier to talk about testing with others who might not be experts. We can show them how we’re doing and what’s left to do.
* Quality: Traceability helps us see how good the software is, how well the testing is going, and if we’re meeting the project’s goals.

So, traceability in testing is like keeping a record of how we’re doing and what we’re finding. It helps us make sure we’re on the right track and can explain it to others too.

1.4.5. Roles in Testing

In testing, there are two main roles: one is like the “boss” of testing, and the other is like the “worker” who does the technical part.

• Test Management Role: This is like the boss of testing. They are responsible for planning how testing will be done, making sure it’s on track, and completing it successfully. The way they do this can change depending on the project. For example, in a fast-paced project like Agile development, some of these tasks might be done by the team itself. But for bigger tasks, there might be a separate test manager who handles them.
• Testing Role: This is like the worker who does the actual testing. They focus on things like understanding what needs to be tested, designing the tests, doing the tests, and making sure everything works as it should.

Sometimes, different people take on these roles at different times. For example, one person might be in charge of both planning and doing the tests. It all depends on the project, the skills of the people involved, and how the organization works. So, in testing, there are leaders who plan and manage, and there are workers who do the testing, and sometimes, one person might do both.

1.5.Essential Skills and Good Practices in Testing

Skills are like talents that make you good at something. When it comes to testing, good testers have skills that help them do their job well.

• Knowledge: They know a lot about testing and the software they’re testing. It’s like having a good understanding of the rules of a game.
• Practice: They’ve done testing before and learned from their experience. Just like how you get better at a sport by practicing, they get better at testing by doing it.
• Aptitude: Some people are naturally good at certain things. In testing, having an aptitude means you’re naturally good at finding problems and figuring out how things work.

Good testers are also good team players. This means they can work well with others because testing is often done as a team. They can also test things on their own without help, depending on the situation.

So, being a good tester means having the knowledge, practice, and talent to find problems and work well with others.

1.5.1. Generic Skills Required for Testing

In testing, there are some important skills that help testers do their job well:

• Testing Knowledge: Testers need to know how to test effectively, which means using techniques to find problems in the software.
• Thoroughness: Testers have to be very careful and pay attention to small details to find tricky problems.
• Good Communication: Testers need to talk to others and explain what they find. They also need to listen and work well with the team.
• Analytical Thinking: Testers need to think logically and critically to be good at testing.
• Technical Knowledge: Knowing how computers and software work helps testers do their job faster and better.
• Domain Knowledge: Understanding the area or business the software is for helps testers communicate with the people who will use it.

Testers must be cautious and helpful when reporting software bugs, combining technical skills, attention to detail, strong communication, and critical thinking. They must also inform others constructively when they find difficulties, as people may not appreciate hearing about problems they created.

1.5.2. Whole Team Approach

Being a good team player is really important for a tester. It’s like playing on a sports team, where everyone has to work together to win.

In a method called the “whole-team approach,” which is like a team strategy from sports, everyone on the team can do different tasks. They all share the same space, like being in the same room or working closely together online. This helps them talk and work together better.

For testers, this means they work closely with others on the team, like the people who understand the business side and the ones who write the software. They help make sure the software is good quality and they share what they know about testing with the team.

But sometimes, in special cases like when safety is really important, testers need to work more independently to make sure things are done very carefully.

1.5.3. Independence of Testing

Independence in testing means being like a fresh set of eyes that can find mistakes that the person who made something might miss.

Imagine you wrote a story, and you know it so well that you might not notice if there are spelling mistakes because your brain knows what the words are supposed to be. But someone else reading your story might easily spot those mistakes because they’re looking at it with fresh eyes.

In testing, it’s similar. The more independent a tester is, meaning they are not closely connected to the people who made the thing they’re testing, the more likely they are to find different kinds of problems. This is because they have a different perspective and aren’t influenced by the same biases.

However, there are also challenges with independence. Sometimes, if testers are too independent, they might not work well with the people who made the thing. They might not communicate effectively or even create conflicts. So, it’s a balance between being independent enough to find problems but also working well with the team.