Scrum Quality Assurance

            Given that we are working in a Scrum team in our Software Development capstone and that we got ample practice with the Scrum in our Software Project Management course, I thought it would be interesting to see the crossover between quality assurance and the Scrum workflow. Scrum is also widely used, so this should be important to know for the future as well. I found this article: https://medium.com/serious-scrum/how-does-qa-fit-with-scrum-4a92f86bec5b which talks about the role of quality assurance on a Scrum team.

            It’s important to remember that the members of a development team do not have pre-defined roles. It’s assumed each member of the team can collaborate with any part of a project, even if certain members have more specialization in certain areas, like product testing in this case. With that in mind, it makes the Definition of Done all the more important. Requirements for testing should be documented and understood by the development team and the product owner. This prevents conflicts during the sprint review if the development team thinks something like compatibility testing needs more work and the product owner is ready to deploy. If there is a more comprehensive Definition of Done, these conflicts are avoided since they would have been discussed ahead of time.

            Quality assurance on a Scrum team is a large part of the process and requirements are developed during sprint planning. It’s important that there is close collaboration during the sprint between the development team and the product owner though, even though the development team is delegated most of the decision-making responsibility for how work will be completed. This keeps the whole team in tune and avoids conflict. It also provides for a closer, more efficient work environment as understanding is enhanced throughout the team and the owner.

From the blog CS@Worcester – Marcos Felipe's CS Blog by mfelipe98 and used with permission of the author. All other rights reserved by the author.

Sprint 1: Retrospective

If anything can be said about this sprint, it is that a lot was learned throughout. I was familiar with how the teams would work, but many of the day-to-day specifics and exact deliverables were a bit unclear to me. Before this class I had only really examined this sort of team structure in CS-348, and that more theoretical practice left me in the dark on some of the specific aspects. To specify, the issue board for our team was not utilized to its full potential in a few different ways. However despite these issues we were able to complete all issues on the board. First I will discuss exactly what worked well, and subsequently what did not.

Regardless of what could have been improved, which will be discussed, this was overall a successful sprint. Each team member did, at the minimum, read through the material they were assigned and documented any relevant information in the wiki. So by definition this was a successful sprint, but it’s true value for us was what we learned for the next sprint in my opinion. One part that could have been worked on were the actual issues themselves. These could have been streamlined a bit, as we simply decided to read through all of the documentation because it was the most logical thing to do. However the documentation often contained much superfluous information that may not really end up  being useful. It felt as though this was mostly being done to meet our SCRUM goals. Besides this, it was still difficult to communicate all of this information with each other. Throughout the sprint we also forgot to move issues through the board as we worked on them, and I personally did extraneous work that could have qualified as a new issue but did not think to create one for them. After all of these issues however, there are some changes that can be made for this next sprint.

This first sprint was an extremely valuable learning experience as previously stated. There are a few ways that our community of practice could improve the effectiveness of our teamwork. One idea that was brought up was to simply communicate more often using the community of practice channels. This will allow us to simply have one location containing all information we may need, and allow us to be on a similar page with each other. To further improve this, we also discussed having small work sessions in the community of practice from time to time to ensure none in the group are behind. This would also allow us to have more consistency in the method that we use to connect our respective systems to Keycloak further down the line. As for myself personally, my major flaw was simply getting behind on my work. If I am being honest, I had to do much more reading towards the end of the sprint than should have been necessary. To improve on this, I have set aside specific time frames during the week to work on projects. I will also try to share any more useful information in the project-wide community of practice, as I have a tendency to just share information in my team’s text channel only. I am excited to put all of the changes into play for this next sprint!

From the blog CS@Worcester – My Bizarre Coding Adventures by Michael Mendes and used with permission of the author. All other rights reserved by the author.

