My name is Ankit. I am a senior in computer science at Worcester State University.
This blog is related to the software testing, I will be posting every week.
From the blog Ultra Code by Anonymous and used with permission of the author. All other rights reserved by the author.
My name is Ankit. I am a senior in computer science at Worcester State University.
This blog is related to the software testing, I will be posting every week.
From the blog Ultra Code by Anonymous and used with permission of the author. All other rights reserved by the author.
My name is Ankit. I am a senior in computer science at Worcester State University.
This blog is related to the software testing, I will be posting every week.
From the blog Ultra Code by Anonymous and used with permission of the author. All other rights reserved by the author.
My name is Ankit. I am a senior in computer science at Worcester State University.
This blog is related to the software testing, I will be posting every week.
From the blog Ultra Code by Anonymous and used with permission of the author. All other rights reserved by the author.
My name is Ankit. I am a senior in computer science at Worcester State University.
This blog is related to the software testing, I will be posting every week.
From the blog Ultra Code by Anonymous and used with permission of the author. All other rights reserved by the author.
My name is Ankit. I am a senior in computer science at Worcester State University.
This blog is related to the software testing, I will be posting every week.
From the blog Ultra Code by Anonymous and used with permission of the author. All other rights reserved by the author.
My name is Ankit. I am a senior in computer science at Worcester State University.
This blog is related to the software testing, I will be posting every week.
From the blog Ultra Code by Anonymous and used with permission of the author. All other rights reserved by the author.
In the blog written by Alex Naraghi on What I Didn’t Understand as a Junior Programmer, he states, “There is no excuse for not understanding the lines you have written, or you are debugging. There is no shortcut, even if it feels like there is.” It is much better to spend time mastering the entire system and understanding a project’s architecture. Spend the time to use good programming principles and design pattern. However, it’s interesting that what was warned in the article was what I did during the past summer.
I was tasked to develop prototypes for some basic mobile applications for the company. They wanted an application that can search their publications, and retrieve the info. I had some experience in Java and also Android Development, but let’s be frank, after not touch Android for a year, I only had a cursory understanding of what was going on. IDE changed, APIs deprecated, and with that a whole slew of new issue will pop up once coding starts. I was also tasked with learning Swift for IOS development, in which I had no experience in. They gave me some code some other intern wrote in the past, (which was written in Swift 1). Being an intern with not much to lose, of course I confidently said, “Yeah, I can do all of this.”
In the end, I pulled it off. 2 weeks were spent writing an Android application that can search, filter by categories, and use the microphone for speech to text search. The last one my boss was most impressed with, although it was basically a very few lines I read browsing stackoverflow. Swift was the same, 2 weeks of watching Youtube videos and browsing stack, I jury rigged an updated IOS app that allowed searching. My boss praised me, commenting that I gave an intern a month and he made me two apps. It didn’t matter the two apps were designed pretty terribly and running on janky code, but as my boss says as I cautiously brought this up, “hey it works.”
“Now, I believe that even if you fix a bug through fiddling around, it is more than likely you haven’t solved it.” The IOS app, I can only somewhat understand what I did and there were probably numerous issues with it. For that project, it was only a quick and dirty prototype. However, in the future, if I’m working on a huge code base, there is no way I can just fiddle my way around while not understanding the system without serious repercussion on future maintenance. The statement I hear often is, “as long as it works, nothing else matters”. A belief that I often read and now seen permeating through middle and upper level management. Alex Naraghi’s post just reaffirms my belief that in the world of programming, that the statement couldn’t further be from the truth.
Understanding the code and fixing problems as a programmer:
http://blog.alexnaraghi.com/what-i-didnt-understand-as-a-junior-programmer
Further interesting articles I read this week:
Al-Jazeera stealing codes from a web development company:
https://www.scrollytelling.io/al-jazeera.html
Learning Angular2 is excruciating (and JavaScript in general):
https://hackernoon.com/why-learning-angular-2-was-excruciating-d50dc28acc8a#.nb7772a3b
Chrome setting marking all HTTP to be unsecured in the future:
https://www.troyhunt.com/heres-how-broken-todays-web-will-feel-in-chromes-secure-by-default-future/
Knowledge Debt:
http://amir.rachum.com/blog/2016/09/15/knowledge-debt/
From the blog CS@Worcester – Site Title by nealw5 and used with permission of the author. All other rights reserved by the author.
This article originally caught my eye because of the title, “What To Do When There Isn’t Enough Time to Test?“. I have been a Software Engineer intern at a company called Innovative Defense Technologies for the past 3 Summers. I started off my internship as a Freshman (incoming Sophomore) not knowing too much about programming, so yep, I was thrown right into testing. I have learned through my experience as an intern that there is always something else that can be tested. Code is constantly changing as the developers fix bugs, or add new features to the product. As a tester in a company, it is your responsibility to be able to keep testing all of the old stuff, while also keeping up with the new. I have become extremely familiar with the testing process, and trust me when I tell you .. there is NEVER enough time to test.
The main point of the article,written by STH author Swati S., is to give testers tips on what to do when they are running out of time, and how to prevent that from happening in the first place. The first tip that stuck out to me was to never under-estimate how much time you need. You always want to over-estimate to make sure you 100% give yourself enough time to test everything. There is always the chance of you running into a problem that may take you longer then expected to deal with. When I first started integration testing, my first Summer as an intern, I remember being very overwhelmed and feeling rushed because I under estimated how long it would take me. Another tip that I liked, was to use a test management tool. It is a lot easier to keep track of everything when you use something to help make life easier. I thought the conclusion in this article was very interesting. It states, “Finally, despite all the precautions and measures if you still find yourself crunched for time, ask help. Most teams are willing to participate in a war room session to get things back on track.” I can say that though personal experience this is very much true. Although testing may not be the most fun thing in the world to many developers, most people are always willing to help when they know you are trying to get everything ready for the release! Overall, this was a great article and I would recommend any new tester to take the time to read through it.
Links to some more blogs I’ve viewed this week:
From the blog CS@Worcester – Alex's Comp Sci Blog by alexsblog13 and used with permission of the author. All other rights reserved by the author.
Hello,
My name is Ryan. I am a senior in computer science at Worcester State University. This blog will be used to discuss various topics in the field of computer science which I find interesting.
From the blog CS@WSU – :(){ :|: & };: by rmurphy12blog and used with permission of the author. All other rights reserved by the author.