HW14: Testing Reflections

I think it was interesting how the author exposed the programmer's typical lack of enjoying testing by connecting it with an admission of failure, by developers. I never thought about how an individual's ego might play into what types of positions they might prefer in the development process.

There is a distinct difference between testing and debugging that I have just now clarified upon completing this reading. Testing is the act of identifying bugs. Debugging is the act of finding solutions to these bugs.

When discussing the builder VS the buyer of software products, I thought it would be even more beneficial to have them come from the same company. To me, this provides integrity and accountability, because the builders know that there is an error, the buyers will have direct contact to ask them about an error or mistake that occurred. The author seems to think that having the builder and buyer from the same company clouds the accountability heavily because the motivation for quality standards disappear.

Chapter 8 that is based on testing brought up the topic of inspections. Software inspections are different than testing because they check system requirements, source code, design models, and system tests. Some of the advantages of inspections are revealing errors that testing can mask, the ability to inspect incomplete versions of a system at no additional cost (because no specialized tests need to be developed), and a thorough check of the overall quality attributes involving inefficiencies and poor programming styles, for example.

It showed the value of inspections is so valuable to the process of testing. My question is why is there not an entire section dedicated to it in the fundamental ideas of software engineering? The fundamental ideas are the software development process, software dependability, requirements engineering, and software reuse. The software development process is comprised of specification, development/ design, validation (including testing), and evolution.

I understand that inspections are only powerful when used before testing as they are not good at discovering defects that happen between a variety of parts to the main program. Inspections are also an additional cost and time consuming, but if they help with expediting testing why would a company not want to include inspections in their process?

HW13: Chapter 8

Ex 8.7

Q: Write a scenario that could be used to help design tests for the wilderness weather station system.

A:

Jasmine is a software engineer that works for the wilderness weather station. She is in charge of testing all of the software utilized daily. She starts off her day by logging into the station system (if there are no errors). She checks that the weather station system is transmitting data to the management system by inserting obvious mock data and then removing it. She then logs into the weather forecasting system to see if the data management system is archiving its data properly, so it can be accessed by other systems. If she doesn't receive a report of the problems she will know there is a problem with the station maintenance system. In this case she would need to check if there is an update needed for the embedded software in the systems. Lastly, if there is an issue she can remotely navigate into the system and investigate the problem.

---

Ex 8.10

Q: A common approach to system testing is to test the system until the testing budget is exhausted and then deliver the system to customers. Discuss the ethics for this approach for systems that are delivered to external customers.

A:

ACM Code of Ethics 1.2 Avoid Harm to Other

In order to avoid harm, we need to allocate a set budget and amount of time to testing the software product being developed.

ACM Code of Ethics 2.1 Strive to achieve high standards of professional competence, conduct, and ethical practice

If we are only testing till the budget is exhausted, we are not holding ourselves to a high standard of professional competence. By having professional competence, we would generate a list of mandatory tests needed to test all of the potential errors in our code.

Collaborated with Chandler Long

HW12: Mythical Man Month & Agile

A woe the Mythical Man-Month, by Frederick P. Brooks, Jr., addresses is creating a product that has now become obsolete. This specific woe spoke to me, as it has always been a huge fear of mine. I can not imagine what it feels like to have all your hard work go down the drain, simply because you were too late.

“A man-month as a unit for measuring the size of a job is a dangerous and deceptive myth…only when a task can be partitioned among many workers with no communica- tion among them”. I think it's interesting how a man and months are interchangeable when it comes to a task being performed. I feel like this would not settle well if spoken about in today's society openly when it comes to human rights and such topics. 

“Computers are young, programmers are younger, and the young are always optimists.”  This stuck out to me for the reason that I would like to remain at the same level of optimism throughout my life. I have seen how maintaining this is a valuable trait has helped adults throughout their careers, weather this is in consideration to morale or longevity. I strive to be the sweet spot between optimistic with realistic expectations.

It seems like testing is not nearly as valued or allocated time as it should be in the industry. In classes we always discuss the importance of it, but based off of what I am hearing from classmates who have worked in the industry, this is an extremely flawed process that sometimes is not even carried out in their fullest way.

Scheduling a Software Task:

⅓ Planning

⅙ Coding

¼ component test and early system test

¼ system test, all components in hand

I think it is interesting how the author has successfully allocated his time as this is his personal standard. Whenever I thought about this subject the breakdown I had always thought of being ¼ planning, ½ programming, and ¼ testing. I understand where he derives these values from and will put it into practice on my next project.

Since the article was written before Agile was created, through the explanation of its problems it is clear to see why agile was created. The Agile Manifesto and most principle related documents that I have read since reading the ACM Code of Ethics and SE Code of Ethics seem to stem from each other. I am starting to see very much of ethical overlap. I personally really enjoy pairing the Agile Method and Scrum simultaneously. When we were introduced to it in ImpactX, a class that helps you design a potential startup, scrum helped us stay on task and removed the majority of possible communication problems. This is not a popular opinion about Scrum , as I have learned from my classmates and friends, but I found that it really boils down to who the team is made up of. If everyone on the team is proactive and motivated, it seems to work in the team's favor. In order to maximize your man-month hour, one could suggested agile development to maximize man hours in that month.