Category Archives: Computer Science

No Ragrets(sion) Testing

CS SERIES (5)“Forget about automating your regression tests” is some bold advice from Bas Dijkstra, who has experience as a test automation consultant. It made me wonder what exactly led him to making this kind of statement on regression test scripts and his article, On Ending the Regression Automation Fixation, covered various reasons why.

Two reasons why Dijkstra says starting with automating your regression tests is not ideal includes regression scripts being too long and how regression tests are written from an end user perspective. I find this interesting as a lot of software bloggers are saying automation is not always going to be the answer and their answers have yet to make me disagree.

Sam CS (10)

The reason I chose this is because I am drawn to honesty; two examples above were explained with scenarios with failures Dijkstra has faced from creating inefficient or “plain worthless” cases.

This content will change the way I think about creating potential testing cases as there will be questions to ask myself before proceeding with the task(s) at hand. There will be a lot of reflecting on what could be consuming my test time, which parts are too repetitive, or what can just be done better. I mean of course I’ve already been considering these questions but now there will be a more conscious effort to think about them.

Dijkstra’s process especially considers the difference between how many scripts there could be when a computer is trying to translate what a human could have performed when testing. I realize how that would be an issue when trying to understand what could have went wrong or does not match up fully when there is less (specific) feedback when it comes to automation.

Thanks to this article, I will also try to predict how many layers of regression scripts would be too much of a hassle to develop ways for communication between what is being tested under the application. Overall, this information was useful as we should be reminded that “automation is meant to make your life and testing applications easier”; it should make sense and not be done at random, especially for regression testing.


Article: https://www.ontestautomation.com/on-ending-the-regression-automation-fixation/

From the blog CS@Worcester by samanthatran and used with permission of the author. All other rights reserved by the author.

TheCurrentStateOf, SD 01110

CS SERIES (4)As someone who will be graduating within the next year, I’m always interested in what software development is currently like. Ekaterina Novoseltseva uses some 2018 statistics and presents interesting facts about software development through Apiumhub—which is a software development company based in Barcelona. The data in this article comes from a collection of over 300 answers from different countries around the world; starting with the challenges in software development.

The information collected on programming languages was interesting to me as Javascript, Java, and Python are the top three current primary programming languages for those companies. On top of that, Go is used around 6% and of the companies who are considering using another programming language in the next 12 months, Go is the second on that list. I like seeing this data to know what is currently popular and may be an upcoming popular language as this is constantly changing. Novoseltseva points out how about 37% “of respondents said they’re not planning to use any new programming languages in the coming 12 months” and it makes me wonder whether it is because they do not want to change their ways or if they are already so on top of the updates that they do not need to for now. It also makes me wonder how companies in the New England region are doing in terms of exploring new languages or ways to keep up to date on their projects.

Although I knew of the current trend(s) for the most part, I was surprised to see what Apiumhub had to conclude on software outsourcing. It shows an infographic where of the people who did outsource software development fully or partially, only 10.06% of them were “absolutely satisfied” and 51.57% were “somewhat satisfied.” Based on what I’d been hearing of people being worried of getting all the tech jobs outsourced, maybe the scare isn’t as bad as people led it on to be. I mean of course, the total majority of responses from that fall under “satisfied” but it was not fully satisfying—this would probably be best for quick, short-term fixes or work. Which shows how there is still more to people-to-people communication in the company’s direct workforce and it puts my mind at ease a little more.


Article: https://apiumhub.com/tech-blog-barcelona/interesting-facts-software-development/

From the blog CS@Worcester by samanthatran and used with permission of the author. All other rights reserved by the author.

Thanks for Coming to My Test Talk™

CS SERIES (3)After learning some life lessons through the pages I’ve skimmed from my copy of The 7 Habits of Highly Effective People by Stephen Covey; this article’s version for software developers in test caught my eye. What exactly are the seven highly effective habits of SDETs? Here are the seven habits that Angie Jones, a senior developer advocate at Applitools, wrote about: being intentional, enhancing development skills, enhancing testing skills, exploring new tools, automating throughout the product’s tech stack, collaborating, and automating beyond the tests.

