Talented Tester Support

Author Archives: Talented Tester Support

What is the difference between a test strategy and a test plan?

So, What is the Difference between a Plan and Strategy?

This is one of the most often asked questions in software testing classes and testing-related google searches as newcomers in the testing business are surrounded by confusion regarding the terminology.


Testing is a crucial part of any software development project as it ensures the project has no serious flaws or bugs that will later take a lot of resources and time to fix. But before any testing begins there are two documents that need to be drafted and approved: the test strategy and the test plan. 


To be able to understand the difference between them one must first know what these documents mean and what they are useful for.


The Test Strategy


This is a document developed by the Test Manager and is a high-level document. It defines the approach the team will have in achieving the testing objectives. It derives from the Business Requirements document and it sets the standards for the testing processes and activities. As appose to an actual testing model, such as The Waterfall, this is the high level strategy.


The Test strategy includes the following:


Scope and objectivesthe test strategy defines the business objectives and the test scope;


Business issues – the budget of the project, the amount of time allocated for testing, the resources needed and other parameters such as these are defined and set before the testing begins.


Testing approach–the document establishes what type of testing will be carried out (performance, functional, stress, load) and if the testing will be done automatically or only manually.


Test deliverables – will list the documents needed from the testing team and also the method they’ll use for testing record keeping.


Defect tracking approachthe test strategy defines the tools the team will use to keep track of the defects and the data flow between the testing and the development teams.


Training –this is especially important if new tools are introduced in the project. The test strategy also defines the type of training that’s needed and the person or entity in charge of delivering them.

Testing Training

Training


Other relevant information – testing measurements and metrics, change and configuration management, risk management, automation information, if it’s being used.


In smaller projects, the test strategy is just a section of the test plan as it’s not practical to separate the two. According to differencebetween, in large companies with many projects, there is usually one test strategy and a lot of test plans, typically one plan for every major component.


The Test Plan


According to getzephyr.com, The test plan focuses on describing what, how and when to test.  The document is necessary as the test strategy only covers a whole range of modules and it covers general principles on how to approach the testing process. The test plan, on the other hand, focuses more on the specifics, the details of who and how is responsible for testing.


The test plan has the following components:


Test plan IDit’s a unique code that it’s assigned to every plan. 


Test environment – defines the environment that’s needed in order to carry out the testing. It’s the setup of both hardware and software that’s required by the test teams in order to execute test cases.  It allows the team to carry out the tests by being configured with the necessary hardware, software and network.


Features to be tested or not – this section defines in details the software features that will be tested as well as the ones that will not be tested for any reason. They might not be available in that version of the software, for example.


Types of testing - the testing plan defines and describes in details the testing method used for every feature (stress, performance, usability, acceptance, integration, system etc).


Entry/ Exit criteria – basically specify when the testing has to start and when to stop. 


Other relevant information such as status, testing tasks, pass or fail criteria, schedule, responsibilities, test items and a brief introduction.


The test plan is very specific as it tells the team or even the team members what to test and when as well as criteria used for testing.  


A single development project can have multiple Test Plans and a waterfall project can have a test plan for every type of testing, as it is in an Agile project, for example, according to Focus Professional Services.


What are the differences?


When we put together the characteristics of the test strategy and the test plan, we observe some crucial differences.

1.  The Test Plan is formulated from SRS (Software Requirement Specification) and it describes the scope of testing as well as the activities performed, in detail. The test strategy describes the way testing is carried out, according to Art of Testing.

2.  The test plan is very detailed and specific when the test strategy talks about the general approach to testing.


3.  The test plan is subject to change while the test strategy remains untouched.


4.  The test plan is always a standalone document, the test strategy can be, in smaller projects, included in the test plan.


5.  While the test strategy is set at the organization level, the test plan is defined only at the project level.


6.  The test strategy outlines the necessary resources to complete the testing while the test plan assigns the testing tasks to specific roles.


7.  The testing strategy talks about the company vision and the expected results, the testing plan explains what needs to be done in order to achieve those results.

And the differences continue. The development of the testing plan, as well as the testing strategy, is viewed by many people as the most important part of testing and it really pays to have a very good plan that specifies clearly what steps are needed to ensure an error-free product.

Both these documents, however, are just pieces of paper unless they are checked regularly against the reality of the testing process and if the test plan is not updated to the current testing needs.

What is the difference between a test case and a test script?