Software Testing Life Cycle

            I was interested in learning more about how software testing works in the professional world on a software development team. Since we are learning about the crafting of software tests in our class, I thought it would be interesting to learn how the pieces are put together, like how developing requirements goes into crafting tests and then executing them. It’s an essential part of a software development team, of course, and I’m sure I’ll be doing plenty of it in my future. I found this resource: https://www.tutorialspoint.com/stlc/stlc_overview.htm from Tutorials Point that gave an overview of the “Software Testing Life Cycle” (STLC) which help put the pieces together for me.

            First, what is the STLC? It deals strictly with testing and “starts as soon as requirements are defined… by stakeholders.” Sidenote, this reminds me of test-driven development, which, by my understanding, is a common practice in software development these days. The STLC consists of 7 parts. The first is requirement analysis, at which point the team analyzes the application under test (AUT) at a high level. Then comes test planning where a strategy for testing is devised. Then is test case designing which is applying the requirements and making tests according to the planning. Then is the test environment setup for integrated testing. This is the last step before actual testing. Next is test execution which yields defect reporting. This either validates tests or finds bugs. Last is test closure, where testing is finished and matrix, reports, and results are completed.

            This was great to see the pieces come together. This very basic overview helps me see what working on software testing in the professional world would be like. Seeing a timeline also provides context for some of the things we’ve been learning in class.

From the blog CS@Worcester – Marcos Felipe's CS Blog by mfelipe98 and used with permission of the author. All other rights reserved by the author.

Boundary Value Analysis and Equivalence Partitioning Testing

When it comes to a large pool of input data, it is not possible to perform exhausting testing for each set of test data. There should be an easy way to select test cases from the pool so that all scenarios are covered. This is when the Equivalence Partitioning & Boundary Value Analysis testing techniques were introduced. In today’s blog, I want to do further research on the testing technique of Boundary Value Analysis and Equivalence Partitioning Testing. Equivalence Partitioning and Boundary value analysis are linked to each other and can be used together at all levels of software testing. To start, Boundary value testing is the process of testing between extreme boundaries between the partitions, for example like start, end, lower, upper, maximum, minimum, just inside, and outside values. Normally Boundary value analysis is part of stress and negative testing. Using the Boundary Value Analysis technique tester creates test cases for the required input field.

Now when it comes to equivalence partitioning or equivalence class testing is a type of black box testing technique in which the input data units are divided into equivalent partitions that can be used to derive test cases. This helps with reducing the time required for testing a small number of test cases. This technique can be applied to all levels of software testing like system, unit, and integration. One of the examples that were widely used in many resources that I have look at is: let us say a password field accepts a minimum of 6 characters and a maximum of 10 characters, that means results for values in partitions 0-5, 6-10, 11-14 should be equivalent.  The three testing scenarios will be:

1       Enter 0 to 5 characters         System should not accept

2       Enter 6 to 10 characters       System should accept

3       Enter 11-to-14-character      System should not accept.

Equally, Both testing techniques are used to reduce a very large number of test cases to a manageable piece, Both are appropriate for calculating intensive applications with such a large number of variables and input data.

https://www.guru99.com/equivalence-partitioning-boundary-value-analysis.html

https://www.softwaretestingclass.com/boundary-value-analysis-and-equivalence-class-partitioning-with-simple-example/

From the blog Derin's CS Journey by and used with permission of the author. All other rights reserved by the author.

Find Mentors

            The “Find Mentors” learning pattern from the Apprenticeship Patterns book is one that I definitely should have focused on earlier. This pattern is focused on find more experienced developers around you early and leveraging their knowledge and practice to take steps forward in your apprenticeship. Keeping with the master craftsman and apprentice theme, no apprentice will learn as effectively without someone to help them along their way and point out the unknown unknowns. The pattern recommends reaching out early and often. The only downside is rejection, which is easy to get over, especially if it is followed by acceptance at some point.

            In my computer science journey, I need to take this message to heart. Oftentimes, I try to do most of my learning on my own. I know I can have a kind of unorthodox way of teaching myself things, so I usually try to stick to myself when learning. I do quite often leverage the help/advice of peers though. Most of the people I’ve become closer with in the WSU computer science program I have worked closely with and either have some knowledge to gain from them or have some to share. While I realize working with peers is great, I definitely have fallen short on the front of getting help from those who are leagues ahead of me, like my professors. Looking back, I definitely should have attended more office hours and been in closer contact with my professors and advisors. That’s a goal I have for grad school, especially since I hope to be working as a research assistant, so this would be perfect.

            As the pattern mentions, it is difficult to get over the awkwardness of asking someone to mentor you. I’m not really sure how or who to reach out to in a professional setting, and I’m also not sure of what I would be looking for from a mentor. Although mentoring in school is great, it would probably be quite different than mentoring in a workplace. This is something I should look further into. Who can I reach out to as a mentor and what should I be looking to gain from them? If I can get the answers to questions like these, I think I would feel more comfortable filling the apprentice role.

