13. Test Types
In the last few lectures, we learned that each test level has specific testing objectives. In this lecture, we will look at the types of testing required to meet those objectives. We need to think about different types of testing because testing the functionality of the component or system alone may not be sufficient to meet the overall test objectives. A test type is a group of test activities aimed at testing specific characteristics of a software system or a part of a system based on specific test objectives. Such objectives may include evaluating functional quality characteristics such as completeness, correctness and suitability evaluating non functional quality characteristics such as reliability, performance, efficiency, security, compatibility and usability.
Evaluating whether the structure or architecture of a component or system is correct, complete and as is specified and evaluating the effects of changes, such as confirming that defects have been fixed, which is called confirmation testing, and looking for unintended changes in behavior resulting from software or environmental changes, which is called regulation testing. Let’s look at each one of them in detail. Functional Testing The function of a system or component is what it does. The function of a system is typically described in the requirements it’s location function or in use cases. Some functions are assumed and not necessarily required by the customer directly, such as copy and paste in any system which should be implemented even if the customer didn’t ask for it explicitly. Functional tests are based on these functions described in documents or understood by the testers.
Another type of functional testing is interoperability testing, which evaluates the capability of the software product to interact with one or more specified components. Functional tests should be performed at all test levels. The smoothness of functional testing can be measured through functional coverage. Functional coverage is the extent to which some type of functional elements have been exercised by tests and is expressed as a percentage of the type or types of elements being covered.
For example using Torcibility between tests and functional requirement the percentage of these requirements which are addressed by testing can be calculated potentially identifying coverage gaps. Functional test design and execution may involve spatial skills or knowledge such as knowledge of the particular business problem the software solves for example, geological modeling software for the oil and gas industries or the particular role of the software servers for example, computer gaming software that provides interactive entertainment. The techniques used for functional testing are often black box based to drive test conditions and test cases from the functionality of the software or system. But other techniques can also be used. We will be talking more about those techniques in the Design Techniques section. Non Functional Testing Imagine an accounting system where every functionality works perfectly well, but it’s very slow. You might need hours to print a report. Such a system is still not usable, even though it performs its functions quite well. That’s why we need the second type of testing, which is testing of the quality characteristics or non functional testing.
Here we are interested in how it is done. The functional attribute what it does might be print a report. The non functional attribute how it’s done might be in two minutes. Non functional testing includes, but not limited to performance testing. How many users can connect to the system and how will that affect the performance of the software? Load testing how will the system perform if we do a single transaction so many times? Stress testing how will the system perform under very tough circumstances? Many users, many transactions, low memory, and so on.
Usability Testing Is the system easy to use? Maintainability testing Is the system easy to maintain if we need to fix a defect? Reliability Testing is the system reliable or does it crash eventually? Portability Testing Is the system easy to boot from one platform to another? Security testing Is a system secure enough that no hackers can hack into the system and get unauthorized data? Security testing used to be a functional testing attribute in the previous versions of the Isttpb syllables, but in this version it’s a non functional attribute. Refer to ISO standard ISO 25,010 for a classification of software budget quality characteristics if you are interested to learn more about it.
Non functional requirement can be stated in the requirement document as a direct customer request. For example, the system must support 1000 users simultaneously or as an industry standard. For example, the web page response time should be less than 6 seconds. We will talk more about some non functional attributes in the Tools section of this course. Contrary to common misconceptions, non functional testing can and often should be performed at all test levels and done as early as possible. The late discovery of nonfunctional defects can be extremely dangerous to the success of the project. Test design techniques can be used to drive test conditions and test cases for non functional testing. The thoroughness of non functional testing can be measured through non functional coverage. Non functional coverage is the extent to which some type of non functional element has been exercised by tests and is expressed as a percentage of the type or types of element being covered.
For example, using traceability between tests and supported devices for a mobile application, the percentage of devices which are addressed by compatibility testing can be calculated potentially identifying coverage gaps. Non functional test design and execution may involve the special skills or knowledge, such as knowledge of the inherent weaknesses of a design or technology, for example, security problems associated with boutique programming languages or the particular user base, for example, the bill sona of users of healthcare facility management systems.
White box Testing We will talk more deeply about white box testing in a future section. White box testing simply means that we use any information about the system’s internal structure or implementation and how the software is constructed to test the software internal structure may include code architecture, workflows and or data flows within the system. So for example, if you as a tester know the components of the system’s database or how a specific function is implemented, then you can use this to your advantage and use white box testing. The most famous kind of white box testing is when you have the source code written by the developers.
Again, the thoroughness of whitebox testing can be measured through structural coverage. Structure coverage is the extent to which some type of structural element has been exercised by test and is expressed as a percentage of the type of element being covered. At the component testing level, code coverage is based on the percentage of component code that has been tested and may be measured in terms of different aspects of code coverage items such as the percentage of executable statements tested in the component or the percentage of decision outcomes tested. These types of coverage are collectively called code cover. At the component integration testing level, white box testing may be based on the architecture of the system, such as interfaces between components and structural coverage may be measured in terms of the percentage of interfaces exercised by tests. White box test design and execution may involve visual skills or knowledge, such as the way the code is built, for example, to use code coverage tools, how data is stored, for example, to evaluate possible database queries and how to use coverage tools and to correctly interpret their results.
Last, a change. Related Testing first, let’s talk about confirmation testing or retesting. When a test fails and we determine that the cause of the failure is a software defect, the defect is reported to the developer and we can expect a new version of the software that has had the defect fixed. In this case, we will need to execute the test again to confirm that the defect has indeed been fixed. This is known as confirmation testing, also known as retesting. When doing confirmation testing, it’s important to ensure that the test is executed exactly the same way as it was the first time, using the same inputs, data and environment. The software may also be tested with new tests. If, for instance, the defect was missing functionality, at the very least, the steps to reduce the failures caused by the defect must be re executed on the new software version.
The purpose of a confirmation test is to confirm whether the original defect has been successfully fixed or not. If the last test now passes, does this mean that the software is now correct? Well, we now know that at least one part of the software is correct where the defect was. However, this is not enough. The effects may have introduced or uncovered a different defect elsewhere in the software. The way to detect these unexpected side effects of fixes is to do regression testing. The word regress is the opposite of the word progress. Progress moving forward.
So regress is moving backward in regression testing to move backward and test areas that were already working fine to make sure it’s still working fine after any kind of change to software It. Changes may include the changes to the environment such as a new version of an operating system or database management system. Confirmation testing and recurring testing are performed at all test levels, especially in Iterative and incremental development lifecycles.
For example, Azure new features It changes to existing features and code refactoring result in frequent changes to the code, which also requires a change related testing. Due to the evolving nature of the system, confirmation and repression testing are very important. This is particularly relevant for Internet of Things systems where individual objects, for example, devices are frequent, frequently updated all the blades. Regression test suites are run many times and generally evolve slowly, so regression testing is a strong candidate for automation. Automation of these tests should start early in the project.
14. Test Levels vs Test Types
Item mentioned for the service cloud application section of the advanced admin exam guide is that you need to be familiar with salesforce knowledge. Now to get knowledge started in your own organization, you need to set your own user record to be that of a knowledge user. So I’ve gone to my own user account, I’m going to click Edit and then select Knowledge User. I want to make sure that you’ve got that checked for yourself and then click Save.
And so now that you’ve got Knowledge enabled, let’s search for Knowledge inside of Setup. All right, so I had to refresh my screen actually for the Knowledge settings in this Knowledge section to appear underneath Service after I had clicked my Knowledge User Checkbox. Another thing to note is that you can access Knowledge Set Up by going into the Gear icon here and selecting Service Set Up. And you’ll see some service oriented items here in the Service Set Up home, including Knowledge here. Click on that. We can get to Knowledge Settings there as well.
Now, once you enable Knowledge in your, you can’t go back, but you can hide the administration settings by unchecking the Managed Salesforce Knowledge Profile permission if you want to hide things such as tabs or Administration Settings from specific profiles. But let’s go ahead and check the checkbox that we understand the impact of enabling Salesforce Knowledge and then click Enable Salesforce Knowledge and click OK to confirm that we realize that this cannot be undone. Then after a moment, the screen refreshes and we now have a few other links here underneath Knowledge data category assignments, data category mappings in addition to Knowledge settings and the main gist behind Knowledge as far as Salesforce Knowledge. Goes is it enables you to create a knowledge base for your support agents. And you can also enable certain people to become knowledge authors and then others to review and approve knowledge articles.
For example, so you’ll find in the Knowledge Settings there’s General Settings and a series of checkboxes and then Lightning Knowledge Settings. One thing to note is that there’s Knowledge Availability inside of Lightning and in Classic and Knowledge is the newer and recommended solution for providing knowledge articles for support reps. And previous to Knowledge or prior to Knowledge there was Salesforce Solutions which we saw briefly in the previous lesson when we were looking at Salesforce Classic. During the case closure page layout there was an area to be able to add a solution article and Salesforce Knowledge is an additional cost.
Let me show you a Help article as well and I’ll link to this Help article. It notes that knowledge is available in Classic and Lighting experience. But there’s some core differences between classic knowledge and lightning knowledge. So it can get kind of confusing because in Classic there are Salesforce Solutions and then Classic Knowledge and then Enlightening is Lightning, what they’re now calling Lightning Knowledge instead of just Knowledge. And sometimes you’ll see it referred to even as Knowledge One. So I believe that was tied into the mobile application.
I don’t believe you’ll see any specifics on Knowledge One on the advanced admin exam. But as far as the capabilities of knowledge between Classic and Lightning, I think you just focus more on the Lightning side of things now and then. Another thing to note is that in Knowledge inside of Classic, there was this concept of article types. And so when you’re in Classic, you set up article types. And then if you are working in Salesforce Knowledge of Lightning, you will set up knowledge record types. And so in the next lesson, we will start creating a few record types for Lightning knowledge articles. So I’ll see you there.