WHAT IS A TEST CASE?

So, what is the difference between a test case and a test script? If this is something you've been asking yourself lately then you happen to be in just the right place. We'll first start by explaining what a Test Case is.

A test case is basically the specification of execution orders, inputs, expected results and testing procedures that define a series of single tests to be done with the main goal of achieving certain software testing objectives. These testing objectives could include compliance verification of specific requirements or exercising particular program paths.

Test cases rely on methodical testing procedures rather than the haphazard way of doing things. The desired coverage for software testing can be produced by building a series of test cases using this technique.

Test cases that have been formally defined give those same tests the ability to run repeatedly against the software's successive version. What this does is it allows for consistent as well as effective regression testing.

In order for an application's requirements to be fully tested, each requirement will require you to run a minimum of two test cases each. A negative test as well as a positive test.

Expected outputs and known inputs are the characteristics of a formal test case. Test cases based on normally accepted program operations are informally written test cases.

What is a Test Script?

Now for the Test Script description. This is basically a script module consisting of system instructions for testing purposes. The fact that you need to write actual coding language to produce this tool is why people in the IT realm gave this procedure the term "test script". 

It seemed better than just a plain text of a series of instructions. JavaScript, Python, Peri, VB Script and Ruby are all languages that can be used to write test scripts

The development of test scripts can be done in very many ways. A clear example is, when working with programming codebase that's object oriented, developers and programmers can access testing objects using several different strategies. 

In other cases, developers and programmers, once again, can take huge advantage of APIs or Application Programming Interfaces for the creation of high quality test scripts, which will in turn lead to development projects with high functionality levels.

In general, test scripts are basically mediums that give IT professionals the ability to determine predetermined input results and test case isolations. This is comprehensive testing's strategy for the elimination of glitches and bugs as well as the promotion of better software service and product functionality. Test harnesses are the test script repositories and the text execution engines.

What is a Test Scenario?

Any functionality that allows for testing is what a Test Scenario basically is. Most IT professionals also commonly refer to this as Test Condition or Test Possibility as well. In this approach, you as a software tester, will need to figure out real world scenarios by using the end user's point of view, as well as using the cases of the application that is currently being tested.

Two words make up Test Scenario. These are Test and Scenario. Here, "Test" represents verification or validation while "Scenario" is meant to represent the user journey's verification process.

Normally you'll find that large amounts of possible paths as well as large amounts of data combinations in the software will usually restrict you from using exhaustive testing, however, Scenario Testing ensures that the application's end to end functionality that is currently being tested is working as it should and it also makes sure that the business flows involved are also working as expected.

As Scenarios are just basically the User Journeys, in this approach the software tester, when checking the applications performance, just has to walk in the end user's shoes.

The Test Scenario's preparation stage is most often times the most vital part of the whole process. You as the software tester using this approach will need to get help or consult the business user, client, developer or business analyst. After the determination of these test scenarios is when you can begin to write test cases for each scenario. 

The high level concepts of what need to be tested are what make up Test Scenarios.

Conclusion

If you're an IT professional in this day and age, then you might want to consider fully understanding the fundamentals of Test Plan. It has the ability of making some of your work so much easier as well as way more effective.

Always try to make the test plan as concise as possible if you want the plan to be as effective as possible and avoid superfluousness and redundancy, and with that you'll be good to go. Hopefully, you now know a lot more about Test Plan.

Regression Testing Best Practices

Regression testing is defined as the process of testing a changed software to ensure that the older established features still work as they should.  It is a crucial step in software development as it eliminates many of the risks associated with software updates. 


Although some organizations verify critical functionality only once and they presume it will continue to work fine unless it’s been purposely modified, the practice has shown that even routine changes in code can have unthought-of side effects that break previously established functionality.


It is essential as it provides the only reliable tool that verifies that the code changes don’t break the existing functionality of an application and it has a huge impact on release delays, budget overruns and the possibility of bugged errored software being released. 


Regression testing determines when code alterations cause previously working functionality to fail, giving you the opportunity to identify errors in real time. 


Why do defects appear during changes in code?


For a software that was previously working flawlessly, this can change if the updates included incorrect or incomplete changes. This occurs extremely often in the software industry. Generally, one of six attempts to correct a defect is faulty and generates additional errors.


This high rate of the defects has several reasons. First, it’s the tendency developers have to fix the symptoms instead of the root cause.  Other factors can be the lack of experience of the developers or poor system documentation, often seen in the agile methodology, as appose to the waterfall model.


