Performance Testing

For this week’s blog, I decided to research a bit on performance testing because it is listed as a topic for a class. While doing research, I found a blog called “How To Do Performance Testing: Tips And Best Practices” by Volodymyr Klymenko. In this blog, he discusses the primary purpose of this kind of software testing, types of performance testing, its role in software development, common problems revealed by performance testing, tools, steps, best practices, and common mistakes to avoid. The blog was well organized and clearly simplified each topic.

The purpose of performance testing is to find potential performance bottle necks to identify possible errors and failures. This is to ensure that the software meets the performance requirements before it is released. Some types are load testing(response under many simultaneous requests), stress testing ( response under extreme load conditions or resource constraints), spike testing (response under a significant and rapid increase in workload that exceeds normal expectations), soak testing(simulates a gradual increase in end users over time to test the system’s long-term stability), scalability testing(how the system scales when the volume of data or users increases), capacity testing (which tests the traffic load based on the number of users but differs in scope) and volume testing(which tests the response to processing a large amount of data).

The next section discusses the role of performance testing. I found some of the bullet points to be a bit obvious like “improving the system’s overall functioning”, “monitoring stability and performance”, and “assessing system scalability”. The other points mentioned were “failure recovery testing”, ”architectural impact assessment”, “resource usage assessment” and “code monitoring and profiling”.

After discussing the role of performance testing, the author discussed the common issues revealed by performance testing. The problems discussed were speed problems, poor scalability, software configuration problems, and insufficient hardware resources. This section is broken down into many bullet points to explain each issue. I found it to be very beneficial in simplifying the ideas presented.

The last three sections are the steps for performance testing, best practices, and common mistakes to avoid. The steps presented in this article for performance testing were: 1.Defining the Test Environment, 2.Determination of Performance Indicators , 3. Planning and Designing Performance Tests , 4. Setting up the Test Environment, 5. Development of Test Scenarios, 6. Conducting Performance Tests , and 7. Analyze, Report and Retest. The section after explaining the steps includes some best practices like “Early Testing And Regular Inspections “ and “Testing Of Individual Blocks Or Modules”. Some of the common mistakes to avoid that I found to be noteworthy were “Absence of Quality Control System” and “Lack of a Troubleshooting Plan”. While working on the Hack.Diversity Tech.Dive project, I had to do some performance testing and even used a tool that was mentioned in the article called Postman. In the future, I will definitely be more prepared to do performance testing now that I can reference this article.

The Long Road

For this week’s blog, I decided to write about the pattern called “The Long Road” from Chapter 3. My previous blogs touched a bit on the contents of this pattern so I decided to discuss what the authors suggest for this pattern. In this pattern, the situation that is presented relates to how your aspirations to become a master software developer conflict with the expectations of others and how “Conventional wisdom tells you to take the highest-paying job and the first promotion you can get your hands on, to stop programming and get onto more important work rather than slowly building up your skills”. 

The solution that is presented is to first accept the judgments you may receive from others to go against the status quo and then to stay focused on the long term. During the journey you will gain quite a bit of skills and knowledge; it is a long one so you need to prepare for it by drawing your own map. The text mentions “ you should keep in mind the expectation that you will be a working software developer even when you are middle-aged. Let this influence the jobs you take and the scope of your ambitions. If you’re still going to be working in 20 years’ time, then you can do anything”. You will be able to catch up to anyone in terms of skills in the decades that you will work and you may just pass them. Before reading this pattern I never really thought about just how long I will be working in the field. As I have discussed in many of my blogs for this class, I have been working on developing myself professionally and learning from other developers; as I have progressed, I have thought about the possibility of not being the weakest on the team so I agree that it is realistic to surpass people during your long journey.

The pattern really stresses the idea that instead of counting the days to retirement, a craftsman will willingly work until their final decades. You should thoughtfully work on developing your craft over many years. The idea of taking the long road is the foundation for a successful apprenticeship along with self-assessment. I couldn’t find anything in this section that I could disagree with. It definitely made me think of what I want to get out of this long journey because I didn’t take the time to think about it in-depth before.

Sprint Retrospective #2

Overall I think the second sprint went well. Like the last sprint, I think we all did a good job of keeping each other updated and asking each other questions if we became stuck. For this sprint, we worked on a lot of the issues as a group. We also were open enough to communicate with each other when we realized that issues may not have been merged for a long period after being reviewed. Unfortunately, there were a couple of times when we didn’t keep up with issues that were in the “Needs Review” column. This resulted in a lot of merge conflicts that need to be resolved for those issues. We continued to display aspects of the original description of the culture we wanted in the working agreement: open-mindedness, honesty, respect, and accountability. We decided how much weight everyone should try to complete to divide the work evenly and fairly before the sprint started and we kept to it for the most part.

I worked on multiple issues that involved verifying that the pantry projects had the correct extensions, linters, and pipeline stages. For this issue, we examined the file types on the project, made a list of linters that were needed based on the files, added any linters, made sure the new linters passed, checked which stages were needed, and fixed the stages accordingly. I worked on verification for GuestInfoBackend, GuestInfoAPI, and GuestInfoSystem/General. I worked on the first two issues with the group and worked on verifying GuestInfoSystem/General by myself. We also had an issue for talking to group 3 about InventoryFrontend and InventoryBackend because they decided to work on some issues for it. Towards the end of the sprint, I realized they didn’t reach out so our group initiated a conversation to confirm if they were all set. Once that conversation finished I moved that issue to the done column. I also worked on reviewing the issue for getting InventoryBackend test working and getting the InventorySystem General test and build working. The issue for getting the InventoryBackend working was an issue that was left in the  “Needs Review” column for an extended amount of time and needed an extensive amount of work to resolve merge conflicts.

As a team, I think we did fairly well but we needed to keep up with the issues that need review more. We also did not rotate reviewing issues as we originally planned when creating our working agreement and or set up a system that will ensure that there aren’t certain people who are reviewing the majority of issues. Because a lot of the issues involved us working together, we didn’t address how we would make sure to stay on track of issues that needed review. As an individual, I need to make sure I can review issues as soon as possible to prevent the possibility of having a team member work through multiple merge conflicts. I think as a group we could benefit from a specific plan for keeping up with completed issues. For the next sprint, I plan on picking a schedule to check on the needs review column.