Author Archives: mrjfatal

Levels of Testing

What is Software Testing?

Software testing is the process of evaluating whether a program or application functions as intended. It serves as a form of quality control, aimed at identifying and rectifying any discrepancies or errors before production use. For instance, in the scenario of a budget-tracking app, testers would verify the accuracy of data input, functionality of buttons, and ease of navigation, among other aspects, to ensure a seamless user experience.

Levels of Testing

Testing levels, also referred to as levels of testing, encompass distinct phases or stages of assessing software throughout its development cycle. These levels target specific aspects of functionality, contributing to enhanced quality assurance and reduced defects. The primary testing levels include:

  1. Unit Testing: This level involves testing individual components, such as methods and functions, in isolation to ensure their correctness and functionality. Automated unit testing is often recommended, allowing for efficient evaluation of code behavior. Unit testing is crucial for identifying bugs at an early stage of development, as it allows developers to test each component independently. By writing automated tests that cover various scenarios, developers can ensure that their code performs as expected.
  2. Integration Testing: Integration testing assesses the interaction and integration between various units or modules within the software. It aims to detect any issues arising from coding errors or integration conflicts, facilitating seamless collaboration between components.During integration testing, developers test how different modules work together to ensure that they function properly as a whole. This ensures that any errors or inconsistencies between modules are detected and addressed before moving to the next stage of development.
  3. System Testing: System testing evaluates the integrated system as a whole, verifying its compliance with specified business requirements. Automation tools can be leveraged to streamline system testing processes, ensuring comprehensive assessment of functional and non-functional aspects.System testing focuses on evaluating the entire software system against the defined requirements and specifications. It includes testing functionalities, performance, security, and compatibility to ensure that the software meets the desired standards.
  4. Acceptance Testing: Acceptance testing focuses on validating the system’s functionality and performance against user-defined criteria. It encompasses aspects such as usability, security, compatibility, and reliability, either through manual evaluation or automation tools.Acceptance testing involves end-users or stakeholders testing the software to ensure that it meets their expectations and requirements. This stage ensures that the software is ready for deployment and use in a real-world environment.

Software Testing Sequence

A structured testing sequence is essential for thorough evaluation of software functionality. This sequence comprises four main stages:

  1. Unit Testing: Testing individual components to ensure functionality.
  2. Integration Testing: Evaluating interactions between integrated units.
  3. System Testing: Assessing the integrated system as a whole.
  4. Acceptance Testing: Validating the system against user-defined criteria.

Conclusion

Software testing is a critical process in the software development lifecycle. It serves as a safeguard against defects and ensures that software meets user expectations and business requirements. Skipping or neglecting testing can have detrimental consequences, undermining the utility and effectiveness of the software.

From the blog CS@Worcester – CS: Start to Finish by mrjfatal and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern: White Belt

Summary of the Pattern:

The “White Belt” pattern emphasizes the importance of approaching new learning experiences with a beginner’s mind, regardless of your level of expertise. It suggests setting aside previous knowledge and preconceptions to fully absorb new information. Drawing analogies from various fields like family therapy and programming, the pattern illustrates the benefits of adopting a mindset of not knowing. By embracing ignorance and being open to making mistakes, individuals can accelerate their learning and gain deeper insights.

Reaction:

As someone who takes pride in my skills, it’s easy to fall into the trap of believing I already know the best way to approach a problem. However, the “White Belt” pattern reminds me that there’s always more to learn and different perspectives to consider.

What to Do:

The pattern suggests practical steps to implement its principles. For example, it recommends trying to implement a program in a language with a different paradigm, or learning from someone in a different technological community to understand their perspectives. These actions challenge one’s comfort zone and encourage embracing new ways of thinking.

What I Found Thought-Provoking:

The analogy of wearing a white belt, signifying a beginner’s level, is powerful. It reminds me that true mastery comes from a willingness to continuously learn and adapt. Additionally, the idea of consciously unlearning and relearning is intriguing. It requires humility and courage but promises significant growth.

