Apprenticeship Patterns Blog – Nurture Your Passion

For this week’s blog post, I read the section  “Nurture Your Passion ” from chapter two of the book Apprenticeship Patterns by Dave Hoover and Adewale Oshineye. The section talked about how the work environment can stifle the passion for the craft. For example, you might be a software developer with a passion for the craft, but unfortunately the daily activities, “demoralizing corporate hierarchies, project death marches, abusive managers, or cynical colleagues.” Can become hard for your passion to grow by staying in such hostile conditions. I think this is true for the majority of the people that work in the IT field. I have seen especially my family members whose having such a hostile situation at work especially when there is a deadline that is approaching, or a software release is going on.

The author goes further into project death marches in which he explained how they are the most damaging of the hostile situations, it takes your time and energy, preventing you from taking any significant actions to protect your passion as more important issues like physical and mental health can take a toll. Now that I think about it, work pressure and stress can significantly affect one’s mental health.  I think it is important for people to take a break from sometimes and focus on something else for a little time. Identify what u like, find something at work that interests you and you enjoy doing. I liked the solution that was given to this problem which was: to grow your passion, set clear boundaries that define the sort of environment you are willing to work in. I think that creating some sort of boundaries helps and necessary to have a free hostile environment. One of the statements I do not agree with the author is how walking out of a meeting or refuse to distribute code that doesn’t meet your minimum standards will help your passion however this type of behavior can cause a conflict between your colleagues or your boss. I think the best solution if you want to follow your passion is just to do it, nurture your passion or find a job that suits well for your passion.   

From the blog Derin's CS Journey by and used with permission of the author. All other rights reserved by the author.

Boundary Value Testing and Equivalence Class Testing

Due to their being a large capacity of data that is used for software, there needs to be test implementation that can test the range of values without testing each number. Therefore, we used testing methods such as boundary value testing and equivalence class testing. The purpose of boundary value testing is to test the extreme ends or also known boundaries hence the name. The most common way to implement this test case is to use input variable values such as a minimum value, a value just higher than minimum, a middle value none as the nominal, a value that is just lower than the maximum and the last is the maximum value. One common example that most have seen is when we have to set up a password. Let’s say that a valid number length for the password has to be between 10 and 15. Using this guide, our boundary value testing would consider values that are less than, ones that are 10, ones that are between 10 and 15, ones that are 12 and ones that are greater than 15. Now the valid inputs will be passwords that are between 10 and 15 and so boundary value testing implementations are a good way to test any input errors that are more near the boundaries of valid numbers.

Equivalence class testing is a method of testing that divides the input of the data into various different equivalence classes. This step is the partitioning of the values that need to be tested and is the step that comes before boundary testing. The accurate values that are considered acceptable inputs are divided into a certain range, and the values under as well as over are considered invalid or unacceptable to the software. The valid class partition keeps all the valid values or inputs in it and the invalid class partition contains the invalid values and partition. The example is same as the password one and how the password that in the acceptable range of 10 to 15 will be accepted and valid, whereas passwords that are less than 10 or more than 15 will be invalid and won’t be accepted. Overall, boundary and equivalence class testing are good testing implementations to test input values without having to try to test all the individual values.

Resources:

Boundary Value Analysis and Equivalence Class Partitioning With Simple Example

https://www.guru99.com/equivalence-partitioning-boundary-value-analysis.html

From the blog CS@Worcester – Roller Coaster Coding Journey by fbaig34 and used with permission of the author. All other rights reserved by the author.

Difference Between Black-Box, White-Box

 White-box or glass-box testing is testing from a program’s source code without using the user interface. This type of testing needs to look at code syntax to find flaws or errors in the internal code in algorithms, overflows, paths, conditions, and so on, and then fix them.

Black-box testing, or black-box testing, is rigorously tested by using the entire software or a software function without examining the source code of the program or having a clear understanding of how the program or the source code of a software function was designed. Testers understand how the software works by entering their data and seeing the results. Typically, testers run tests using not only input data that is guaranteed to give correct results but also input data that is challenging and may result in errors in order to understand how the software handles various types of data.

The program under test is treated as a black box, without considering the internal structure and characteristics of the program. The tester only knows the relationship between the input and output of the program or the function of the program and determines the test cases and inferences the correctness of the test results by relying on the requirement specifications that can reflect the relationship and function of the program.

Black box testing of software is used to verify the correctness and operability of software functions. Treat the program as a black box, without considering the internal structure of the program box processing. In the program interface test, just to check whether the program function in accordance with the specification of the normal use. Black box testing is also called functional testing or data-driven testing.

