Tag: CS-443

  • Security Testing

    Security testing is an important part of software development and testing. Security testing focuses on identifying security vulnerabilities such as malicious attacks, unauthorized access, and data breaches. Testing is done by verifying the system is compliant with security standards, evaluating security features and mechanisms, and conducting penetration tests to find weaknesses.

    Security testing plays a critical role in software testing for numerous reasons. Some of these include the protection of sensitive data, meets compliance requirements, and most importantly maintains trust. An application with strong security helps build trust among clients and end users because strong security makes users feel that they can use the application without their information being at risk to be compromised. Organizations are held to security standards that are used to regulate the minimum level of security in an application. Security testing can be used to identify security vulnerabilities and ensure the application meets the set standards.

    Main types of security testing

    There are many types of security testing based what the intended use is. For example there is security testing for software applications, web based applications, APIs, and more.

    Application security testing tests the security of a software application. The process includes a combination of automated and manual testing techniques such as code analysis, penetration testing, and security scanning.

    As the name suggests, web based application security testing focuses on identifying vulnerabilities in web based applications. Testing also involves a commination of manual and automated testing; however, what is actually tested differs from application security testing. This is because testing web based applications involves methods such as SQL injection testing, and cross site scripting testing.

    API testing evaluates the security of an application’s APIs and the systems that the APIs interact with. When testing APIs, various types of malicious requests are sent to the APIs and their responses are analyzed to find potential vulnerabilities. APIs are susceptible to specific threats such as denial of service attacks, API injection, and man in the middle attacks. Man in the middle attacks are where an attacker intercepts the API communication to steal sensitive information. Therefore the goal of API security is to ensure that they are secure from attacks and sensitive information is protected.

    Conclusion

    This article was chosen because it clearly explained what security testing is, why it is important, and the different types of security testing. This was important to me because I have a very little knowledge/experience with security testing. I enjoyed learning about security testing as it plays an essential role in software development because no one wants to use an application where their information could be compromised. In the future I intend to look further into standard security measures, and how to test them.

    Resources:

    https://www.hackerone.com/knowledge-center/what-security-testing#:~:text=Security%20testing%20is%20an%20important,unauthorized%20access%2C%20and%20data%20breaches.

  • Unit Testing

    Unit testing is a process in software testing where the smallest functional unit of code is tested. A common practice for unit tests is to first write the tests as code. Then the test code can be run automatically when changes are made. Doing this allows errors to be found, and isolated quickly if a test fails. Automating tests helps to ensure that efforts are focused on coding, rather than running tests.

    As stated previously, a unit test is a block of code that verifies the accuracy of the smaller blocks of the code such as a function. The unit test checks that the block of code runs as expected, determined by the developer’s logic. A block of code may have more than one unit test assigned to it, in order to cover the full behavior of the block of tested code.

    A block of code cannot be tested using a unit test because a unit test cannot use external data. Therefore the unit test needs to run in isolation. Because unit tests must run in isolation, this helps to improve the design of the code base to ensure that no function relies too heavily on other parts of the system. Doing this prevents code smells which can lead a rigid system due to insufficient modularization.

    Unit testing strategies

    There are strategies used when creating unit tests to ensure coverage of all test cases. Some of these strategies include error handling and numerous checks such as logic, boundary, and object oriented. Boundary checks and error handling are similar in the sense that they both check the behavior of the system based on inputs that are invalid/outside the expected input range. Object oriented checks ensure that the state of persisted objects are updated correctly. Lastly, logic checks ensures that the system performs as expected given a valid input.

    Benefits of unit testing

    A major benefit to unit testing is the increased efficiency when testing code and discovering bugs. Whenever the system code is changed, the same set of unit tests are run. If a test fails, it is easy to identify what caused the failure because tests are small and isolated. Therefore, unit tests help catch any bugs before the system reaches production. Another benefit to unit testing is unit tests act as another form of documentation. Unit tests act as documentation because developers can read the tests to see how to code should behave. Having accurate documentation is an important part of software, so that other developers know exactly what the expected behavior of the code is.

    Conclusion

    This article was chosen because I enjoyed that it explained when unit testing is less beneficial unlike other resources. This allowed me to understand when unit testing should, and should not be used. I enjoyed learning more about unit testing outside of class as it is such as integral part of software development. Therefore, I plan to implement unit testing in future projects to ensure system accuracy.

    Resources:

    https://aws.amazon.com/what-is/unit-testing/#:~:text=Unit%20testing%20is%20the%20process,test%20for%20each%20code%20unit.

  • Performance Testing

    Performance testing is the process of evaluating how a system performs under specific workloads. Responsiveness and stability of the system is monitored by examining the speed, reliability, and application size. Common indicators that are used for testing are network response times, number of users the system can handle at a time, processer memory consumption, and more.

    Performance testing is an important part of the software development process. If an application is not tested before being released, users may have a negative experience because of errors that could have been found in the performance testing phase. Users that have a negative experience may be deterred from using the application in the future resulting in fewer overall users. Performance testing aims to find these errors before release, so users can have the best possible experience

    When is performance testing done?

    In software development, there are two main phases: development and deployment. Development testing focuses on individual components such as web services, APIs, and microservices. The earlier development testing begins, the earlier errors can be caught. Catching these errors early in the development phase is important because as the code base progresses, there is more and more code building on top of code that may have errors. This can make fixing the error more complicated. As the application becomes larger, comprehensiveness of the tests should also scale alongside. However, the application may get to a point where testing in the development phase becomes unreasonable and testing is done during the deployment phase. This happens when testing involves replicating a production environment, but recreating the environment is too difficult or expensive.

    Types of Performance Testing

    There are many types of performance testing that are done throughout the development process to verify the application performs as expected and can meet user requirements. Some of these performance testing types are:

    • Load Tests – Tests the application under a realistic load by simulating virtual users. Response times are monitored, which can reveal potential bottlenecks to the system’s performance.
    • Stress Tests – Similar to Load Tests, but the number of simulated virtual users is greatly increased. This is to see how the application runs when under peak activity.
    • Soak Tests – Tests are conducted over an extended amount of time, as opposed to the tests mentioned above. This test is to evaluate how the system performs when under intense loads for a prolonged amount of time.

    Conclusion

    This article was chosen because it covered a variety of topics within performance testing, so I was able to gain a general understanding of what performance testing is. Performance testing is an important process in software development because it finds potential weak spots in a system. These weak spots can come from slow response times during peak activity, long load times, etc. Therefore, performance testing should be done on all systems to improve the user experience. In the future, I intend to look further into performance testing tools and frameworks to see how I can implement them in later projects.

    Resources:

    https://www.tricentis.com/learn/performance-testing

  • Behavior-Driven Development (BDD)

    Behavior Driven development is an approach where the focus is set on the behavior of an application for the purposes of a business. This focus is to find a common ground between developers, quality assurance teams, and business professionals. Common ground is found by defining behaviors that are written in plain language, allowing everyone to understand and agree upon the software’s behavior.

    BDD Process

    Behavior driven development begins with defining behaviors in “feature files” which are used throughout the development process. Behaviors are straightforward statements that outline a specific process in a predetermined format.

    Behaviors are written in a language called Gherkin, which use simple words such as “Given”, “When”, and “Then.” An example behavior would be, “Given the user enters an incorrect password, When they click the login button, Then they should be prompted with an error to reenter their password.” These behaviors are turned into tests with tools that check if the software behaves as intended. Because everyone is involved in this process, and agrees on the final product, confusion can be avoided.

    Advantages to BDD

    Behavior driven development leads to advantages that would otherwise be lost with other development approaches. A key advantage with BDD is better communication and collaboration. This is due to the nature of BDD as everyone from business, to quality assurance, to developers, meet together and plan everything. Because there is better communication, requirement understanding also increases. This is because requirements are explicitly defined, and everyone agrees what should be done. Due to the increase in requirement understanding, testers are made aware exactly what requirements should be tested. Ultimately the chances for the final product to be different than what was intended is less, saving time and effort.

    Disadvantages to BDD

    Because BDD is different from other development approaches, adopting the practice can be difficult. This is because teams are used to working amongst themselves, then meeting with the other teams once a final product, or an iteration of the final product has been completed. Waiting until a product has finished development before meeting the other teams can lead to wasted time and effort because what is actually delivered may be different than what the business team intended. Another reason why BDD can be hard to get used to is the overemphasis and learning curve with the tools necessary for BDD. Teams can get off track because they get caught up in learning Gherkin syntax and other tools.

    Conclusion

    This article was chosen because topics were easy to understand with the use of real world examples. Once past the learning curve, behavior driven development seems like a useful approach that fosters strong collaboration and communication. I was unaware of tools like Gherkin and Cucumber that are used to process the feature files, so learning about them was interesting. This approach is unlike others I have seen in the past; however, I am curious about how is all works. I will be looking into these tools in the future.

    Resources:

    https://www.browserstack.com/guide/what-is-bdd

  • Levels of Testing

    Levels of testing refers to the different stages of testing software during the development cycle. Each level of testing aims to test specific aspects of the functionality of the software. The most common types of testing levels are unit, integration, system, and acceptance testing. Unit tests focuses on individual components, or units, of the system such as functions. Integration testing is used to ensure that these units work together as intended. System tests verify that the entire system meets the requirements specified by the customer. Acceptance testing is similar to system testing in that the whole system is verified. However while system testing tests the entire system, acceptance testing tests the final system.

    Unit Testing

    Unit testing is conducted at the code level, where each individual component is tested and the results are analyzed. Rather than manually testing each component, automating unit tests is highly recommended to reduce errors in analyzing and for increased efficiency. When making a unit test, an outline stating the expected results of the code should be made.

    An example of an outline for a unit test for a calculator app that simply adds to numbers together would look like:

    • Program should accept two numbers
    • Program should return the sum of the two given numbers
    • Program should handle negative values appropriately

    Once the outline for the unit tests are made, then the actual code for the unit test should be written. The test will then check the code to verify it is doing what is expected once the test has run.

    Integration Testing

    Integration testing tests groups of individual components that are integrated into a system. This type of testing helps to identify any issue that may occur from coding errors or errors from the integration between units.

    System Testing

    System testing is performed on the application as a whole. All components are assessed against specific requirements made by the customer.

    Acceptance Testing

    Acceptance testing involves testing the final system. This includes the system’s functional and non-functional aspects such as performance, security, usability, and more. In this testing level, end users are given access to the software to ensure the end users’ needs are being met.

    Conclusion

    This resource was chosen because it clearly described the different testing levels, their purpose, and why each level is important. I enjoyed reading this article because it was written in a way that made understanding easy. In the future, when creating a complex system, I will be sure to follow the different stages of testing at the appropriate time in the development cycle to prevent issues later in development.

    Resources:

    https://testsigma.com/blog/levels-of-testing

  • Test Driven Development (TDD)

    Test driven development is a form of testing done in software development that focuses on creating unit tests before the actual code. Developers create small test cases for every feature with the intention of modifying the code only when the tests fail. Test driven development is also a practice that focuses on the structure of the code that allows for the creation of optimized code that remains reliable over time.

    TDD vs Traditional Testing

    As stated above, one of the main differences between TDD and traditional testing is that tests are created before the actual code unlike traditional. However some other differences include the testing scope and the processes that each form of testing follows. The testing scope in TDD focuses on testing small, individual pieces of the codebase whereas traditional testing tests the entire system including integration testing. The process of each type of testing also differs in that TDD is an iterative process. As tests are created, this process also includes cycles of developing small chunks of code, testing that code, then refining until all tests pass. An important part of the TDD process is refactoring. Once tests pass, it’s important to check the code if there are any optimizations that can be made, or if there is any redundancy that should be removed.

    Benefits to TDD

    Test driven development allows for the creation of optimized code by nature because of the process that TDD follows. Once code is written, if the tests fails then the developer is forced to go back and fix the code until the tests pass. The test coverage that TDD covers is greater than traditional testing methods. This is because before any code is written for a specific functionality, the test is created beforehand which ensures every function passes testing. Using test driven development also helps in reducing the number of larger, more complex issues that arise. This is because testing is done on a consistent basis, where development does not progress until each set of tests are complete.

    Conclusion

    I chose this article because it clearly explained what test driven development is, differences between traditional and test driven development, and the benefits. I also appreciated the use of examples the article used to further explain what the TDD approach would look like in real scenarios. Learning about different approaches to developing software is helpful because I am exposed to approaches that could be more useful than what I already know. I plan to try test driven development in the future.

    Resources:

    https://www.browserstack.com/guide/what-is-test-driven-development

  • Static vs Dynamic Testing

    Testing software and ensuring it works as intended is a crucial part of software development. Two approaches to testing are static and dynamic. Static testing involves testing the software without running the code, while dynamic executes the program and tests its behavior in various situations.

    Static Testing

    The term static testing comes from examining the code in a “static” state rather than actually running it. Because the code is never actually executed with static testing, the focus of testing is on analyzing the software’s documentation along with the design of the code, and the code itself. Static testing is most beneficial in the early stages of development. Since the code is never being executed, a fully working implementation is not required unlike dynamic testing. Issues identified early in development are easier and less costly to fix resulting in better maintainability, and decreased time and money spent in the long term. Some static testing techniques include informal reviews, walkthroughs, static code reviews, and more.

    Dynamic Testing

    Dynamic testing involves actually executing the software and testing its behavior based on various inputs. Test cases are created to conduct test runs to identify defects and ensure the software meets the required specifications. Along with testing the software with various inputs and comparing to the expected outputs, error conditions are also tested. Error conditions are inputs that are outside of the valid input range, and the software should be able to handle the invalid input without any unexpected behavior. Dynamic testing is performed after coding and development are complete, whereas static testing usually begins in the early stages of development. Because dynamic testing executes the code, the software must be far enough in development where the software functions, performs, and secure as intended. Those reasons are why dynamic testing is to be completed after development. Some dynamic testing techniques include unit testing, integration testing, and system testing.

    Conclusion

    This article was chosen because it clearly explained what static and dynamic testing are and the differences between them. The article was also easy to follow along. I enjoyed learning about when static and dynamic testing are most beneficial because I was unaware that static testing begins in the earlier stages of development while dynamic is performed after development. So far in my software development journey, I have not written many tests for the code I have written, and have mainly done manual testing which takes extra time and may have errors. Gaining insight in these techniques will be helpful when testing code in the future.

    Resource:

    https://www.guru99.com/static-dynamic-testing.html

  • Black box vs. White box vs. Gray box Testing

    Black box testing

    Black box testing focuses on the behavior of the software on a surface level. This means the tester cannot see any technical details such as code or the structure. Testers are not concerned about the inner workings of the software, rather only on the inputs and outputs. Therefore black box testing comes from the perspective of the user which allows testers to uncover any bugs and/or design flaws that would directly affect the user’s experience.

    Some black box testing procedures include boundary value analysis, equivalence partitioning, and decision table testing. Boundary value analysis tests whether the software results in the correct output when the input contains the lower or upper limit of the input range. Equivalence partitioning groups all possible inputs into categories, which can reduce the number of total test cases. Finally, decision table testing involves grouping inputs into a table and testing how the software behaves when those inputs are combined.

    White box testing

    White box testing is the opposite of black box, meaning testers are given the internals of the system such as the code, the structure, and how its implemented. White box testing allows testers to fully understand how the software is executed. Having access to the internals of the software can help testers find issues related to security vulnerabilities, broken data paths, etc. while black box testing could not focus on those type of issues.

    White box testing can be completed with a few techniques. These techniques include statement, branch, and path coverage. Statement coverage ensures that every statement in the code is run and tested at least once. Branch coverage executes all possible branches (i.e. conditional branches) in the code to be tested. Path coverage uses test cases to cover all possible execution paths throughout the software.

    Gray box testing

    Gray box testing combines black and white box testing into one. Therefore testing can be done from the perspective of the user, while still having access to the software’s internal code. Gray box testing is helpful when identifying problems that may otherwise be hard to find with other types of testing.

    A couple techniques that are used in gray box testing are Matrix and Regression testing. Matrix testing looks at all variables in the code and assesses its risk level. Doing this can identify unused/under-optimized variables. Regression testing checks that software changes or bug fixes do not create new errors.

    Reflection

    This article was chosen because it clearly described the different types of box testing, and what each does. While reading the material, I realized that what we have done in class (equivalence class, boundary value testing) are actually black box testing techniques. I enjoyed learning about the different techniques that are used, and the benefits of them. Although developers and testers are two different roles, developers sometimes play the role as the end user when black box testing, so having a basic understanding of the different types of box testing will be helpful in the future.

    References:

    https://www.shakebugs.com/blog/black-vs-white-vs-grey-box-testing

  • Welcome to my blog for CS-443! My name is Zack Tram and am a senior completing my undergraduate CS degree. In the upcoming weeks, I’ll be posting about topics relating to various software testing methodologies

    I look forward to completing my degree this semester, and everything that comes with it!

Design a site like this with WordPress.com
Get started