Changes in Thinking:

This pattern has reminded me in the importance of continuous learning and humility in any area of life. I aim to approach new challenges with a more open mind, ready to embrace the discomfort of being a beginner again. Instead of seeing setbacks as failures, I now view them as opportunities for growth.

Disagreements:

While I don’t disagree with the core principles of the pattern, I recognize that fully embracing a beginner’s mindset can be challenging, especially in environments that value expertise and efficiency. However, I do see a view of balance on where it can be useful to listen to new ideas/appreaches while incoperating past ideas. As I do not think the White Belt pattern suggest to blondly accept any and all new information without any rebuttals or input.

In conclusion, the “White Belt” pattern serves as a powerful reminder to approach learning with humility and openness. By unlearning and relearning, we can break through plateaus and continue our journey toward mastery.

From the blog CS@Worcester – CS: Start to Finish by mrjfatal and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective

Introduction

As we conclude Sprint 2, it’s essential to take stock of our journey, examining both our successes and the challenges we’ve encountered along the way. This sprint, our primary focus was on scaling up productivity and initiating the UI development process. Despite its longer duration compared to the previous sprint, Sprint 2 felt back-heavy due to delays in commencing frontend work until we obtained access to the new template.

Challenges Faced and Lessons Learned

Both sprints presented us with unique challenges, contributing to our team’s growth and development. One significant challenge in Sprint 2 was the unexpected complexity encountered while coding a UI component. Initially deemed a simple task, unforeseen changes in the source code necessitated extensive adjustments, resulting in delays and frustration. However, this challenge provided valuable lessons in flexibility and adaptability. By grappling with the intricacies of the component and adapting to evolving requirements, we honed our problem-solving skills and gained a deeper understanding of UI development.

Another challenge stemmed from the weight of certain child issues, which had a more substantial impact on our workflow than initially anticipated. This highlighted the importance of thorough planning and assessment when breaking down tasks and allocating resources. Moving forward, we recognize the need for a more nuanced approach to issue prioritization to ensure each task receives the appropriate attention and resources.

Team Dynamics and Communication

Effective communication emerged as a cornerstone of our approach throughout both sprints. We found that tackling problems collectively as a group significantly eased the resolution process. Whether through online discussions or face-to-face meetings, open dialogue and transparent communication channels were maintained, ensuring alignment and informed decision-making. We intend to prioritize effective communication, proactive problem-solving, and meticulous planning in future endeavors.

Strategies for Improvement

Team Improvement

  1. Keep a consistent schedule: In hopes of avoiding a repeat of the last sprint where everything was stacked at the back of the sprint, it would be beneficial to manage our time better as a group with a more consistent meeting time.
  2. Division of Labor: We continue to ensure that one person does not get stacked with too much to do while others get left with little to work on.

Personal Improvement

  1. Frequent Check-Ins: In realizing the significance of team alignment, I commit to checking in more frequently with my team members. By maintaining regular communication and seeking feedback, I aim to ensure that our efforts remain aligned towards our common objectives throughout each sprint.

Moving Forward

As we look ahead, we are committed to leveraging the lessons learned from Sprint 2 to inform our approach in subsequent iterations. Documenting challenges, solutions, and key takeaways in a “lessons learned” repository will serve as a valuable resource for future sprints, enabling us to anticipate and mitigate potential obstacles more effectively. With a shared commitment to continuous improvement and a supportive team environment, we are confident in our ability to overcome challenges and achieve our goals collectively.

Links to Activity on GitLab

From the blog CS@Worcester – CS: Start to Finish by mrjfatal and used with permission of the author. All other rights reserved by the author.

Intro to Software Testing

Software testing != doing homework bt rather, Software testing == checking homework to make sure it’s done right. In this blog we’ll explore the basics: what testing is, how it’s done, and why it’s important. We’ll cover different ways to test, how deep we go into testing, some smart ways to test, and why testing is worth it. Let’s dive in!

