Author Archives: dylanbrowncs

Security Testing

Security testing is a form of testing which is rapidly growing with consumers’ needs for security on the internet. As the article states, cybersecurity is becoming very important when you are online not only for personal reasons but also for business purposes. Many companies now use multiple online resources just to run their business day to day which may include payment systems, payroll, database management or any other range of services which are offered to companies through different platforms in order to help business owners run their business as efficiently as possible. These platforms have to be trusted so that consumers continue to use them and recommend them to friends, family, etc. Some examples provided of security issues within an  application are a student management system being insecure if the admission branch of the system can edit the exam branch, online shopping malls or any online storefront is not secure if the details from users credit cards or other payment methods is not encrypted as this opens up the users to credit card fraud, and even custom software can have security issues which is highlighted by the articles example of an SQL query retrieving the actual passwords associated with users accounts. Two tools recommended in this article for security testing are Invicti which is a web application that is used to scan both legacy and modern applications and Indusface which includes scanners for web, mobile and API applications. There are also different techniques involved with security testing some of these being access to application which involves going through the different roles in a system one by one ensuring they all only have access to what they should, data protection which similarly to access to application is meant to ensure that a specific user/role cannot see an aspect or menu of the application they are not supposed to and error handling which ensures detailed error messages cannot be used to aid in hacking.

Security testing while not being something we directly worked on during the semester it would have been interesting to work with as the many different types of security testing and the many different risks associated with application security. This type of testing seems to be much more manual in many aspects versus directly writing test cases as we did in most cases but being able to test for access or test the permissions of a role in a system would be very interesting to work with.

From the blog CS@Worcester – Dylan Brown Computer Science by dylanbrowncs and used with permission of the author. All other rights reserved by the author.

Performace Testing,up%20under%20a%20given%20workload.

Performance testing is a form of testing in software development which is called non functional testing. Non functional testing means that the software’s function is not directly tested during this type of testing and in turn this makes a large majority of people view performance testing to be an afterthought or unimportant compared to other types of testing. Performance testing is specifically responsible for testing how a system or software may perform under a heavy amount of traffic or stress provided by many requests or users concurrently using the system. Some of the reasons that an organization may choose to undertake performance testing are to ensure a specific amount of users can be handles (for example 1000 concurrent users), to locate bottlenecks within an application which hinder performance or result in errors, to ensure that software is performing up to the standard that was given by the softwares vendor and to measure general stability as traffic goes up and down. Performance testing can require many different steps depending on the type of application being tested, the tester must make sure to look at the environment they wish to use for testing as well reading documentation on the environment or systems hardware in order to ensure the proper environment is used as performance testing may or may not involve testing within the production environment. The tester must also decide what is deemed acceptable performance wise which may involve meetings with the product owner or production team in order to set the correct standards for your tests and then you must also plan and design your original tests for performance. These tests may be all that you need, but if you require further testing due to necessary changes in a system if the system is originally unable to meet the requirements you will have to redesign and re-run your tests.

I feel as though performance testing is a lot more important than some people may think, especially to very large companies or social media platforms as they need to be able to accommodate a certain number of users not only everyday but also a certain number of users concurrently. Companies like amazon, microsoft, facebook, etc have to deal with thousands of customers or users at once and they can even reach millions of concurrent users which means they must do thorough performance testing in order to maintain the stability of their platforms and keep consumers happy.

From the blog CS@Worcester – Dylan Brown Computer Science by dylanbrowncs and used with permission of the author. All other rights reserved by the author.

‘Breakable Toys’ Pattern

The “breakable toys” pattern from chapter 5 is one of if not the most important pattern contained in this book in my opinion. This pattern specifically talks about the necessity of learning from failure even if your work environment does not allow you to do so. A situation like this is common within industries such as software engineering and the example the book gives of a juggler and how someone who can juggle three balls would not attempt to juggle five while actually performing which relates to software engineering as this pattern encourages you to make mistake and learn from your failures on your own time if your workplace does not allow it. “Breakable Toys” also suggests constructing a similar system to the one you may work on at work in order to be able to experiment on your own time and learn from your mistakes in an environment that directly resembles the one you are in at work. You should push yourself to find learning opportunities for yourself through the use of this pattern as if you do not have those opportunities at work then you must make your own in order to continue learning and get better at your craft. It is also stated that your “breakable toys” should be things that you find fun or have interest in so that even though they are meant to provide learning experiences for you, you are still engaged enough to where you look forward to working with them.

I think that this pattern is very important especially to a software engineer. No matter what company you work at there will eventually be a job where you are expected to make nearly no mistakes and you will not be able to try different solutions due to this expectation. But if you are able to experiment with different solutions on your own and see why they may not work or why they do work you can not only learn for yourself but you can also help the team you are working on evolve from using one standardized solution to using one that could be more efficient or faster.

From the blog CS@Worcester – Dylan Brown Computer Science by dylanbrowncs and used with permission of the author. All other rights reserved by the author.

Sprint 3 Retrospective

This was our third and final sprint for the semester and I believe we improved greatly when it came to working as a team compared to our previous sprints.We completed all of our issues during this sprint as a team during our various meetings which allowed us to collaborate more and learn about the project together. These issues included getting our frontend properly running in gitpod, figuring out which files were needed from guest info frontend and changing the existing scripts as well as updating documentation in order to leave the frontend in a good state for the next team to work on it.

Overall I did not have any trouble with working on any of the issues this sprint and I feel as though our collaboration on the issues helped us complete them more efficiently. The issue we worked on regarding getting the frontend to run in gitpod was straightforward and we were able to complete it without much delay as we were able to effectively reference the guest info frontend as it was already able to run in gitpod. The second issue that we worked on as a team regarding the addition of more frontend files/file structure and changing the scripts also went well and we were able to complete that as a team without any major issues.. The final issue we worked on as a team included updating the documentation which was rather easy to complete as a team as we had good references and experience with documentation between all of us. We had two other issues regarding making a confirm page but we were not able to finish those during the sprint as we did not want to leave unfinished work for the next team to have to deal with.

We did not have many problems during this sprint and I feel as though we all improved and worked together efficiently as a team. We all attended every meeting that we had scheduled and we all contributed directly to the project through code, documentation etc. The more collaborative nature of the work we did this sprint with each issue relying on the previous issues being completed first allowed collaboration to be a vital part of the process as we were able to finish issues in a timely manner when having all of our ideas going towards the completion of each issue. I feel as though we were all able to draw on one another’s strengths when working during this sprint which is something we were lacking slightly in the previous sprints. We also improved even more when it came to usage of Gitlab as we are all more experienced in both gitlab and gitpod now and able to understand the processes used as well as the workflow. The two issues we were unable to complete regarding a confirmation page are set up so that the next team can work on them when they begin their first sprint and we made sure to update the wireframe along with the documentation to provide the best start possible for the next team.

From the blog CS@Worcester – Dylan Brown Computer Science by dylanbrowncs and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective

This was our second sprint of the semester and I would say we definitely did better in some aspects as a team while we still need to work on other aspects. I personally worked on one issue on my own while we did all the other issues completed during the sprint as a team during our meetings. These issues included ensuring the proper linters and pipeline stages in a repo, researching how to write vue code and implementing said code as well as developing the frontend with buttons and input fields to prepare for a confirmation page next sprint. Our group issue that we completed included researching vue as well as redesigning the wireframe for the addInventory frontend.

Overall I did not have any trouble with my individual issue during this sprint. My issue I worked on regarding the addition of linters and pipeline stages was straightforward and I was able to complete it without much delay as there were not many issues in any of the files after implementation of the necessary linters. The first issue that we worked on as a team regarding the research of vue code and making an example button also went well and did not take us long during our meeting. The second issue we worked on as a team included working on the frontend which was rather challenging as we do not have much experience with the frontend between us but we were able to add two buttons along with input fields in order to have a displayable frontend. Our last issue as a team was to redesign the wireframe for the frontend in order to prepare for sprint 3 which went very well as we are planning on adding a second page to the frontend which confirms the addition to the inventory.

We did not have many problems during this sprint but I still feel as though there are things we could work on to improve as a team. One thing we can improve on is everyone making it to scheduled meetings, during the sprint we had meetings where we were not all in attendance and the team members in attendance did not know that others would not be making it to the meeting so I believe we need to work on communicating more when it comes to having to be absent from a meeting so the team knows what to expect. Another problem we had during the sprint was being willing to ask for help when needed, although we all have little experience when it comes to frontend coding we still can bounce ideas off of each other in order to work through issues faster as it is more useful to the team if we all understand what we are working on and we all agreed when writing our working agreement that we would all be available and willing to help eachother or answer questions as needed. In my opinion we worked well together during our second sprint and I hope we are able to work together even better during our final sprint of the semester.

Issues worked on:

Verifying that all Thea’s Pantry projects have the correct extensions, linters, and pipeline stages – CheckInventoryFrontend

Research code for `button` implementation in Vue and HTML

Develop `Submit` button Vue and HTML files

From the blog CS@Worcester – Dylan Brown Computer Science by dylanbrowncs and used with permission of the author. All other rights reserved by the author.

Test Driven Development

Test driven development is an important method of developing which is based on first writing a test for what you want your program to do, this test will fail as you do not have any code written in orde for the test to pass but you then write the code which is necessary for the test to pass and then you continue repeating this process of writing a test then writing the code for said test to pass. You are encouraged to write the simplest possible code in order to make your test pass before moving on to the next test but you may need to do some refactoring between tests in order to ensure you do not have unused code, confusing methods or variables, etc. Test driven development is very helpful when it comes to testing the specifications of a system as you can write simple unit tests which would pass if a specification was met and when it fails you know that you still must add or change your code in order to make sure the specification was met for the end product. Other types of testing are also important to perform but test driven development can help you steer away from over complicated code and make sure that you do not have recurring duplication present when you regularly refactor between cycles.

I found this article to be particularly helpful when researching test driven development as it clearly breaks down the steps of test driven development in order for the reader to fully understand the process you must go through in order to follow this development method. Along with the thoroughly explained process this article also compares and shows how both acceptance test driven development and developer test driven development work together. As we just started working with test driven development in class I found this article to provide valuable insight into the definition and process of this testing/development model as it is something rather different compared to what we have worked on previously regarding testing as we usually have worked with code that needed tests written and not with tests that needed code to be written. Being new to TDD made it seem very confusing at first as it did not feel right to be writing the tests for code which did not even exist yet but the benefits of TDD are much easier to understand once you put this method into practice.

From the blog CS@Worcester – Dylan Brown Computer Science by dylanbrowncs and used with permission of the author. All other rights reserved by the author.

‘Sweeping the Floor’ Pattern

The ‘sweeping the floor’ pattern in chapter four pertains directly to the beginnings of an apprenticeship or just work in software in general. This pattern explains that when you first begin the process of working in software while you will not be nearly as knowledgeable or efficient as the other members of your team with more experience you will still be able to contribute in smaller or more simple ways in order to still provide assistance and work with your team as you learn how to do more technical tasks. This strategy can be applied in every field as when you start your career or even when you start a part time job in high school you first have to be taught how to do certain tasks in the correct way but while you learn how to do the more complicated tasks correctly you will still be able to put effort into making tasks easier for others who are already able to do the more complicated tasks that come with your job.

This pattern stood out to me as I believe that this is especially important to remember when you are entering any job or looking to start your career after college as the thought of ‘not knowing’ how to do the more technical tasks can be daunting for people at times as they see it as a massive obstacle you must overcome when in reality you are not expected to be able to do every task that more experienced team members are able to do. You are expected to contribute in any way you can to help your team work and provide insight while also remembering to continuously learn along the way in order to enable yourself to do these tasks in the future so that one day you are the ‘more experienced team member’ that someone looks to for guidance. Advice like this is important for college graduates that are just starting their careers as in most cases our first jobs will be learning experiences that we need to embrace and make the best of in order to further our understanding of both the field and our colleagues. 

From the blog CS@Worcester – Dylan Brown Computer Science by dylanbrowncs and used with permission of the author. All other rights reserved by the author.

Object Oriented Testing,encounter%20in%20the%20real%20world.

Object Oriented testing focuses on the behavior of an object or class within an  object oriented system with its goal being to ensure any interaction or expected behaviors are correctly carried out when the system is used. This type of testing also heavily relies on ‘real world’ situations for example when writing test cases you would base your cases on things that the system is likely to interact with in the real world input wise which makes it easier to identify any possible behavioral issues within the system. There are three different testing phases which are commonly used in object oriented programming which are Unit testing, integration testing and system testing. Unit testing is used when testing classes or objects while isolated from the rest of the software, integration testing is used to verify that objects or classes are able to properly work together and system testing is used when testing an entire system to verify that the system itself works properly. Object oriented testing also requires the tester to have knowledge of a system’s inner workings in order to properly test it. This type of testing obviously is used on object oriented software which would be any software that is written using an object oriented language so in that aspect it is limited as object oriented testing would not be relevant or necessary to software which is not in the object oriented domain.