From the blog CS@Worcester – Marcos Felipe's CS Blog by mfelipe98 and used with permission of the author. All other rights reserved by the author.

The Power of Decision Table Testing

In POGIL activity 8, we worked with decision table-based testing and applied it to applied this concept to the ongoing graduation problem. Unlike the previous activities, we did not go over the advantages of using a decision table opposed to using any of the other testing frameworks. So for this blog post, I want to look more at the pros of using decision table-based testing.

In this article, it gives a complete step-by-step rundown of what is a decision table, why we use it for testing and how to conduct decision table-based tests.

A guide to Using Decision Tables

It is basically a review of what we covered in class with pictures/diagrams at each step.

In this second article, it talks about the characteristics of decision tables and why some of these characteristics may make decision table-based testing more preferable to the other testing frameworks.

https://www.edureka.co/blog/decision-table-in-software-testing/#advantages

Decision table-based testing is similar to Equivalence Class testing in the sense that it divides the tests into cases and complete test coverage. Unlike Equivalence Class testing, decision tables are more versatile. One aspect that I really liked about this second article was the fact the author completed multiple action rows into just one rule by defining a key. This made the table smaller and easier to read while not obscuring the meaning within the table.

From the blog CS@Worcester – Just a Guy Passing By by Eric Nguyen and used with permission of the author. All other rights reserved by the author.

The Long Road – Apprenticeship Pattern

What this apprenticeship patter talks about is that this journey of a software developer and that of a software craftsmen is all about the long- term. You have to have the long-term mindset and vision to always be learning and realize that you will never be done. People now a days are looking for ways to quickly do everything and have the ability to do something overnight. Well, when it comes to software development and the journey that needs to be followed, this won’t be realistic. In order to build the skill of the best software developer, you need to realize that this will take time and years of practice and learning. I think this is a good mindset to have in order to not give up and keep on pushing yourself when times get tough. One thing that I have seen over the years with coding is that when people start to have a tough time with it and can’t seem to figure something out, they give up and self-declare that programming isn’t for them. They didn’t even realize that with just a little bit more effort and time they would have figured and become better coders, while also increasing their confidence. This shows to me that no matter what adversity you face, that you need to keep on going and not give up at a time where you need to put in the most effort. Once you past that barrier, the road just starts to get a little bit easier and you will become more capable of dealing with problems, that just a while back you thought was impossible.

Taking the long road is a key in the software world and is also a key in our everyday life. I’m sure there were times when we did not want to do something and thought of something as hard, but looking back at it seems silly to us. This is why when you keep a long-term vision, the issues that come in the present time won’t seem so big because you know at the end it will all be worth it. The software craftsman is striving to keep on improving and learning because they know it will all be worth it and the journey will be a great one. Overall, the message is to keep on striving to learn and build up skills and work hard to break through barriers by not giving up.

From the blog CS@Worcester – Roller Coaster Coding Journey by fbaig34 and used with permission of the author. All other rights reserved by the author.

Concrete Skills

This week I chose to look at the “Concrete Skills” pattern. This pattern explains that you need concrete skills to be able to get a job and contribute to the team you are joining. Concrete skills mean discrete abilities you can demonstrate using specific technologies. Something like understanding and being able to apply a certain framework or being able to write docker compose files. Things beyond soft skills like being able to learn quickly and having a good attitude. Creating a toy project can help show your concrete skills to employers and comparing your CV to the CVs of people whose skills you respect can help you take stock of where your own abilities stand.

I found this pattern interesting because it is a very helpful thing to think about when writing a resume or CV. Especially in a technical field like software development, you need to have very specific skills to be able to do the job you are hired for. Thinking about what concrete skills you have and making those specifics clear can really help you when looking for a job and it is definitely something I will be thinking about as I enter the workforce.