Most common regression testing techniques that are used today


These techniques exist to focus our testing on the aspects that could have been affected by the code changes instead of covering all possible aspects that could go wrong. 


Full testing (Retest All) aims to cover as many issues as possible and it’s basically running all tests after every change to the code is made. It’s the complete technique and sometimes the only option when you can’t predict which part of the software was affected by the update.


Regression test selection aims only at the modules that were more likely to be affected by the changes. As it is not complete, I can let errors slip through so it’s extremely important to receive a very high ROI.


Test Case Prioritization is approached in two different ways: general prioritization when cases are chosen based on their importance and version-specific prioritization when cases are chosen based on their importance for that specific version.


Hybrid combines any or all of the above techniques for various releases.


What are the best practices for regression testing?


When you create your regression testing plan and you’re opting for one technique or the other, there are a few things you should keep in mind:


1.  Use automation – nothing can make your process more efficient than automation. Repeated testing under the same conditions and with the same variables will not discover any new defects. Also, repeated tasks will make your testers lose concentration and they might miss some of the defects. 


The biggest advantage of automated regression testing is that you can add extra test cases to the regression pack without increasing the testing time too much. And more, the automated test can be run during the night or at the same time with the manual tests. 


2.  Update your regression pack regularly – It is always a good idea to keep your regression pack up to date. As your project increases, some of the newest functionality won’t have enough test coverage while some other tests might not be necessary anymore.


3.  Use an element 'id’ to locate items on screen. Original automation tests recorded actions they later replayed. They could simulate the clicking on a certain pixel’s location. However, if that button was moved, the clicking will take place in the wrong location. Calling it by name instead of location allow the test to continue no matter where the button was moved


4.  Analyze every defect that escaped the previous testing  - this will allow you to figure out what went wrong and to include tests that can possibly cover that path and detect that particular type of defect.


5.  Focus on busy paths – they should include the basic functionality of your software as well as the most used features. This implies you know your users and those features they rely on the most. Your regression pack should focus on the core functionality of your application.


6.  Identify those areas that have shown the most failures and include in your regression pack more tests that focus on those areas.


7.  Don’t forget to include tests that cover non-functional attributes such as performance, usability, security. 


Regression testing tools you can use


There are a few testing tools available for use, like code-based software testing frameworks, JavaScript-based frameworks, BDD testing frameworks, Enterprise record-playback IDEs or Codeless cloud-based platforms.


The latter are simple substitutes to Enterprise IDEs but they offer advanced functionality, like DOM comparison, collaboration functionality, etc. 


Conclusions


When developers change or update their applications, the smallest modification can have unforeseen ramifications. Regression testing is the only way to ensure the modification hasn’t broken existing functionality. By re-running testing scenarios that were designed when original problems were fixed you can make sure your update didn’t cause previously solved bugs to re-appear.


Regression testing needs to be seen as a piece of a testing methodology that’s cost-effective but still complete and that incorporates enough variety, like for example frontend UI automated tests combined with targeted unit testing using risk prioritization. This will prevent any aspect of your application from being unchecked


Software development companies with effective regression packs improve their performance of their developers significantly thus leading to a successful project. 


The discovery of errors on time can save a lot of time wasted on chasing errors further in the development cycle. It also allows the team to update the code when necessary without being afraid it will compromise previously established functionality.

1

What Are the Advantages and Disadvantages of the Waterfall Model?

The Waterfall model, also known as linear sequential design, is a software development model. Just like the name suggests, the development flows only in one direction, which is downwards. 

Waterfall

What does the Waterfall Model do?

According to Oxagile, this sequential development ends up releasing a new software product. The key to this Waterfall Model’s framework is that it proceeds with each requirement step by step and never goes backwards..

The linear sequential design follows a program full of activities that need to be accomplished correctly before moving on to the next one.

This won’t allow you to leave any open stages because you won’t be able to proceed to the next task. All of the phases are planned and designed beforehand.

I highly recommend you to watch this YouTube video, that goes through the basics of this development model. This will help you understand all the aspects explained in the article. It’s named “What is Waterfall Methodology?” and it is created by Project Management Software – Easy Projects.

  

If you are still trying to understand how this software development model works, it is essential for you to get acquainted with all the steps that you will be required to pass before reaching the final result.

The different phases of the development