What is Software Testing?

Software testing is the process of verifying and validating whether a software or application is bug-free, meets technical requirements, and satisfies user needs. It ensures that the software functions as expected, identifying errors, faults, or missing requirements in contrast to actual specifications. This process aims to enhance efficiency, accuracy, and usability.

Verification and Validation

  1. Verification: Ensures that the software correctly implements specific functions, answering the question, “Are we building the product right?”
  2. Validation: Confirms that the built software aligns with customer requirements, answering the question, “Are we building the right product?”

Different Types of Software Testing

  1. Functional Testing: Validates whether the software functions according to functional requirements.
  2. Non-functional Testing: Assesses non-functional aspects like performance, scalability, and usability.
  3. Maintenance Testing: Involves modifying and updating software to meet evolving customer needs.

Further, testing can be performed manually or through automation, each with its own set of advantages and applications.

Different Types of Software Testing Techniques

  1. Black Box Testing: Conducted without accessing the source code, focusing on software interface.
  2. White Box Testing: Involves knowledge of internal workings and access to source code.
  3. Grey Box Testing: Blends aspects of both black and white box testing, providing testers with partial knowledge of the internal workings. This approach offers a balanced perspective, allowing for effective testing while maintaining a degree of independence from the code’s intricacies.

Additionally, Grey Box Testing combines elements of both approaches.

Different Levels of Software Testing

  1. Unit Testing: Evaluates individual units or components of the software.
  2. Integration Testing: Tests the interaction between integrated units.
  3. System Testing: Assesses the complete, integrated system or software.
  4. Acceptance Testing: Determines system acceptability based on business requirements.

Each level serves a distinct purpose in ensuring software reliability.

Best Practices for Software Testing

  • Continuous Testing: Test each build as it becomes available to reduce risks and improve functionality.
  • User Involvement: Engage users to understand their needs and perspectives during testing.
  • Test Segmentation: Divide tests into smaller parts for efficient analysis and resource utilization.
  • Metrics and Reporting: Track project metrics and share test results for improved collaboration and decision-making.
  • Regression Testing: Continuously validate the application to maintain its integrity.
  • Avoid Programmer Bias: Programmers should refrain from writing tests to maintain objectivity.
  • Service Virtualization: Simulate systems and services to reduce dependencies and start testing sooner.

Benefits of Software Testing

  • Product Quality: Ensures delivery of high-quality software by detecting and fixing errors early.
  • Customer Satisfaction: Identifies and resolves issues before delivery, enhancing user experience.
  • Cost-effectiveness: Saves time and money by detecting and fixing bugs in early stages.
  • Security: Protects software from internal and external security vulnerabilities.

Sources – https://www.geeksforgeeks.org/software-testing-basics/

From the blog CS@Worcester – CS: Start to Finish by mrjfatal and used with permission of the author. All other rights reserved by the author.

Sprint #1 Retrospective

Achievements & Challenges

Reflecting on what worked well, one aspect was our organization. From the start, we established a strong foundation with clear and well-defined issues, allowing us to hit the ground running. The team demonstrated a balance between offering assistance and providing constructive feedback on each other’s work, creating a collaborative and supportive environment.

However, GitLab presented a learning curve that took us a bit longer to fully grasp and navigate. This resulted in occasional roadblocks, such as instances where work had already been done or where components were missing, requiring further elaboration. Recognizing these challenges is the first step toward overcoming them in future sprints. Another issue we faced and have already solved was our Sprint planning meeting, creating a more team-balanced approach. Originally, we had only one member creating issues as we talked about them. However, we realized this was not the best approach. For Sprint 2, we had each member create issues that we originally defined as a team. Then, we gave each member a chance to talk about their issues, how they plan to work on them, and if any improvements/clarifications would be needed.

On the team improvement front, our collective strength shone, especially when tackling potential ideas for more challenging tasks ahead. Moving forward, we aim to enhance our coordination by implementing more frequent check-ins. This approach will ensure that no team member is too far ahead, behind, or engaged in incorrect work, establishing a system of checks and balances within the team dynamic. Another improvement that will benefit the team as these issues begin to become longer and more challenging is more team-based work. After reviewing other teams’ work in the first sprint, I noticed multiple issues where more than one team member was working on an issue. This step will allow more time and a second pair of eyes on an issue, improving our productivity and furthering our ability to tackle an issue simultaneously.

Individually, I’ve identified areas for improvement that will contribute to both personal and team success. Managing time more effectively is a key focus, acknowledging that optimizing productivity requires a strategic approach to time mangement. Additionally, recognizing the importance of communication, especially on off days, will be crucial in maintaining a good workflow. The goal is to avoid getting too ahead of myself and attempting to tackle everything simultaneously. This includes refraining from taking on multiple issues beyond what is required, ensuring a more measured and sustainable workflow.

GitLab Work

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/documentation/-/issues/10

Description: In my individual assessment above, I recognized a mistake in attempting to tackle more than necessary. While working on issue #1, I unintentionally delved into other topics. In an effort to make the branch more user-friendly, I decided to combine these three separate issues into a single, comprehensive one. This new issue provides clear documentation for each step involved.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/documentation/-/issues/10

Description: This issue involved a straightforward review of the existing documentation. The focus was on ensuring the pipeline’s smooth operation by confirming the correct properties. Additionally, unnecessary extensions and linters were eliminated to simplify and optimize the documentation.

From the blog CS@Worcester – CS: Start to Finish by mrjfatal and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns Intro

Dave’s Story

The narrative of Dave’s journey serves as an illustrative example of how apprenticeship patterns can contribute to personal growth in software development. It emphasizes the importance of mentors, the willingness to expose ignorance, and the value of continuous learning and experimentation. Dave’s story underlines the idea that apprenticeship is a dynamic and evolving process, shaped by experiences, challenges, and the pursuit of improvement.

What Is Software Craftsmanship?

It critiques existing definitions of software craftsmanship, drawing inspiration from medieval craft models. While it rejects a rigid hierarchical structure but advocates for a modern craft studio where practitioners are free to innovate. The author also emphasizes the need for a community united by shared values, such as a growth mindset, adaptability, pragmatism, openness to sharing knowledge, and dedication to self-improvement.

Roles in Software Craftsmanship

The passage outlines three key roles in software craftsmanship: apprentice, journeyman, and master. Apprentices focus on personal growth, learning, and building foundational skills. Journeymen expand their responsibilities to include communication, mentoring, and portfolio building. Masters not only excel in their craft but also contribute to the industry’s advancement, mentoring others and creating tools or techniques that elevate the entire community.

What Is Apprenticeship?

The concept of apprenticeship is explored as a way for individuals to learn about professional software development. It is portrayed as a mindset, acknowledging that not everyone has the luxury of a formal apprenticeship and that many must create their own learning opportunities in less-than-ideal situations. The text encourages individuals to recognize their position at the beginning of their career and actively seek opportunities for learning and growth.

What Is an Apprenticeship Pattern?

The authors introduce apprenticeship patterns as guidance for career progression in software development. These patterns, extracted from personal experiences and practitioner interviews, offer flexible solutions to common challenges. The book is structured as a pattern language, allowing readers to choose, combine, and adapt patterns based on their unique circumstances.

Reflection

Through the reading felt very connected to Chapater 6 which focused on the
Idea that there is so much to learn but only one of you. I often find myself overwhelmed trying to learn as much as possible just to be versatile. Whether that be multiple languages, IDEs, frameworks, or anything in between. I finally was able to take some time to create a roadmap that I could follow that would better help me achieve my end goal of becoming a full-stack developer. This map focuses more on understanding over forcing content down someone’s throat and allowing the user time to properly learn and experience the tools needed to reach my goal.

From the blog CS@Worcester – CS: Start to Finish by mrjfatal and used with permission of the author. All other rights reserved by the author.

CS-443 The Start

Hi everyone,

This semester we are back with some new exciting blogs that will cover the course CS-443, Software Quality Assurance & Test. We will learn about developing and implementing thorough test plans, applying diverse testing techniques efficiently, computing test coverage, conducting reviews, and assessing software processes for quality promotion. Be on the lookout for all the upcoming blogs.

From the blog CS@Worcester – CS: Start to Finish by mrjfatal and used with permission of the author. All other rights reserved by the author.

LibreFoodPantry

Website Review

The content from the LibreFoodPantry website was very informative and easy to follow. However, the content was information I have already received due to multiple in-class discussions regarding the project. Instead, I would like to take the time to review the website design and ease of use. One highlight of this website is the use of knowledge given, no matter the user background. This website caters to users who might come here wanting to know what this project is doing for the world, while others may come to learn more about the technical side of this project. The landing page acts as this buffer, giving a quick snapshot of this project as a whole, while providing additional pages to those who would like to know more. Also, this website has dark mode available and is easy to find!

Gitlab Review

One thing that surprised me was that each system had an experiment group that could be used. The purpose of this group is to allow users to create temporary projects that are used for educational use only and will not be pushed to production. I wrote about this as something I haven’t seen yet or heard much about. I find this to be a much more organized way to handle temporary files without the accidental chance of being pushed to production.

From the blog CS@Worcester – CS: Start to Finish by mrjfatal and used with permission of the author. All other rights reserved by the author.

CS-343 Wrap Up

APIs, or Application Programming Intеrfacеs, sеrvе as softwarе intеrmеdiariеs facilitating communication bеtwееn divеrsе applications or dеvicеs. Thеy arе vital for intеraction with wеb browsеrs, mobilе dеvicеs, and third-party softwarе. APIs opеratе through protocols, primarily ovеr thе intеrnеt using HTTP, and arе likеnеd to a mеdiator facilitating communication bеtwееn a usеr and a backеnd systеm.

REST APIs, a usеr-friеndly stylе of API architеcturе, usе HTTP mеthods likе GET, PUT, POST, and DELETE. REST API Managеmеnt involvеs four kеy componеnts: API Dеsign, API Gatеway, API Storе/Dеvеlopеr Portal, and API Analytics/Dashboard.

Thе principlеs of writing clеan codе еmphasizе using commеnts judiciously, brеaking down mеthods into focusеd units, incorporating unit tеsting, and еliminating codе duplication. Clеan codе еnhancеs rеadability, еfficiеncy, scalability, and rеducеs thе likеlihood of introducing bugs.

Documеntation is crucial for codе maintеnancе and collaboration, еncompassing low-lеvеl or inlinе documеntation, high-lеvеl documеntation, and walkthrough documеntation. Convеrsеly, anti-pattеrns likе Spaghеtti Codе, Goldеn Hammеr, and Boat Anchor hindеr codе maintainability and dеvеlopmеnt.

Dеv Containеrs, or dеvеlopmеnt containеrs, offеr a complеtе and isolatеd dеvеlopmеnt еnvironmеnt accеssеd through SSH in prеfеrrеd IDEs. Thеy addrеss sеtup configuration issuеs, standardizе projеct build instructions, еnsurе isolation of dеvеlopmеnt еnvironmеnts, еnablе consistеncy across tеams, and simplify onboarding and training procеssеs. Thеir adoption is bеnеficial for rapid dеvеlopmеnt, prototyping, and addrеssing challеngеs associatеd with divеrsе local еnvironmеnts.

This is just a quick summary of what I have been through in CS-343. It was a very impactful semester that taught me many new things. I believe what I enjoyed the most was working collaboratively in teams. I find myself always working better in a structured group and retaining information much better. Towards the end of the semester, when we started to work with APIs, specifically the backend/frontend, I noticed a big usage of JavaScript. The homeworks became a little more challenging because of this, and I am going to use my break to get a crash course in JS. I also am working on a personal project where I will soon be implementing a frontend GUI, so the timing works out great.