I found this article useful as it gets straight to the point when it comes to outlining the basic idea behind object oriented testing but it also chooses to compare it to conventional testing which helps the reader to differentiate between some of the different attributes of the two testing types as well as some of their similarities. This really helps when it comes to understanding why object oriented testing is defined as its own type of testing when their are already many other testing methods. This article helped me gain a greater understanding of object oriented testing which will help me to think more in depth about the cases I am able to write while testing in the future. The specific use of real world scenarios mentioned in this article was particularly interesting to me as I had not previously thought about how using real scenarios would typically provide more accurate results and or errors as compared to randomly selected scenarios which will also influence how I write test cases in the future.

From the blog CS@Worcester – Dylan Brown Computer Science by dylanbrowncs and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective

With this being our first sprint of the semester it went well but we had our fair share of issues that we had to work through as a team which will help us make better decisions on our workflow and our team dynamic in the future. I personally worked on five issues throughout the sprint, one of these issues being a team issue and three of the issues being assigned to myself while we still worked as a team while going through our individual issues. These issues included adding the alex js linter to a pipeline and resolving alex js issues, adding a git pod dev environment setup to a repo in the project and moving from commands to bin for a specific repo within the project. Our group issue that we completed included researching frontend development and using our research to create issues for our second sprint regarding the wireframe for the add inventory frontend.

Overall I did not have much trouble with my individual issues within this sprint. My first issue I worked on with the alex js linter was straightforward and I was able to complete it without much delay as there were not a lot of terms flagged by the linter after its implementation to the pipeline. My second issue regarding git pod dev environments took a bit more time which was simply just due to the time it took to fully test the pipeline after a commit but I did not have trouble with implementing the git pod dev environment within the repository. My last individual issue involved moving from commands to bin, this was my most simple individual issue as it mainly consisted of renaming a folder and checking for commands which used the commands folder and changing it to use the bin folder. Our team wide issue of researching frontend and making issues also went well as we all attended the meeting and went over frontend basics together. Links to my individual issues are listed below.

Although we did not have a large amount of problems within this sprint I still feel as though there are things we could work on to improve as a team. One thing we can improve on is our timeline when it comes to reviewing, during the sprint we didn’t review our code until near the end of the sprint which just ended up being inefficient and experiencing this has led to us deciding to review code as soon as possible during this sprint instead of waiting until the end of the sprint in order to notify each other of any issues with our work with ample time to fix mistakes. Another thing I feel as though we all need to work on during sprint two is our use of gitlab as there were points where we got lost in gitlab when making merge requests, branches etc so being more careful when using gitlab will help us all remain more organized in order to ensure we get our code properly reviewed and merged within a timely manner. In my opinion we worked well together given it was our first time working in a team like this and hopefully we can continue to develop our abilities to work as a team throughout the next two sprints.

Alex JS Linter issue:

Gitpod Dev Environments Issue:

Move from commands to bin issue:

From the blog CS@Worcester – Dylan Brown Computer Science by dylanbrowncs and used with permission of the author. All other rights reserved by the author.

‘Find Your Mentors’ Pattern

The ‘Find Your Mentors’ pattern is about the idea of “apprenticing” yourself to someone who is more experienced than you are within your field of expertise. While this pattern should be considered for many different professions it should especially be considered for software development as having a mentor can be very helpful especially when you are trying to find your place in the huge world of software. One of the main ideas attached to this pattern is that you will have the realization that you are not the first person to start out being a software developer with little experience professionally as everyone that is currently in the field had to start at the same spot you are currently at and their knowledge can be beneficial to you in order to shape your own career and practices. The solution provided for this pattern is finding a master craftsmen in order to be supervised by them and have the proposed master shape your understanding of the field and your career, but it is also said that with computer science being a relatively ‘young’ field it is hard to find a true master as their are not many people that have ‘mastered’ all of computer science but that there are many people who may have mastered parts of computer science and you should seek out different people in order to increase your understanding of what each mentor you obtain has mastered in their time in the field.

I feel as though this pattern is very important because computer science is younger than many other fields and mentors can be hard to come by in fields which have many ‘masters’ nevermind fields which have very few like computer science. Explaining that it is ok and completely acceptable for a software developer to have many mentors throughout their professional journey in the different disciplines of computer science helps students such as myself realize that you can continue to explore further and further into the field without having to necessarily pick a specific discipline and settle to work on only that discipline for our entire careers but instead that we should feel encouraged to gain more knowledge as knowledge on other disciplines can help us to gain understanding within whichever discipline we are currently working within.

From the blog CS@Worcester – Dylan Brown Computer Science by dylanbrowncs and used with permission of the author. All other rights reserved by the author.