If anyone is interested in becoming a SDET, they should follow Jones’ advice as she is very familiar with interviewing SDET candidates. Something thought-provoking about the first one is how automation projects are not always the best option. Before this article, I understood that not everything required automation but it was the end goal for more projects or companies overall. This is due to my experience; for some reason I believed that just because the company I was at wanted automation for something that everyone else would too. After reading this, I am now understanding that automation is only the goal when it is aligned with the overall outcome.

I am noticing a consistent pattern of guides to becoming a good software developer or tester containing similar tips like “enhancing development skills” and “enhancing testing skills” as people in this industry must always keep learning to stay on top of what’s new. Due to the repetition, I have been trying to keep an eye out for the more unique ideas. One of the ideas that stood out to me more is the one of collaborating.

Jones listed careers ranging from business analytics to software development and mentioned how they would be good matches for pairing up with SDETs to help each other better understand certain features and the importance of what they will be working on. From a sociological standpoint, I like this approach to finding all the resources to complete a project outside of the department. As someone who is always looking for ways to connect with people or connect people to other people, this is an effective idea for helping companies and their people feel more at ease with their jobs. The SDETs may feel less pressure knowing they are not entirely on their own and can request help when necessary.


Article: https://techbeacon.com/7-habits-highly-effective-sdets

From the blog CS@Worcester by samanthatran and used with permission of the author. All other rights reserved by the author.

