I am working with two FTP servers at work and am writing tests for the application we run on it. The test case I am handling right now involves having no application, no backup, and no valid application on the FTP server that will FTP it to the machine. I get an Updater FTP error. After 1s, 2s, 3s, 1m, 10m, and 1 hour it will reboot the machine and since I only have it in the log files to prove that, I need to have the test know when this reboot happens. So I am pinging the machine once a sec for 4,266 seconds and when it goes offline, it will return false.
I encountered a problem I want to document for the future in case anyone else or myself forgets this will happen.
On any other machine, a ‘Destination Host Unreachable’ error will be False, but if you specify identifying the machine as Windows, it will still return true.
Explain software testing and two other means of quality assurance and how they are applied.
Using software tests and analyzing code coverage is one software testing technique, but that is not the only way to test the quality of the software. Testing is often thought to be just running unit tests or executing test suites, but the reality is that testing has an entire life cycle of its own, very similar to the Software Development Life Cycle. This life cycle means the entire testing approach is a multi-faceted process and has many techniques. Testing is not only about making tests pass, but provides information about the software in terms of finding defects, isolating failures, preventing future defects, gaining confidence in the quality of the system, and meeting entry and exit criteria specifications according to standards, policies, laws, or requirements. Three techniques I want to explain are Test Plan, Regression Testing, and Exit Criteria.
A Test Plan is very important to a project. This plan is document outlining the scope, approach, resources, and schedule of intended test activities. It also outlines who will be doing the testing, when they will do it and degree of autonomy, test design techniques, and entry and exit criteria (Black, 2012). It outlines the entire process and enables testers to start testing early, which prevents exponential costs by having to fix a problem in production. A plan helps identify any weaknesses in the strategy so the team can plan accordingly.
Regression testing is very simple to explain. Once you have all passing tests and the software has been modified by the team or a feature has been added, those same tests will be ran first to make sure that the new code did not break anything that was previously working. If any defects have been introduced, this will identify them (hopefully).
Lastly, exit criteria is important for testing. This criteria is previously agreed on by the stakeholders and allows a project or task to be complete. This protects the stakeholders by not allowing a task to be completed when there are still parts incomplete and also gives the software developers a set of metrics to gauge the software against to know when to end the task and when to stop testing.
This is three test strategies that are common in testing, but testing will be unique in every situation. For example, software that is used where lives are at risk have a more complete and exhaustive list of testing strategies than a game we play on our phone. Keeping this in mind will help see that testing is a very organic process and can be built to assure the level of quality needed for each project.
Black, R. Foundations of Software Testing ISTQB Certification. [Capella]. Retrieved from https://capella.vitalsource.com/#/books/9781305175594/
Testing can focus on various aspects of a system or software. These aspects can include a focus on functionality, or what the system does, or on non-functionality, how the system does it what it does. It can also include testing on the system’s structure, changes to the system, if changes are successful, and if any unintended side effects happened. These four levels of test types are called functional, non-functional, structural, and change related. In this post, I will examine functional testing and testing pertaining to changes.
Functional testing involves testing the specified behavior or “what it does” and may be performed at all test levels. Specification-based testing is also known as “black-box testing” since it tests without reference to the internal structure of the component or system (Black, 2012). The testing focus for functionality testing is usually suitability, interoperability, security, accuracy, and compliance, according to ISO 9126 standards. There are two main approaches to using this test type: requirements-based or business-process based.
Requirements-based testing can take the requirements from the table of contents of a specification document and use them as a test basis for creating the tests. Business-based requirements are focused more on use cases from business processes. In a payroll system, for example, business processes would include when an employee joins the company or how often employees are paid.
Testing related to changes involves confirmation and regression testing. After a failed test, a defect is found and fixed. Confirmation testing involves re-testing the code in the same way and make sure that the new code did not bring in any unintended side effects and can be used at all test levels. Regression testing is used as a follow up to confirmation testing.
Regression testing involves executing test cases that have already been completed and most likely passed the last time they ran. We must organically grow the regression test suite over time in line with the software just as we do with unit tests. Should one of these tests now fail, we will have found a new defect introduced to the system. Regression testing should be performed at all test levels, specifically when a new version of the software is created, or the software environment changes.