White-box testing is exhaustive path testing, and black-box testing is exhaustive input testing. These two methods are based on completely different points of view, reflecting the two extremes of things. They have their own emphasis and advantages, but they cannot replace each other. In the modern concept of testing, the two methods are not separate but intersect.

It relies on the careful examination of the details of the program, the design of test cases for specific conditions, and the testing of the logic path of the software. Check the “state of the program” at various points in the program to see if the actual state corresponds to the expected state. White-box testing of software is used to analyze the internal structure of a program.

sources:

Difference Between Black-Box, White-Box, and Grey-Box Testing

From the blog haorusong by Unknown and used with permission of the author. All other rights reserved by the author.

Difference Between Black-Box, White-Box

 White-box or glass-box testing is testing from a program’s source code without using the user interface. This type of testing needs to look at code syntax to find flaws or errors in the internal code in algorithms, overflows, paths, conditions, and so on, and then fix them.

Black-box testing, or black-box testing, is rigorously tested by using the entire software or a software function without examining the source code of the program or having a clear understanding of how the program or the source code of a software function was designed. Testers understand how the software works by entering their data and seeing the results. Typically, testers run tests using not only input data that is guaranteed to give correct results but also input data that is challenging and may result in errors in order to understand how the software handles various types of data.

The program under test is treated as a black box, without considering the internal structure and characteristics of the program. The tester only knows the relationship between the input and output of the program or the function of the program and determines the test cases and inferences the correctness of the test results by relying on the requirement specifications that can reflect the relationship and function of the program.

Black box testing of software is used to verify the correctness and operability of software functions. Treat the program as a black box, without considering the internal structure of the program box processing. In the program interface test, just to check whether the program function in accordance with the specification of the normal use. Black box testing is also called functional testing or data-driven testing.

White-box testing is exhaustive path testing, and black-box testing is exhaustive input testing. These two methods are based on completely different points of view, reflecting the two extremes of things. They have their own emphasis and advantages, but they cannot replace each other. In the modern concept of testing, the two methods are not separate but intersect.

It relies on the careful examination of the details of the program, the design of test cases for specific conditions, and the testing of the logic path of the software. Check the “state of the program” at various points in the program to see if the actual state corresponds to the expected state. White-box testing of software is used to analyze the internal structure of a program.

sources:

Difference Between Black-Box, White-Box, and Grey-Box Testing

From the blog haorusong by Unknown and used with permission of the author. All other rights reserved by the author.

Difference Between Black-Box, White-Box

 White-box or glass-box testing is testing from a program’s source code without using the user interface. This type of testing needs to look at code syntax to find flaws or errors in the internal code in algorithms, overflows, paths, conditions, and so on, and then fix them.

Black-box testing, or black-box testing, is rigorously tested by using the entire software or a software function without examining the source code of the program or having a clear understanding of how the program or the source code of a software function was designed. Testers understand how the software works by entering their data and seeing the results. Typically, testers run tests using not only input data that is guaranteed to give correct results but also input data that is challenging and may result in errors in order to understand how the software handles various types of data.

The program under test is treated as a black box, without considering the internal structure and characteristics of the program. The tester only knows the relationship between the input and output of the program or the function of the program and determines the test cases and inferences the correctness of the test results by relying on the requirement specifications that can reflect the relationship and function of the program.

Black box testing of software is used to verify the correctness and operability of software functions. Treat the program as a black box, without considering the internal structure of the program box processing. In the program interface test, just to check whether the program function in accordance with the specification of the normal use. Black box testing is also called functional testing or data-driven testing.

White-box testing is exhaustive path testing, and black-box testing is exhaustive input testing. These two methods are based on completely different points of view, reflecting the two extremes of things. They have their own emphasis and advantages, but they cannot replace each other. In the modern concept of testing, the two methods are not separate but intersect.

It relies on the careful examination of the details of the program, the design of test cases for specific conditions, and the testing of the logic path of the software. Check the “state of the program” at various points in the program to see if the actual state corresponds to the expected state. White-box testing of software is used to analyze the internal structure of a program.

sources:

Difference Between Black-Box, White-Box, and Grey-Box Testing

From the blog haorusong by and used with permission of the author. All other rights reserved by the author.

Expose your ignorance AND confront your ignorance

If you want to reassure them, it should also be through your ability to learn, not by pretending to know what you don’t. In this way, your reputation will be based on your ability to learn, not on what you already know. The easiest way to expose ignorance is to ask questions.

