cooperative-software-development icon indicating copy to clipboard operation
cooperative-software-development copied to clipboard

Verification: rationale for choosing

Open amyjko opened this issue 4 years ago • 0 comments

A question I like the chapter to answer is why unit tests, integration tests, and regression tests are common testing methods in software engineering. Though the chapter does do a good job at explaining and giving examples of each, I still don’t understand why they are so commonly used. Is it because a well-known programmer started using these specific tests so that is why it is so popular or is it because these are the easiest test to do so that is why it is so common?

The part that I was confused about and had to reread a couple times was the explanation on empirical and analytical approaches related to manual and automated techniques. The definitions of empirical and analytical approaches weren't as explicit and was more embedded within the sentences and examples, but I think it would be helpful to have an explicit definition and comparison of the two. Maybe a small table that holds the empirical, analytical, manual and automated techniques with examples in each would make it easier for me to learn, as I'm a visual learner that would appreciate a graphic instead of text with several vocabulary at once.

I felt that the chapter could have allocated more to explaining the reasons why programmers might not use the described verification methods (testing, analysis). It seems that there are many positives to verifying your code, so it would be interesting to learn more about why programmers (students are an example of programmers that find testing tedious) would choose not to verify. Is the reason for this simply the time and effort required to run these tests or conduct an analysis?

Overall, I thought this chapter was very important, as verification is essential in the software development process. In the programming classes I took, I was told to verify a function or a certain portion of the code after writing it so that I knew whether it worked or not before moving on. It was surprising to learn that “modern developers don’t test as much as they think they do.” Something I would like to perhaps see another sentence or two on for clarification purposes is why students tend to go with manual tests more often than automated ones. Is it because that’s what they’re more used to or more comfortable doing? It’s understandable as to why they end up regretting it later, since it takes up more time and money to test manually. Another question I have is whether teams or managers ensure there is testing of a certain aspect of the software at a certain stage in the development process, and why they don’t if they don’t. Personally though, I learned a lot in this chapter that I didn’t know before, such as the different types of test and verification from a more analytical standpoint through logic.

amyjko avatar Nov 11 '20 19:11 amyjko