The most important thing you should keep in mind while going though this software development model is to have a clear vision of the project and to understand properly what you are aiming for.

The Waterfall Model is very useful and easy to follow, only if the idea and its stages are perfectly identified. According to a Tech Republic article, the following are the phases to a successful development.

Brainstorming and Defining a Concept

One of the first steps is brainstorming and defining a concept. Investigate the target briefly to get an idea of their needs and find out the perfect product. 

Define your target

Once you resolve all of those questions, you need to do an exhaustive research of the clients and customers that you will be directing to. Define your target and investigate what they need and where they are from. 

Plan a Strategy

Once you have your customer’s area controlled, it is time to start designing. You will need to plan a strategy that solves each of the problems that are presented. Apart from that, you will need to program other aspects like the language.

Implementation

The next step is to start constructing it. Once all the ideas are clear, you will be able to start with the next step, which is implementing the solutions to every stated problem and constructing the final product.

Once the construction part of the development is done, you should start testing it. Verify that it accomplishes all the requirements you named before. Also, check out if they are totally error-free.

There are three different types of testing that are usually put into practice. The first one is called unit testing of code modules, which makes sure that all the coding is properly set up.

Then you should proceed with the system testing and finally, the acceptance testing. 

The next step is deployment. When you check and verify that everything is working properly, you will be able to install the final product. The last step is the maintenance of the software result you just created. 

What are the Advantages of using the Waterfall Model?

The Waterfall Model is well known for its multiple advantages when it comes to creating and developing a new software product from scratch. 

In agreement with an article of Tech Target, the first thing to note is how organized the process is. This means that every step or activity has a deadline that needs to be respected and followed strictly. 

Every task has a starting and ending point that needs to be accomplished in a limited time. 

Dividing the development of the software in other departments makes it easier to manage and control. The rigid model usually turns into a successful final project.

Another advantage to keep in mind is that usually this model requires a lot of beforehand strategic thinking and planning. This is why so many problems are found in the early stages and can be avoided. 

The model is also popular for its simplicity. As mentioned before, the planning is so well organized that everyone is able to understand the process. Moreover, the tasks never overlap each other, so there are no confusions.

All of the processes are completed one at a time, that is why the model is strict to follow but the durability of the activities is much shorter and effective than if you use any other development model. 

Does the Waterfall Model have any disadvantages?

After going through all of the advantages that this software development model has, it is fair to display some of the disadvantages. 

One of the aspects that most people tend to dislike according to Armarjeet Chavan is the fact that once you complete one task, you are not able to step back and modify it.

Sometimes, there is a possibility that you might be able to change something but it will surely end up being extremely expensive and will add extra cost to your project. 

That is why the Waterfall Model is only supposed to be used when the idea of the product is very clear and all of the requirements are understood beforehand.

However, it is true that due to its fast development, it makes it a little bit difficult and complicated to revise all the work, as well as to verify if it is going on the right path.

 Another disadvantage is the difficulty to solve all the problems even before starting with the process. You may estimate the basic things that will get on your way but maybe not each and every one of them. 

For example, you could have designed something that later turns out to cost a lot more money or it is just too difficult to produce. This is why some people state that this development model is unrealistic. 

Finally, this model should only be used in short and simple projects because if you try to apply this to a complex development, the risk of needing to change any requirement is higher. 

And as suggested above, this will only result in extra expenses or even a failure of the project.

ISTQB Foundation Answers to Questions Part 3

Hello and welcome to part three of the ISTQB Foundation answer to questions. In case this is the first time that you’ve checked out one of these please feel free to go back and look at part one and part two.

If you would like to download the entire list of answers to questions on PDF or in PDF format, then click here.

I’m gonna be focusing in on three questions taken from sample paper number two. This is freely available for download at the main website TalentedTester.com. And the questions that we’re gonna be focusing in on this week is going to be questions 2, 7, and 15.

 

Why is a test strategy important?

[Taken from the ISTQB Foundation Sample Paper 2, Question 2]

The first question is, “Why is a test strategy important?” Is it:

  • a) To inform the developers how you will approach testing to give them confidence in your work
  • b) Software defects can cause a number of critical problems including death, injury, financial loss, loss of time, and poor customer experience, meaning it is important to have a test strategy.
  • c) To let the project manager have full transparency of your testing approach to feel him with confidence before you start the test phase.
  • d) It is required to give a high level view of the testing approach so that the stakeholders do not have to go through your actual test plan.

