CSE 370: Software Engineering Principles

W04 Team Activity: Case Study Discussion

Overview

Meet with your team and follow this outline to discuss this week's case study.

Instructions

(Before the meeting) Prepare yourself

Before meeting with your team, you need to:

If you have not read the case study you will not be able to participate with your team.

Begin with prayer

The lead student should ask someone to pray to begin the meeting.

Review the case study basics

Discuss the following:

  1. Why was Radiant Shutters seeking a new system?
  2. What were the key components of the system that required detailed testing?
  3. What did Brice propose to do to save roughly 20% on the product?
  4. How did the employees of Radiant Shutters respond to the early demo of the new software?
  5. At the end of the case study, why does Brightside need to stop work on the Radiant Shutters project?

Identify Christlike attributes

Disciples of Jesus Christ

As a team, discuss the following:

  1. Are there any people or actions in this case study that exemplify the way the Savior would act in that circumstance?
    • If so, do you think acting this way was difficult for that person?
  2. Are there any people in this case study that behave contrary to the teachings of the Savior?
    • If so, how could that person have achieved their overall goal in a different way?

Dig a little deeper

Answer the following questions:

  1. What kind of testing is occurring and who bears responsibility for it?
    2. After you have answered the question, expand this box.

    The following are some of the types of testing shown in the case:

    • Unit testing (Jessie): Despite agreeing to forego much of the unit testing, Jessie is still trying to do it for the most critical parts of the system and hoping to achieve at least 60% code coverage.
    • User Acceptance Testing (Brice): Brice has agreed to own user acceptance testing.
    • System Testing (Brice):While not explicitly stated, in Brice's description of UAT, he talks about concepts that may fall under a system testing umbrella, such as verifying some use cases with a tape measure.
    • Code Reviews (Brightside Engineers): While not specifically a type of testing, Brightside has increase the prominence of code reviews which can help them find and fix errors in the code.
  2. What are some potential risks that could be uncovered through more thorough testing?
    3. After you have answered the question, expand this box.

    Some of the risks that could be uncovered include:

    • Jessie is most concerned about issues in the calculations, and certainly some of those could be exposed. The major risk here is producing bad products.
    • Performance issues could arise from lots of users at the same moment or issues resulting to having much more data. Jessie mentioned the load time issues of the dashboard, which would likely be increased with more data in the system. The risk here is that the system may not be able to keep up with the load under live conditions.
    • Security issues are not mentioned at all in the case study, but they could certainly be lurking in this system. Among other issues, someone could potentially bring down the whole system and prevent Radiant Shutters from doing work, they could access sensitive customer information, or they could even submit faulty information causing the company to produce erroneous products.
    • There are many more kinds of bugs and risks that your group may have identified.

Analyze the case

Answer the following questions:

  1. Given that testing cannot remove the existence of all bugs, where do you draw the line at what is necessary for this project? What are the appropriate testing activities that you would like to see before you feel comfortable shipping?
    2. After you have answered the question, expand this box.

    The following are some activities that you might want to see performed.

    • Complete code coverage for all calculations components.
    • Detailed UAT following specific scripts that align with requirements.
    • Testing beyond the calculations components to ensure the rest of the system is functioning correctly.
    • Some basic automated integration tests, especially to help with regression bugs in the future.
    • At least some limited performance tests to verify that the dashboard and other high computation components can work reliably under likely load scenarios.
  2. They are in a situation where they are not doing as much testing as Jessie felt they probably should. Who carries the most responsibility for this decision? Given the circumstances of this case, do you think they made an appropriate decision? Why or why not.
    3. After you have answered the question, expand this box.

    It's tempting to say that Brice is responsible for the move away from unit testing. While Brice suggested it, because he is not a software engineer, he doesn't really understand the kinds of testing that should be done in a system and the role of that testing in quality assurance. In that regard, as the software engineer on the team, Jessie is most responsible for the decision.

    It is difficult to say what is appropriate in this case, but it does seem that Jessie could have pushed for some level of more rigorous testing. At a minimum, Jessie could have insisted on some level of unit and integration testing in core components, even if they didn't get to 100% code coverage. Likewise, Brice may not have been aware of some areas of testing such as performance or security testing that Jessie might have highlighted. In the end, it seems like Jessie could have pushed a little harder for more rigorous testing.

Conclude

As you finish your meeting, select a person to be the lead student for your next meeting.

Submission

Other Links: