15. Maintenance Testing
Not enabled lightning knowledge yet. So the only knowledge capability we have currently in our is for Salesforce Classic. Now, I mentioned previously this concept of article types, which is only available in Classic. And then once you enable Lightning knowledge, then you have the ability to create Knowledge Record types. So before we enable Lightning knowledge, I want to switch over to Classic and show you knowledge article article types.
And then we’ll enable Lightning knowledge and create Knowledge Record types. If we go into Setup inside of Classic and search for knowledge, you see that there’s a lot more links available and set up inside of Classic than Enlightening so far. And we have this link here for Knowledge article types. And this is a precursor of what eventually became Knowledge Record Types, which is available inside of Lightning experience only.
And it’s kind of the same concept in that it defines the look and feel of an article, including its fields, layout and templates. And so you can look at one of these and you see the fields available from that article type, and you can get to the page layouts here. So if we click on Edit for the page layout, this is the knowledge layout and the enhanced page layout editor. And it’s kind of sparse right now. Now, I’m not going to set up article types and article type page layouts. I want to defer to Lightning, and we will set up Knowledge Record Types and then set up page layouts for those.
So let’s go back into Lightning now and return back to Setup and Knowledge, and we’ll go into our knowledge settings again, and we’ll then enable Lightning knowledge if we click Edit from the Knowledge Settings page. Let’s now enable Lightning knowledge. And so an important note here is that this enablement of Lightning knowledge changes the data model of your. Once Lightning knowledge is enabled, it cannot be disabled. Please verify this change in a trial or sandbox before you enable it in production. And so there’s no going back once you go to Lightning knowledge. And this does then introduce record types on the Knowledge Object.
And I believe as well you’ll no longer be able to create knowledge article types, and you’ll instead have to do Record types. Let’s click save. So now we should be able to set up Knowledge Record types just like in any other object. I’m going to go into Object Manager now and look for knowledge and click on that. And I’m not sure what the history is behind the API name for this underscore underscore Kav after Knowledge. That’s just a little side note. But we’re looking at the knowledge object inside of Object Manager. And if we go to Record types, we can now create Knowledge Article Record types. So I’m going to create two knowledge Article Record types, one for hardware and one for software. And then as well, much like with other record types, you enable these for profiles and then the first one that you enable for profiles is also marked as the default by default and can’t be changed until you then introduce a secondary record type.
Then you can change what the default is. And then as well, you have page layouts for knowledge articles. We just have the one page layout for now. We’ll apply that to all profiles. Let me just confirm that there’s no other page layouts and there’s not. And so now we’ll click Save and New to create the software Knowledge Record type. We’ll make this active as well. Let’s go ahead and enable this for all profiles and make this the default instead for all profiles. And click next. And then finally let’s click Save to finish out the creation of our two Knowledge Record types. And so now if we go back into setup, let’s look and see what we have under Knowledge here inside of Lightning. And once again it is much less than what you see in classic. But there’s a few other things here that I would like to talk about and that would be specifically data categories. You see data category assignments and data category mappings. And so let’s dive into data categories for knowledge in the next lesson.
16. Testing in Context
So we have learned about software development models, test levels and test types. So the question that usually pops up here is which software development model to use or which software development model is better? The answer is software development models must be selected and adapted to the context of the project and the product characteristics.
An above yet software development lifecycle model should be selected and adopted based on the project goal, the type of product being developed, business barrier’s for example, time to market identified product and project risks. For example, the development and testing of a minor internal administrative system should differ from the development and testing of a safety critical system such as an automobile brakes control system unless organizational and cultural issues for example, in some cases smooth communication between team members in some cases may prevent or abstract iterative development from the testing point of view. Depending on the context of the project, it may be necessary to combine or reorganize test levels and or test activities. For example, if we need to integrate a commercial of the shelf COTS software product into a larger system, the buyer may perform interoperability testing at the system integration test level to make sure that it integrates fine.
And also we can do testing at the acceptance test level, functional and nonfunctional testing along with user acceptance testing and operational acceptance testing. In addition, software development lifecycle models themselves may be combined. For example, a V model may be used for the development and testing of the back end systems and their integrations, while an Azure development model may be used to develop and test the front end user interface or UI, and functionality prototyping may be used early in the project with an incremental development model adopted once the experimental phase is complete. Internet of Things or IoT systems which consists of many different objects such as devices, products and services typically apply separate software development lifecycle models for each object.
This presents a particular challenge for the development of the Internet of sync system versions. Additionally, the software development lifecycle of such objects places a stronger emphasis on the later phases of the software development lifecycle after they have been introduced to operational use. For example, operate, update and decommission phases. Okay, now to the Farmba. What kind of questions can we see in the exam related to this section? Well, we have learned many terminologies in this section and we need to know what means what and who does what.
The V model is a sequential software model where we can do a planning and design of testing iterative. Incremental models like Spiral, Agile and Rationale are where we need to use automation testing, combine testing, integration testing, system testing and acceptance testing are test levels functional, non functional, whitebox and migration and retesting all types of testing. Maintenance testing is done on a live environment, alpha testing is done at the developer site, beta testing is done at the user site and both are kinds of acceptance testing. A question might be what kind of testing can be done by a developer? Let’s see component testing, integration testing, functional testing, non functional testing and for sure, white box testing, Bloss V testing and retrievation testing. Another question could be what kind of testing can be done by the customer, acceptance testing and the four types of testing.