Test Strategy

Image by: Flavio~

So have a think about those potential answers and then I’m going to highlight the correct one. The correct answer is B, and it is software defects can cause a number of critical problems including death, injury, financial loss of time, and poor customer experience, meaning it is important to have a test strategy. Bear in mind that you will have a lot of similar structured questions in the actual exam, multiple choice to try and catch you off guard, so it’s a case of just understanding the criteria and obviously having a good understanding of why it is correct.

 

Which of the following is not included in defect management?

[Taken from the ISTQB Foundation Sample Paper 2, Question 7]

Notice I said, “Not included.” This is another thing that can catch people off guard is when they use stuff like, “Not.” So it’s the complete opposite, and you may quickly scan through the question and the paper, and then just overlook that you’re actually looking at what is not included. So let’s have a quick look at these:

a) Reporting on defects.
b) Triage the defects with the development team.
c) Changing the status of the defects.
d) White box testing.

Defect Management

Image by: marcdalio

So have a look at these four answers. Think of, logically, which would be the correct one, make a selection, and, in just a few seconds, I’ll reveal the correct answer for your knowledge.

The correct answer is D, white box testing is not included in defect management. Remember the question is, “What’s not included?” So this is obviously the one that we need to isolate.

Which person typically uses static analysis tools?

[Taken from the ISTQB Foundation Sample Paper 2, Question 15]

a) Project managers.
b) System testers.
c) Programmers.
d) Business analysts.

Have a think about these four potential answers. Think logically which will be the correct one, and then I’m going to reveal the answer shortly.

The correct answer is C, programmers. Which person typically uses static analysis tools? And for this the answer is programmers. So hopefully you’ve got this question correct. And hopefully all of the other three questions have made since. If not, you can add them to your list of questions and answers that can help you prepare for the exam and your study.

Want more ISTQB Foundation sample exam papers?

If you want a free exam question example paper or even download the exact PDF, which supports … includes the questions that have been covered today and a lot more or even additional mock papers, then click here. Thank you and hope to see you on the website.

 

ISTQB Foundation Answers to Questions Part 2

Welcome, welcome. This is Wayne Vassell with TalentedTester.com and today I’m going to be going through the ISTQB Foundation Answers to Questions Part 2 (Video below). In this series, we are going to be covering answers to questions and we’re going to be looking at three sample questions which have been taken from sample paper number two. Today, we’re going to be looking at questions 1, 4, and 6.

If you would like to download the entire list of answers to questions on PDF or in PDF format, then click here.

In particular, you will see a full list of questions … Of 15 questions with 15 answers in preparation for your ISTQB Foundation Level exam and there’ll be additional sample papers that you can download or request access to, which will help you for your studies. Without further ado, let’s get into this session.

 

Test Harness, Script, Driver or UAT Plan?

[Taken from the ISTQB Foundation Sample Paper 2, Question 1]

Question number one, Ray the programmer has just written a function and needs to test it. He wants to call the function and pass it test data, which one of the following does he need? Is it:

a) A harness
b) A script
c) A driver
d) A UAT Plan.

Have a quick think. Which one of the following does he need? The right answer is it’s not a harness, it’s not a script. The answer is c. A driver. If you think about this logically, a UAT plan has nothing to do with this scenario, yeah? A script is not correct and a harness in this context would typically be a test harness, is not what we need, so the driver is the correct answer.

 

Which of the following is not a performance testing activity?

[Taken from the ISTQB Foundation Sample Paper 2, Question 4]

Question four, which of the following is not a performance testing activity? Note it says ‘not’:

a) Simulating many transactions into the system.
b) Recording the system response time under heavy load.
c) Putting the system under heavy load by simulating multiple users.
d) A test harness to replicate a key system function.

Stress Testing

Image by: topgold

Before we get into the answer, what is performance and stress testing? Remember, this is a type of testing which is quite specialized and will basically put this system under a lot of stress to get or prove that it can handle the chance of there being multiple users on the system without being … Without it crashing. What is the correct answer to this? The correct answer is d. This is one of the questions … Or one of the answers that is incorrect, which is not a performance testing activity. Using a test harness to replicate a key system function is not a performance testing activity.

Why is it necessary to prioritize test cases?

[Taken from the ISTQB Foundation Sample Paper 2, Question 6]

Final question, six. Why is it necessary to prioritize test cases?

a) To introduce some structure into your testing,
b) It makes your testing look more organized,
c) To allow you to perform the best possible testing in the agreed time
d) It is easy to find more defects.

What is it necessary to prioritize test cases? It’s not a. To introduce some structure into your testing. B. It’s not b. It makes your testing look more organized. The answer is c. Which is to allow you to perform the best possible testing in the agreed time frame. It’s not d. either.

If we think about it, the reason that we prioritize is that if we get to a situation where our time is crunched, we can then make a judgment call or a priority call on the test cases that are absolutely mandatory and potentially not run the tests, which are deemed as the least priority. This is something which has come up in my career time and time again so it’s a very good way of being able to quantify exactly which tests will be run when your time is cut short or you run out of time due to a number of defects that you’ve come across.

Want more ISTQB Foundation sample exam papers?

If you want a free exam question example paper or even download the exact PDF, which supports … includes the questions that have been covered today and a lot more or even additional mock papers, then click here. Thank you and hope to see you on the website.

 

1

ISTQB Foundation Answers to Questions Part 1

Welcome people and thank you very much for joining me on this video transcription. In this video (full video below), I’m going to be covering ISTQB foundation answers to questions and this is part one in this series.

You can actually download the full answers to questions PDF document here. The idea there is that I’m going to walk you through a selection of questions that are covered in the downloadable PDF and walk through why they are correct and why the others are incorrect.

 

What is the V-Model?

[Taken from the ISTQB Foundation Sample Paper 2, Question 3]

To begin with, we’re gonna look at this question three, which is taken from sample paper number two.

What is the V-Model?

a) a type of test automation that supersedes the Z-model;
b) a unit testing technique used by developers to test software function;
c) a type of test harness that allows the tester to inject test data for a difficult test case; or
d) a software testing model that demonstrates how software testing integrates with development.

I’ll just give you a couple of seconds just to think about what you believe to be the right answer. Hopefully you’ll get it right and even if you don’t, not a problem. At least you’ll learn something from this and then we can walk through why it’s correct. The correct answer is actually D, a software testing model that demonstrates how software testing integrates with development.

If we look at this diagram that I’ve got here, it explains or demonstrates how this is a model that demonstrates how software testing integrates with development, so we can see on the left-hand side, we’ve got detail design, requirements and architecture, and on the right-hand side, we can see system verification, which is typically system testing and low level testing on the right-hand side, and we can see how they actually mesh together.

The V-model is one of the earlier models, which is something that I’ve used quite extensively in my career over the years. Nowadays, a lot of people tend to go with the agile method, because it’s something that is quick to implement and is not a lot of documentation involved, but from my experience, V-model has always been a very solid software testing model that you can always rely on. Obviously, it’s not 100% perfect. I don’t believe a 100% perfect model exists, but this is definitely a solid one, but it just takes a little bit more red tape to get correct and you have to have the buy-in from all your stakeholders.

Let’s move onto the next question.

What does the acronym PDCA stand for?

[Taken from the ISTQB Foundation Sample Paper 2, Question 13]

Question 13:

What does the acronym PDCA stand for?

a) Plan, design, check and act;
b) Plan, do, check, and act;
c) Plan, do, correct, and act; or is it
d) Plan, direct, check, and access.

I’ll give you a couple of minutes just to think what is the correct answer to this. Just to give you some context, in the foundation exam, you will get similar questions like this, which will try and trip you up by making the answers look very similar with maybe one small change. The idea is just to take your time, think back to what you’ve been studying and remember if you can get the correct answer.

Without further a delay, excuse me, let’s look at what the correct answer is. The correct answer is B, which is plan, do, check, and act. The best way really is just to commit this one to memory, but it’s an example of how some of the questions can try and trip you up.

What is Unit testing also known as?

[Taken from the ISTQB Foundation Sample Paper 2, Question 14]

Let’s move onto the next one.

Question 14:

Unit testing is also known as:

a) Component testing;
b) White box testing;
c) Module testing;
d) Program testing.

Which one do you think is the correct answer? Unit testing is also known as. I’ll give you a couple of seconds just to have a think. Okay, so I can reveal A is the first potential answer, and this basically is one, two, and four. Is the answer a combination of one, two, and four? Or is it B, a combination of two, three, and four? Or is it C, one, two, and three? Or is it D, which is all of the above?

