Week 6 CST438
Write a weekly entry describing important things you learned this week.
One of the concepts that caught my attention this week was from the lecture videos and slides discussing Quality Assurance and the procedure steps provided. The reason why is that I am currently in the middle of a QA mentorship that utilizes the procedure almost one to one. I can't count how many times I've had to use the five R's from the procedure, and the most noteworthy one that I have been utilizing most often is regression testing. For my workflow, I've had to download previous versions of the code through different binaries and manually test each one from the newest to oldest in order to find where the difference or bug first came into contact or began. Then I would have to report to the person who initially might have caused the problem and warned them about potential mishaps in their code. That's something I've noticed being discussed within the lecture which was the "blame" portion of quality assurance. Before I didn't mind it too much about blaming people, but now I'm learning that the blame could possibly be providing assistance and enhancing the developer's training. For my work the software actually requires manual testing since it is an equivalent to an office suite so in most cases creating automation tests wouldn't suffice much. Although I do have to sometimes create automation for menial crash tests. The difference in the procedure given in the lecture is that we have to "add a new test that reproduces the problem into the test suite so that future changes will not reintroduce the same error". That's something new to me since my workflow was mostly finding the regression and reporting it to the developer. It's good to know now that if I was developing I would need to follow this process of creating tests that reproduces the problem so it won't be introduced again.
From the book the most notable thing I have learned this week was Google's adaptation to scaling from manual deployment methods like SSHing into dozens of machines to the evolution of automated scheduling and containerization. Something that had stood out to me was the concept of "cattle, not pets" mindset because of the bizarre phrasing of it. The book discusses this mindset as systems that should be designed to be replaced and automatically handled without human intervention. Another important concept I learned was the distinction between virtual machines and containers. Recently there has been a surge in industry requirements for jobs that require individuals to know how to use Docker and Kubernetes. According to the book VMs provide strong isolation but come at a price with heavy overhead, slow startup, and large resource footprints. Containers on the other hand, are light weight and designed to be fast making them ideal for large distributed systems. Lastly, the idea of serverless architecture where engineers focus solely on writing handlers while providers manage the execution environment was quite an interesting topic. Something that was fascinating was the pros and cons like requiring code to be truly stateless or even the idea of losing control over your environment. The book had mentioned that Google utilizes a non pure server-less stack for its operations. As always there are trade-offs that Google has utilized in their system designs. Overall, this week helped me understand QA practices much more than I have already had, and explored the modern compute infrastructure as a whole at Google. I feel a bit more confident connecting these concepts to industry trends I have seen in job applications, although I would say I need to dive a bit more in depth to these concepts.
One of the concepts that caught my attention this week was from the lecture videos and slides discussing Quality Assurance and the procedure steps provided. The reason why is that I am currently in the middle of a QA mentorship that utilizes the procedure almost one to one. I can't count how many times I've had to use the five R's from the procedure, and the most noteworthy one that I have been utilizing most often is regression testing. For my workflow, I've had to download previous versions of the code through different binaries and manually test each one from the newest to oldest in order to find where the difference or bug first came into contact or began. Then I would have to report to the person who initially might have caused the problem and warned them about potential mishaps in their code. That's something I've noticed being discussed within the lecture which was the "blame" portion of quality assurance. Before I didn't mind it too much about blaming people, but now I'm learning that the blame could possibly be providing assistance and enhancing the developer's training. For my work the software actually requires manual testing since it is an equivalent to an office suite so in most cases creating automation tests wouldn't suffice much. Although I do have to sometimes create automation for menial crash tests. The difference in the procedure given in the lecture is that we have to "add a new test that reproduces the problem into the test suite so that future changes will not reintroduce the same error". That's something new to me since my workflow was mostly finding the regression and reporting it to the developer. It's good to know now that if I was developing I would need to follow this process of creating tests that reproduces the problem so it won't be introduced again.
From the book the most notable thing I have learned this week was Google's adaptation to scaling from manual deployment methods like SSHing into dozens of machines to the evolution of automated scheduling and containerization. Something that had stood out to me was the concept of "cattle, not pets" mindset because of the bizarre phrasing of it. The book discusses this mindset as systems that should be designed to be replaced and automatically handled without human intervention. Another important concept I learned was the distinction between virtual machines and containers. Recently there has been a surge in industry requirements for jobs that require individuals to know how to use Docker and Kubernetes. According to the book VMs provide strong isolation but come at a price with heavy overhead, slow startup, and large resource footprints. Containers on the other hand, are light weight and designed to be fast making them ideal for large distributed systems. Lastly, the idea of serverless architecture where engineers focus solely on writing handlers while providers manage the execution environment was quite an interesting topic. Something that was fascinating was the pros and cons like requiring code to be truly stateless or even the idea of losing control over your environment. The book had mentioned that Google utilizes a non pure server-less stack for its operations. As always there are trade-offs that Google has utilized in their system designs. Overall, this week helped me understand QA practices much more than I have already had, and explored the modern compute infrastructure as a whole at Google. I feel a bit more confident connecting these concepts to industry trends I have seen in job applications, although I would say I need to dive a bit more in depth to these concepts.
Comments
Post a Comment