I also cannot wait for the capstone class next semester as the whole idea behind the class just sounds perfect. I am a very hands-on guy, so getting to finally work on an actual project for a semester with a team and implementing what we learned will be a learning experience. Also, a great way to practice for internships and job opportunities for the future.

Sources:

https://www.freecodecamp.org/news/standardize-development-environment-with-devcontainers/

https://medium.com/@krunalchauhan_/article-worth-reading-on-what-is-an-api-what-is-a-rest-api-and-deep-diving-into-rest-api-fea074dacaed

https://www.linkedin.com/pulse/benefits-clean-code-your-application-development-daniel-donald/

https://swimm.io/learn/code-documentation/code-documentation-benefits-challenges-and-tips-for-success

https://www.atlassian.com/agile/project-management/scrum-values#:~:text=Scrum%20is%20a%20set%20of,solving%20and%20reducing%20project%20timelines.

From the blog CS@Worcester – CS: Start to Finish by mrjfatal and used with permission of the author. All other rights reserved by the author.

Dev Container Basics

What is a Dev Container?

A Dev Container, or development container, encapsulates a complete development environment accessible through Secure Shell (SSH) in your preferred Integrated Development Environment (IDE). It overcomes workflow impediments such as low performance and limited bandwidth by providing an isolated environment with standardized configuration stored in a .devcontainer.json file. This JSON file, structured with Comments (jsonc) metadata, allows customization for specific needs, such as adding tools or extensions.

Why Use it?

Addressing Setup Configuration Issues: Maintaining and managing local environments involves the use of various tools and configurations, leading to a cumbersome process. Standardizing this process with a unified approach can significantly save time and streamline setup configurations.

Standardizing Build Instructions of the Project: Documenting dependency upgrades and changes can be challenging. Utilizing code rather than extensive documentation simplifies the process, enabling anyone to ship without being hindered by the “it works on my machine” dilemma.

Ensuring Isolation of Development Environments: Developers often work on multiple projects simultaneously, each with its own complexities. Isolating environments prevents conflicts with other software on the host system, creating a clean, controlled space for development tasks.

Enabling Consistency Across Development Teams: Achieving portability across diverse teams is complicated by varying technologies and configurations. Implementing a standardized development environment ensures uniform configurations among team members, minimizing inconsistencies from individual machine differences.

Simplifying Onboarding and Training Processes: Quickly launching environments in isolation facilitates learning new languages or frameworks. This approach is particularly beneficial for onboarding and training processes, keeping machines clean and allowing for smooth presentations and workshops, where everyone can follow along without interruptions caused by missing tools or confusion mid-step.

Dev Containers in Real World Enviroment

  1. Standardized Development Environments:
    • Dev Containers provide a standardized and reproducible development environment, ensuring that all team members work with the same configuration. This minimizes the “it works on my machine” issue and streamlines collaboration.
  2. Setup Configuration Management:
    • Addressing setup configuration issues is simplified with Dev Containers. They help in managing dependencies, tools, and configurations uniformly, reducing the time and effort required for setting up development environments.
  3. Version Control Integration:
    • Dev Container configurations are often stored in version control systems (e.g., Git), ensuring that the development environment is versioned along with the code. This enhances collaboration and makes it easier for team members to switch between branches or versions seamlessly.

Personal Experience

Dev Containers are something I have recently just learned about, and I feel like the need for them is understated. The overall idea behind such a tool is to create a simple and consistent environment for a team to work in. Anytime I work on a project, I stress the need for one as it eliminates many common problems teams face in the early stages of development. I also believe that when I start my professional journey, I will find these containers to be more standardized within the teams I work with.

Sources:

https://www.freecodecamp.org/news/standardize-development-environment-with-devcontainers/

From the blog CS@Worcester – CS: Start to Finish by mrjfatal and used with permission of the author. All other rights reserved by the author.