This is another example of a style of question that will be used to try and test you and obviously, it’s just more about eliminating the incorrect one or could it be that all of these are correct and they’re just trying to trip you up. The correct answer is D, all of the above. You can see component testing, white box testing, module testing, program testing, these are all interchangeable terms associated with unit testing.

Want more ISTQB Foundation sample exam papers?

If you want a free exam question example paper or even download the exact PDF, which supports … includes the questions that have been covered today and a lot more or even additional mock papers, then click here. Thank you and hope to see you on the website.

 

What is the ISTQB Certification

Welcome guys. This is Wayne Vassell here from Talented Tester. Just wanted to give you a quick piece of content here about what is the ISTQB testing certification. Many people ask me, so I wanted to just make sure that you’re fully aware of what it is.

So the ISTQB is the International Software Testing Qualifications Board. That is what the actual acronym breaks down. It’s in 70 different countries and each country has its own local board for testing. For example, in Australia and New Zealand there is what they call the ANZTB and also in Norway, there’s a Norwegian testing board NTB.

What Makes the ISTQB So Attractive?

So what makes the ISTQB so attractive to all the testers around the world you may ask? Well first and foremost for the sheer fact that it is a well known internationally recognized certification makes it very interesting to all people. This means that if you was going to be working in a different country then it would add value to your CV because you’d be able to port those skills to other countries. It allows you to have a world recognized certification. There are multiple levels from foundation to advanced and also expert level, which I will get on to in more detail in just a moment. Another beauty of it, there’s no expiry date. As other certifications, you have to renew them like maybe every 5 or 10 years, but this one does not have an expiry date. So once you get your certificate, that is basically on your CV for life. It’s also online certification, which means it’s really easy to do and very accessible.

What are The Different Levels?

So what are the different levels, you may be asking yourself? There are three distinct levels. There’s the

  • Foundation Level
  • Advanced level
  • Expert level.

Who is the Foundation Level Certification level for?

So who is the foundation level certification level for? This is typically for entry level brand new testers, people that have maybe been in testing just for a short period of time. Maybe not exactly brand new, but they’ve been into testing maybe only six months to a year. It’s not just for people that are brand new to testing as well. It’s also open for experienced testers that are wishing to have a recognized certification. What you have to understand is you may be one of those people that have been testing for a large amount of years, but you’ve never had any formal education or certificates to back up your understanding. This might be just a gap in your CV that people keep asking for, which might be a reason why the foundation level certificate would be a good starting point.

It’s also a good certificate for experienced testers who are wishing to work up to the advanced or expert level. So if you want to actually get to the expert level then it is best practice to get your foundation certificate first and then move up the ranks.

What does the Foundation Level Certificate actually cover?

So let’s delve deeper into the foundation level. What does it actually cover? The key concepts of the foundation level: they go into the SDLC, the Software Development Lifecycle; static techniques such as black box and white box testing; and also an entry level view of test management tools.

Who is the Advanced Level Certification level for?

So if we skip on to the advanced level certification, who is this targeted at? What is the best person for this level? So it’s typically mid-level testers that have had a minimum of five years experience. Typically established test professionals that are fairly confident in testing, that have been around for a while. Professionals looking for some growth in their career. Maybe they’ve been around for a while and they just want to actually solidify their skills and make themselves more marketable.

What does the Advanced Level Certificate actually cover?

So let’s just look at some of the advanced level coverage. We’re talking about advanced behavioural or black box testing, standards for business-centric testers, test automation as well, which is obviously a big interest in the market these days, advanced structural or white box testing, and also test management concepts.

Who is the Expert Level Certification level for?

So let’s take a look at the top tier expert level and what the difference is for that. Who is this actually targeted at? This is typically for leaders with eight plus years experience and maybe leaders in the game who are looking for real industry recognition. Quite a bit of work to get to this level and therefore the expert certification is the perfect accolade to add to your CV.

What does the Expert Level Certificate actually cover?

So let’s look at the type of coverage that you’d expect on the expert level. You’re looking at the latest proven cutting edge testing techniques. Test process improvement, expert level automation, so it does get very low level technical stuff, and expert level test management for people that are going more into the management side of things rather than down to the actual automation or technical side of testing.

Summary

So that is a good overview of exactly what the ISTQB has in store. These are different levels. If you want to see a free exam question sample from the foundation level, then click here and you can download a free sample, no questions asked, and just pick that up for free.

1 3 4 5
Skip to toolbar