if (two < one) {

CS SERIES (2)According to music artists, two is better than one. When it comes to designing code that has two parts, this may not be the case. In Max Kanat-Alexander’s article, he explains how he has a personal rule of needing to know how generic his code needs to be. He describes it as if he were designing an audio decoder and started out with supporting WAV files and then later needed to add support for MP3 files. His solution was for what he only needed on its own instead of having to copy and paste the common parts for the format; he emphasizes that “it’s not just two implementations that are bad, but also two locations.” Another rule Kanat-Alexander has for helping this stay consistent is to create code well enough to ensure you would ideally never have to go back and change it if another part of the code has to be modified.

I found this information useful because I believe that developers are always striving to be the most efficient coders they can be. In order to do so, using two of Kanat-Alexander’s methods would help them plan to code more effectively. Just imagine the potential headache of realizing you have to go further back to code you thought was finished and then even further back when you notice a change on top of what you originally needed to make. This will probably affect how I will work in the future as it will make me sit back and think beyond the task at hand. It would allow me to save room for potential add-ons without them crisscrossing, which would allow me to skip out on having to do more rework.

At the end of the article, Kanat-Alexander notes that the reader does not have to take this as a “hard and fast law of the universe” and I appreciate how he tries to help the reader but does not try to push them to do it his way. In terms of the subject, I do not think my thoughts have changed too much as I do want to learn how to code better and I would like to continue finding out about people’s coding structure process.


Article: https://www.codesimplicity.com/post/two-is-too-many/

From the blog CS@Worcester by samanthatran and used with permission of the author. All other rights reserved by the author.

Testing, Testing. QAn You Hear Me?

CS SERIES (1)To kick off this series, I wanted to introduce why Software Quality Assurance (SQA) testing is important not only for testers to understand, but for developers as well. From my experience, I’ve become familiar with manual testing and exploring different types of automated testing for web applications. I wanted to know a little more about how being a good developer also includes being a good tester and found an article on SimpleProgrammer which reveals the importance of knowing how to test.

John Sonmez, the founder of SimpleProgrammer, says that he “owe[s] a large amount of the success [he] ha[s] had in [his] career as a software developer to [his] background in testing.” I can see why he feels that way, as using just a little more time to double-check what you have created could save you even more time in the long-run. For instance, if something you have spent hours working on seems complete and you do not double-check it and pass it on to a QA team, you have to wait for someone in QA or a testing platform to check it. That could take anywhere between minutes to a few days or more. Once it is QA tested, maybe a bug is found and your task falls back into your hands again.

Could the scenario above been preventable? Yes and no. It is a true that “you can never find all the bugs or defects in a piece of [theoretical] software and you can never test every possible input into the [theoretical] software” but you can try your best. This doesn’t necessarily mean having to do your own end-to-end regression testing through the entire software each time you add a minuscule feature but you should thoroughly check what you have changed and the features directly connected to it.

The article continues to describe common testing forms and what they each mean for developers. Sonmez supports the Agile cycle of software development and describes it in the article as well.


Article: https://simpleprogrammer.com/software-developers-know-testing-qa/

 

From the blog CS-Series by samanthatran and used with permission of the author. All other rights reserved by the author.

The CS Series || Intro V2

Processed with VSCO with hb2 presetHey guys! This site is going to take a slight change in direction for the next few months; it’s my last year of college so your girl is going to feature some CS content for classes.

Stay tuned for more!

Samantha Tran

P.S. Please excuse my double-intro.

 

From the blog CS-Series by samanthatran and used with permission of the author. All other rights reserved by the author.

The CS Series || Intro V1

Processed with VSCO with hb2 presetHey guys! This site is going to take a slight change in direction for the next few months; it’s my last year of college so your girl is going to feature some CS content for classes.

Stay tuned for more!

Samantha Tran

P.S. Please excuse my double-intro.

 

From the blog CS-Series by samanthatran and used with permission of the author. All other rights reserved by the author.

Preparing to Present

Over the past semester, I’ve been working with Dr. Vallejos to build a website for Massachusetts HOSA. At the conclusion of my independent study project, I will be presenting my project to the Computer Science faculty and other CS students. In preparing for this presentation, I came to a couple of realizations about what I’ve learned from this experience.

While I certainly think that I have improved upon my technical skills in CSS and PHP, I think that what is perhaps more valuable is the immense amount of real-world project management experience that I have gained. This experience has already allowed me to build a better understanding of project requirements at work and for the software development capstone project with AMPATH Informatics. Being able to understand the requirements of stakeholders is essential to delivering a product that meets their expectations. Asking the right questions the first time will prevent having to reach out again and again for clarification of the requirements. People are generally very busy and they will not be available to answer your questions or provide you with information. Whether it is a customer, manager, or product owner, it is best not to waste other people’s time with comeback questions because of your own failure to fully consider the project’s requirements.

I also believe that I greatly improved my personal software development process throughout this project. Although it took a couple of mistakes for me to learn, I am thankful that I made these mistakes in a safe environment and lost nothing but a few hours of my time. I was initially pretty careless, making customization changes to the theme files directly on the web server itself, not backing up, and not tracking any of my changes. After losing all of my theme customizations by updating the theme, I decided to make some changes to this process. I implemented Git version control, allowing me to make and test changes locally before pushing to the actual website as well as tracking changes incrementally and allowing me to rollback to any revision, as desired. I also implemented automatic offsite backup in Google Drive, which runs weekly to ensure that even if I do mess something up, there’s always a working copy safely stored elsewhere.

I have always been an avid believer in learning through experience, and the MassHOSA website project has been a fantastic opportunity to learn through my experiences. Not only have I had the chance to both sharpen my technical skills and widen my skill set, I have gained invaluable experience managing a project and working with stakeholders on bringing an idea from the conceptual phase through to a working product.

From the blog CS@Worcester – ~/GeorgeMatthew/etc by gmatthew and used with permission of the author. All other rights reserved by the author.

Looking Back on the Final Working Sprint

Just like that, I am writing the final sprint retrospective for our capstone project working with AMPATH Informatics! I have learned so much about the development process, contributing to open source software, and especially working in a Scrum development team. I am extremely grateful for the opportunity to work with the AMPATH developers, my team, who were extremely helpful and made this experience valuable. I am thankful that the software development capstone has allowed me to contribute to a real-world application, and hopefully make some small difference.

In terms of concrete tasks for this sprint, I took on fewer development stories than in previous sprints, and chose to focus more on documenting and producing tests for what I have already contributed. Other team members were assigned develop tasks, however, and our implementation of an offline login is close to being a shippable product. The main item blocking a pull request to AMPATH is the lack of encryption for the stored credentials. They are currently only encoding in base64, which is about as good as plain text. We are unsure whether a working encryption implementation will be available before time runs out.

One of the development tasks that I took on for this sprint was to update the refresh time of the online tracker indicator on the bottom of the screen. When Dominique added a checkbox element to the user interface, she used a subscription that updated every three seconds. As a result, the checkbox would appear even when the online tracker indicated that the user was still offline. To fix this, I updated the refresh time of the online tracker component to match the subscription of the checkbox.

Another task that was assigned to Dominique and Luigi for this sprint was to implement the backend logic for the checkbox. While there are still some bugs, we should be able to work through them as a team if they are not resolved by the time we meet for review and retrospective. This logic should store credentials in localStorage only when the checkbox is checked.

A task that was assigned to Matt was to document the current status of our offline login implementation. During our in-class meetings, I discussed with Matt how my implementation works and where I made changes to the code in order to allow the user to login offline. I think that we will continue this task into the final presentation preparation sprint, where we all will be documenting our contributions.

Kwame was assigned the task of looking at writing tests for the offline login implementation. While he had some trouble writing tests, I think that this is something that we can all work on in the final sprint as part of documenting what we have done. I think that it might be easier to write tests for the code that we have contributed as individuals, rather than assigning all of the test writing to one person.

As mentioned earlier, we are waiting on an encryption service for the storage of user credentials from another team. While we were able to accomplish most of the requirements for the offline login implementation, the lack of encryption has kept us from submitting much of anything to AMPATH. Storing the user’s credentials in plain text is far too risky from a security standpoint, and I am doubtful that the developers would accept our implementation without encryption.

I am very happy with the progress that we’ve made as a team. I have certainly improved from the beginning of the semester, and it has been great to see other members of the team improve as well. I’m looking forward to the last sprint where we will compile all of what we have learned and implemented into a presentation.

From the blog CS@Worcester – ~/GeorgeMatthew/etc by gmatthew and used with permission of the author. All other rights reserved by the author.

Thinking Like an End User

I am getting ready to deliver a website product that I have been working on for Massachusetts HOSA. Because I’ve been working on the development of the website for the past couple of months, I am familiar with where to find everything. Once the product is delivered, however, it will be updated and maintained by Massachusetts HOSA. While I would be perfectly happy to continue helping out with the website as needed, I would like to minimize the need for my involvement by making the website as self-sustaining as possible.

In previous blog posts, I already outlined the setup of automatic backups. This makes me feel much better about enabling automatic updates for the WordPress installation. With automatic upgrades enabled, the site will be kept secure and up to date as WordPress and plugin or theme developers release new versions. I would be weary of allowing automatic updates if I was unsure of whether or not there were current backups because of the possibility of an update breaking the site. Occasionally there are incompatibilities between different plugin/WordPress version combinations, or simply bugs in a release that could make the site unstable. In case of such a scenario, having a recent backup that can quickly be rolled back to is essential.

The second part of making the site self-sustaining is to write documentation for the use of this specific WordPress installation. While WordPress is already extremely well documented, this vast documentation can sometimes be difficult to navigate efficiently. I would like to pick and choose the essentials to include in a slimmed-down version of documentation to provide to MassHOSA as a guide for the maintenance and updating of the website. This documentation will include guides for use of the WordPress platform, use of the various plugins that are installed, and also references to the locations of various resources such as backups and styling files.

I am extremely thankful for the opportunities that working on this project has granted me. While I may have had some prior experience building WordPress websites, this was quite different. I got a much better idea of the various stages of a design project and experience working directly with stakeholders to turn specifications into a working, real-world implementation.

From the blog CS@Worcester – ~/GeorgeMatthew/etc by gmatthew and used with permission of the author. All other rights reserved by the author.