People often disguise their ignorance by pretending to know a great deal about their field. But they forget that knowledge is acquired by knowing one’s own ignorance. Knowing your ignorance, and then study hard to improve your knowledge reserve, is a craftsman needs to have and cultivate the basic quality. Because no one can know all the knowledge in their field, it is through their own ignorance and facing their own ignorance that you can truly achieve the omniscience you need to achieve. It takes a certain amount of courage to recognize and face your ignorance correctly. But in the show you will find that often standing on top of the people they will be very open to accepting their own ignorance, and open to learning. Often it is the people who are afraid to face their ignorance that have little knowledge of their own territory.

Pick a skill, tool, or technique and actively fill in the knowledge gaps associated with it. Do it in the way that works best for you. For some, the best approach may be to read all the literature and FAQs available to get an overview. Others may feel that building a “crunchy toy” is the most effective way to understand something. Whichever method works for you, don’t forget to ask around with your “peers” and mentors to see if anyone has already mastered the skill and is willing to share what they’ve learned. Sometimes others may be learning the skill, and you’ll progress faster by working with them. At some point, you will have reached a satisfactory level of competence in this new area, and you can decide whether it is more productive to dig deeper or to turn your attention to other skill gaps. With only 24 hours in a day, you can’t grind every skill to a very high level, so you have to learn to make the necessary tradeoffs between them.

It’s not just about conquering previously unknown peaks, it’s about carving out a new path, step by step.

From the blog haorusong by Unknown and used with permission of the author. All other rights reserved by the author.

Expose your ignorance AND confront your ignorance

If you want to reassure them, it should also be through your ability to learn, not by pretending to know what you don’t. In this way, your reputation will be based on your ability to learn, not on what you already know. The easiest way to expose ignorance is to ask questions.

People often disguise their ignorance by pretending to know a great deal about their field. But they forget that knowledge is acquired by knowing one’s own ignorance. Knowing your ignorance, and then study hard to improve your knowledge reserve, is a craftsman needs to have and cultivate the basic quality. Because no one can know all the knowledge in their field, it is through their own ignorance and facing their own ignorance that you can truly achieve the omniscience you need to achieve. It takes a certain amount of courage to recognize and face your ignorance correctly. But in the show you will find that often standing on top of the people they will be very open to accepting their own ignorance, and open to learning. Often it is the people who are afraid to face their ignorance that have little knowledge of their own territory.

Pick a skill, tool, or technique and actively fill in the knowledge gaps associated with it. Do it in the way that works best for you. For some, the best approach may be to read all the literature and FAQs available to get an overview. Others may feel that building a “crunchy toy” is the most effective way to understand something. Whichever method works for you, don’t forget to ask around with your “peers” and mentors to see if anyone has already mastered the skill and is willing to share what they’ve learned. Sometimes others may be learning the skill, and you’ll progress faster by working with them. At some point, you will have reached a satisfactory level of competence in this new area, and you can decide whether it is more productive to dig deeper or to turn your attention to other skill gaps. With only 24 hours in a day, you can’t grind every skill to a very high level, so you have to learn to make the necessary tradeoffs between them.

It’s not just about conquering previously unknown peaks, it’s about carving out a new path, step by step.

From the blog haorusong by Unknown and used with permission of the author. All other rights reserved by the author.

Expose your ignorance AND confront your ignorance

If you want to reassure them, it should also be through your ability to learn, not by pretending to know what you don’t. In this way, your reputation will be based on your ability to learn, not on what you already know. The easiest way to expose ignorance is to ask questions.

People often disguise their ignorance by pretending to know a great deal about their field. But they forget that knowledge is acquired by knowing one’s own ignorance. Knowing your ignorance, and then study hard to improve your knowledge reserve, is a craftsman needs to have and cultivate the basic quality. Because no one can know all the knowledge in their field, it is through their own ignorance and facing their own ignorance that you can truly achieve the omniscience you need to achieve. It takes a certain amount of courage to recognize and face your ignorance correctly. But in the show you will find that often standing on top of the people they will be very open to accepting their own ignorance, and open to learning. Often it is the people who are afraid to face their ignorance that have little knowledge of their own territory.

