 Hello, myself, M.V. Bogdai, assistant professor of CAC department from WIT, Sholapur. In this session, we are going to see some points from black box testing, white box testing, system testing. So, at the end of this session, students will be able to understand black box testing, white box testing and system testing. So, these are the contents for this session. So you know that white box testing is also known as clear box testing, open box testing, structural testing, transparent box testing, code based testing, glass box testing. So white box testing, the clear box or white box name symbolizes the ability to see through the software's outer shell or box into its inner working. So, this is the diagram for white box testing. One of the basic goals of white box testing is to verify a working flow for an application. It involves testing a series of predefined inputs against expected or desired outputs so that when a specific input does not result in the expected output, you have enough encountered a bug. So, what do you verify in white box testing? White box testing involves the testing of the software code for the following. One security holds, broken or poorly structured paths in coding processes. The flow of specific input through the code, expected output, the functionality of the conditional loops, testing of each statement, object and function on an individual basis. So, steps involved in white box testing are understanding the source code and create test cases and execute. So, first step contains the tester must be very knowledgeable in the programming language used in the application. They are testing. They must be highly aware of secure coding practices. The tester should be able to find security issues and prevent attacks from hackers and Navy users who might inject malicious code in the application either knowingly or unknowingly. One step contains the test applications source code for proper flow and structure. One way is by writing more code to test the applications source code. The tester will develop little tests for each process or series of processes in the application. This method is required that the tester must have intimate knowledge of the code and is often done by the developer. Statement box testing techniques. So first, the major white box testing technique is code coverage analysis. There are automated tools available to perform code coverage analysis like system coverage, like statement coverage. This technique requires every possible statement in the code to be tested at least once during the testing process. Next is branch coverage. This testing technique checks every possible path of software application tools. An example of a tool that handles branch coverage testing for C, C++ and Java applications is TCAT path. Apart from the above, there are numerous coverage types such as condition coverage, multiple condition coverage, path coverage, functional coverage, etc. Using statement and branch coverage, you generally attain 80-90% code coverage which is sufficient. Advantages are code optimization by finding hidden errors. White box test cases can be easily automated. Testing is more thorough as all code paths are usually covered. Testing can start early in SDLC even if GUI is not available. This advantage, white box testing can be quite complex and expensive. Developers who usually execute white box test cases, detects it. The white box testing by developers is not detailed, can lead to production errors. White box testing requires professional resources with a detailed understanding of programming and implementation. It is time consuming, bigger programming applications take the same time to test fully. The white box testing can be quite complex. The complexity involves has a lot to do with the application being tested. A small application that performs a single simple operation could be white box tested in few minutes while large programming applications take days, weeks and even longer to fully test. Now we will see black box testing. Black box testing symbolizes not being able to see the inner working of the software so that only the end user experience can be tested. So this is the diagram for black box. In black box testing we just focus on inputs and outputs of the software system without bothering about internal knowledge of the software system. Black box testing is a software testing technique in which functionality of the software under test that is SUT is tested without looking at the internal core structure implementation details and knowledge of internal paths of the software. This type of testing is based entirely on the software requirements and specifications. These are the black box testing steps. So types of black box testing are functional testing. This black box testing type is related to functional requirements of a system. It is done by software tester. Next is non functional testing. This type of black box testing is not related to testing of a specific functionality. But non functional requirements such as performance scalability and usability. Last is regression testing. It is done after code fixes, upgrades or any other system maintenance to check the new codes have not affected the existing code testing strategy. First is equivalence class testing. It is used to minimize the number of possible test cases to an optimum level while maintenance reasonable test coverage. Next is boundary value testing. This technique determines whether a certain range of values are acceptable by the system or not. It is mostly suitable for the systems where input is within certain ranges. Third is decision table testing. A decision table puts causes and their effects in a matrix. This is a unique combination in each column. So advantages are efficient when used on large system. Testing is balanced and unpresurized due to independent tester and developer. Tester can be non technical. There is no need for the tester to have detailed functional knowledge of system. Test will be done from an end user's point of view. That is acceptance testing. Testing helps to identify vagueness and contradictions in functional specifications. Test cases can be designed as soon as the functional specifications are complete. Disadvantages, test cases are challenging to design without having clear functional specifications. Difficult to identify the key inputs if the test cases are not developed based on specifications. It is difficult to identify all possible inputs in limited testing time. As a result, writing test cases may be slow and difficult. There are chances of having undidentified paths during the testing process. There is a high probability of repeating tests already performed by the programmer. Now we will see system testing. It is testing of a complete and fully integrated software product. Usually software is one element of a larger computer based system. Ultimately software is interfaced with other software or hardware systems. System testing is actually a series of different tests whose sole purpose is to exercise the full computer based system. System test falls under the black box testing category of software testing. So this is the diagram for system testing. So what do we verify in system testing? System testing involves testing the software code for the following. Testing the fully integrated applications including external peripherals in order to check how components interact with one another and with system as a whole. This is also called end-to-end testing scenario. Verify thorough testing of every input in the application to check for desired output testing of the user's experience with the application. This is the software testing hierarchy. First is unit testing, next is integration testing, third is system testing, fourth is acceptance testing. So these are the types of system testing. System testing main focus areas are hardware interfaces, complex functionalities, system security, disaster recovery, performance testing, user interface, install ability, documentation, usability, load or stress testing, backward compatibility. So advantages are system testing covers full end-to-end testing. System software architecture and business requirements are both tested in system testing. Proper system testing helps in mitigating after production go live issues and bugs. System testing is conducted in an environment similar to production environment or sometimes it is done with broad parallel test environment where same data is feed to existing system and new system to compare the difference in functionality added and removed. Take a pause and answer this question. White box testing is also known as dash testing. The answer is all of these. So these are the references. Thank you.