Software Testing
Unit 1: Systems
Unit 1: Systems
First, let's look at an overview of software development models.
Notes Update
Today/Tomorrow, add the following in your notes:
- debugging
- validation vs verification
- testing & types of testing:
-- dry-run
-- functional
-- unit
-- integration
-- user acceptance
-- alpha
-- beta
- types of data used in testing:
-- normal
-- at the limits
-- extreme
-- abnormal
Today's focus is on testing software and systems. We briefly looked at testing already, but today we'll go a bit deeper into it. Testing is used to check for potential costly bugs, verify the system and related processes run successfully, as well as to validate that the product or system meets the requirements.
The systematic process of correcting (and finding) bugs or errors in a program is referred to as debugging.
Traditionally, testing was not a big thing. It was often an afterthought after the product was basically done. Now, in present times, testing is huge. It has become its own specialized area, and some people make whole careers just out of testing.
Let's take an overview of testing. This, however, is not exhaustive. There is much, much more you can learn about testing if this is an area of interest for you. You can also check out a variety of resources on LinkedIn Learning related to testing.
Firstly, testing can be divided into two categories, dynamic and static.
Dynamic testing relates to directly using the system to test it. That is, you are actually running and operating the software or system (or a portion of it) for testing. For example, if you write a python program that calculates the interest gained on a CD available at your bank over years of time, a dynamic test would be to actually run it and make sure what the program says matches what it should say.
Static testing relates to testing where the software or system is not actually run. You may be analyzing the algorithm design, reviewing the code, or checking client's requests related to the design documents. Examples of static testing includes methods such as reviewing technical documentation related to the software's design, or dry-runs. A dry-run is when you manually move through the code with pen-and-paper, to determine the expected outcome when the code is executed.
There are a variety of methods related to testing.
Functional testing relates to testing individual commands, text input, menu functions, etc. For example, if try to take a photo on your phone's camera app, does it take a picture? If you tell it to delete the picture, does it actually delete it? Unit testing relates to separately testing the individual components or parts of the system or software. These are both in contrast to integration testing, where the components are testing together within the system or software to verify that everything works correctly with each other.
User acceptance testing relates to determining if the system satisfies the customer's needs. This is usually done on-premise before the system or software is shipped or trasnfered to the customer. This is more common when a system or software is specifically designed for a specific client, and not a software provided for the general public.
Last, let's look a little more at integration testing, as well as look at incremental testing. When we test different parts of a system or software, this also often includes inputting data to verify whether or not the system returns the expected output. There are different types of data we use to test these components. We'll also look at those.
A few final notes related to testing before we move on.
As we looked over the concepts of testing, this all predominantly relates to testing by developers and QA (quality assurance) professionals. This may include a 3rd party organization outside of the company that is contracted specifically for testing.
Additionally, you should also be aware of alpha and beta testing. Alpha and beta testing goes beyond the developers testing the software in specific testing environments, and instead is closer to testing the software or system out in the wild.
In alpha testing, the software or system is released to those within the company or organization who are not specifically involved in the development or implementation of the product. For example, if you are a developer for Apple's Final Cut Pro software, when a new iPhone model is available, they may ask if you'd like one of the early models that's still in testing. This allows them to get feedback and testing data more similar to how actual customers would use the new phone model.
In beta testing, the software system is available to the public (or a group consisting of the public). As this includes the actual public, this is the closest and most realistic testing data a company or organization can get before the product is fully available. At this point, the product should be very stable, and testing may be more related to any unusual cases where the system or software may interact in an unexpected way with other software or systems, or also as a stress test if the system or software has to connect to servers or other internet-based resources.
You may wonder why we do alpha testing, and don't just jump to beta testing. When a product goes out to the public, even if it is a beta test, they still are expecting a pretty stable product. Any major issues that weren't caught before beta testing could create negative connotations or reputations for the software and company. The whole product should be tested quite thoroughly before the beta test.