Pick a skill, tool, or technique and actively fill in the knowledge gaps associated with it. Do it in the way that works best for you. For some, the best approach may be to read all the literature and FAQs available to get an overview. Others may feel that building a “crunchy toy” is the most effective way to understand something. Whichever method works for you, don’t forget to ask around with your “peers” and mentors to see if anyone has already mastered the skill and is willing to share what they’ve learned. Sometimes others may be learning the skill, and you’ll progress faster by working with them. At some point, you will have reached a satisfactory level of competence in this new area, and you can decide whether it is more productive to dig deeper or to turn your attention to other skill gaps. With only 24 hours in a day, you can’t grind every skill to a very high level, so you have to learn to make the necessary tradeoffs between them.

It’s not just about conquering previously unknown peaks, it’s about carving out a new path, step by step.

From the blog haorusong by and used with permission of the author. All other rights reserved by the author.

Static vs Dynamic Testing

Two common methods used for software testing are static and dynamic testing. Now, although they are both testing methods, there are a lot of differences between them. First we need to define what each of them are. Static testing is when we test the software to look for errors or defects, but we are not going to actually execute the code. Now on the other hand, for dynamic testing we test the software by executing the code and see if there is any errors with inputs and overall function of the software. Static testing is conducted with specific documents related to the software and the goal is to find errors early on in the development cycle before the software gets too advanced. Dynamic testing executes the code and analyzes things such as the input and output of the software to determine the correct results. The goal for dynamic is to test the functional behavior of the code and also takes into account memory, CPU as well as the performance of the software put together. Static testing uses manual or automated testing of the documents by examining things such as the requirements for the software, the source, necessary test cases or any thing related to the overall design. Dynamic testing is more direct testing to whether the software works by using techniques such as black or white box testing and it confirms that the code works in the way it is desired to.

The main differences between static and dynamic is one thing we stated earlier about how static won’t be executed, whereas dynamic will. Another important factors is the stages with where these tests occur, as static happens early in the process of developing software, whereas dynamic is towards the end or completion stage. The goal of static testing is to prevent any bugs or errors from being produces, but dynamic tests finds bugs or errors that were created with the development of the software. Static testing is more simply known as the verification process, whereas dynamic testing is more about the validation process. Static testing is known to generally take shorter time, whereas dynamic will take a little bit longer due to the variance of test cases that need to be implemented. Overall, both of these testing methods are important in the development of software, but they occur at different stages and can be helpful to do both efficiently to lead to the least amount of error in the software.

Resources:

https://www.geeksforgeeks.org/difference-between-static-and-dynamic-testing/ https://www.guru99.com/static-dynamic-testing.html

From the blog CS@Worcester – Roller Coaster Coding Journey by fbaig34 and used with permission of the author. All other rights reserved by the author.

Boundary Value and Equivalence Class Testing

This week in the Software Quality Assur&Test class we got the third assignment that was about Boundary Values and Equivalence Class Testing. We had worked during class time in different activities that covered this assignment so I would say I really enjoyed working in this assignment. We had to complete three parts each with a different level of difficulty. I learned to understand more of the way testing works and what exactly get tested.

What we covered in this homework:

Boundary testing is the process of testing between extreme ends or boundaries between partitions of the input values.

Robust Boundary Values. Introducing outside of boundary values.

Equivalence Class Testing, which is also known as Equivalence Class Partitioning (ECP) and Equivalence Partitioning, is an important software testing technique used by the team of testers for grouping and partitioning of the test input data, which is then used for the purpose of testing the software product into a number of different classes.

Weak Normal Equivalence Class Testing: In this first type of equivalence class testing, one variable from each equivalence class is tested by the team. Moreover, the values are identified in a systematic manner. Weak normal equivalence class testing is also known as single fault assumption.

Strong Normal Equivalence Class Testing: Termed as multiple fault assumption, in strong normal equivalence class testing the team selects test cases from each element of the Cartesian product of the equivalence. This ensures the notion of completeness in testing, as it covers all equivalence classes and offers the team one of each possible combinations of inputs.

Worst-Case boundary value analysis is a Black Box software testing technique.

In Worst case boundary value testing, we make all combinations of each value of one variable with each value of another variable.

Edge Testing is a combination of Boundary Value Analysis and Equivalence Class Testing.

Weak Robust Equivalence Class Testing: Like weak normal equivalence, weak robust testing too tests one variable from each equivalence class. However, unlike the former method, it is also focused on testing test cases for invalid values.

Strong Robust Equivalence Class Testing: Another type of equivalence class testing, strong robust testing produces test cases for all valid and invalid elements of the product of the equivalence class. However, it is incapable of reducing the redundancy in testing.

From the blog CS@Worcester – Tech, Guaranteed by mshkurti and used with permission of the author. All other rights reserved by the author.