I also found it interesting when the author wrote about “buzzword bingo”. If you do a quick search for software development jobs, you do see a lot of these buzzwords and that can sometimes be really intimidating. Having ultra-high standards for software developers in kind of a meme now too (10+ years of experience in Swift required!!!). Making a list of these concrete skills helps make that a little less intimidating as you realize how capable you really are. That or it can help you see how far you need to go. Taking stock of your abilities is a good thing.

I know I am lacking a bit in the concrete skill area. A lot of the work we are doing with the project this semester will help fix that deficiency. We are working with so many new tools and I feel like I am learning more about software development than ever before. Putting myself in the uncomfortable position of creating something complex using brand new languages and technologies is pushing me towards becoming a better programmer.

From the blog CS@Worcester – Half-Cooked Coding by alexmle1999 and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns Blog – Nurture Your Passion

For this week’s blog post, I read the section  “Nurture Your Passion ” from chapter two of the book Apprenticeship Patterns by Dave Hoover and Adewale Oshineye. The section talked about how the work environment can stifle the passion for the craft. For example, you might be a software developer with a passion for the craft, but unfortunately the daily activities, “demoralizing corporate hierarchies, project death marches, abusive managers, or cynical colleagues.” Can become hard for your passion to grow by staying in such hostile conditions. I think this is true for the majority of the people that work in the IT field. I have seen especially my family members whose having such a hostile situation at work especially when there is a deadline that is approaching, or a software release is going on.

The author goes further into project death marches in which he explained how they are the most damaging of the hostile situations, it takes your time and energy, preventing you from taking any significant actions to protect your passion as more important issues like physical and mental health can take a toll. Now that I think about it, work pressure and stress can significantly affect one’s mental health.  I think it is important for people to take a break from sometimes and focus on something else for a little time. Identify what u like, find something at work that interests you and you enjoy doing. I liked the solution that was given to this problem which was: to grow your passion, set clear boundaries that define the sort of environment you are willing to work in. I think that creating some sort of boundaries helps and necessary to have a free hostile environment. One of the statements I do not agree with the author is how walking out of a meeting or refuse to distribute code that doesn’t meet your minimum standards will help your passion however this type of behavior can cause a conflict between your colleagues or your boss. I think the best solution if you want to follow your passion is just to do it, nurture your passion or find a job that suits well for your passion.   

From the blog Derin's CS Journey by and used with permission of the author. All other rights reserved by the author.

Boundary Value Testing and Equivalence Class Testing

Due to their being a large capacity of data that is used for software, there needs to be test implementation that can test the range of values without testing each number. Therefore, we used testing methods such as boundary value testing and equivalence class testing. The purpose of boundary value testing is to test the extreme ends or also known boundaries hence the name. The most common way to implement this test case is to use input variable values such as a minimum value, a value just higher than minimum, a middle value none as the nominal, a value that is just lower than the maximum and the last is the maximum value. One common example that most have seen is when we have to set up a password. Let’s say that a valid number length for the password has to be between 10 and 15. Using this guide, our boundary value testing would consider values that are less than, ones that are 10, ones that are between 10 and 15, ones that are 12 and ones that are greater than 15. Now the valid inputs will be passwords that are between 10 and 15 and so boundary value testing implementations are a good way to test any input errors that are more near the boundaries of valid numbers.

Equivalence class testing is a method of testing that divides the input of the data into various different equivalence classes. This step is the partitioning of the values that need to be tested and is the step that comes before boundary testing. The accurate values that are considered acceptable inputs are divided into a certain range, and the values under as well as over are considered invalid or unacceptable to the software. The valid class partition keeps all the valid values or inputs in it and the invalid class partition contains the invalid values and partition. The example is same as the password one and how the password that in the acceptable range of 10 to 15 will be accepted and valid, whereas passwords that are less than 10 or more than 15 will be invalid and won’t be accepted. Overall, boundary and equivalence class testing are good testing implementations to test input values without having to try to test all the individual values.

Resources:

Boundary Value Analysis and Equivalence Class Partitioning With Simple Example

https://www.guru99.com/equivalence-partitioning-boundary-value-analysis.html

From the blog CS@Worcester – Roller Coaster Coding Journey by fbaig34 and used with permission of the author. All other rights reserved by the author.