Category Archives: Week 12

Software Technical Review

In class we did a group activity which had us work together in teams of five and conduct a software technical review. In a software technical review you have a specific role in which you must fulfill specific duties. There are four roles. The producer, review leader, recorder, and reviewers.

Producer–  The producer is the person who created the work that is being reviewed.

Review Leader–  The review leader schedules the review meetings, prepares materials for meetings, conducts meetings, and writes the review report.

Recorder- The recorder’s job is to take notes of what is being said. They also document anomalies, decisions and recommendations.

Reviewer– The reviewer(s) job is to prepare an individual reviewer issue sheet that is given to the review leader before the meeting. The sheet contains all of the issues that the reviewer found with the code.

There are three different types of software technical reviews. The walk through, technical inspection and an audit.

Walkthrough- A walkthrough is an informal meeting with the producer and the colleagues. There is little preparation and little documentation.

Technical Inspection- A technical inspection is a formal process and includes training.  There is sufficient and budgeted preparation time and the team ic very carefully selected.

Audit– An audit is a review that is held by an external group. The purpose of audits are to ensure that you are conforming to standards.

Why would we waste our time with such a complicated process when we could just look for faults individually? Well, there are many good reasons why we hold reviews and why the process is so important.

Reviews push developers to communicate with one another, it gives an opportunity to train new employees, it helps management report progress in the business, you find defects, it builds team morale and it gives the customer reassurance that the product comes out the way it should.

Going into your first review is probably nerve wracking. If you can remember the proper review etiquette, you should be golden!

Be prepared– There is nothing worse than an unprepared team member

Be respectful- it is the golden rule after all. Review the product not the producer.

Avoid discussions of style- Not everyone likes the same thing you do, as long as it is not wrong leave it be.

Provide minor comments to producer at the end of meeting 

Be Constructive- help others, don’t bring them down.

Remain focused- identify issues and don’t try to solve them yet.

Participate- Do not try to get the spotlight, it can be annoying.

Be open- the results of the review should be available to the entire organization.


My source of information was our class slides, but you can learn more about software technical reviews here:

From the blog CS@Worcester – Rookey Mistake by Shane Rookey and used with permission of the author. All other rights reserved by the author.

Software Testing With Security in Mind

For this weeks blog post I wanted to take a look at the security aspect of software testing.  I feel that we have discussed many aspects of software testing in our CS 443 class but one of the aspects we haven’t really gone over is how to determine whether code we write is secure.  Many of us, at some point in our carriers, will probably write software that will be used in a web/ desktop environment. By testing such code for vulnerabilities before it is released we can save ourselves and the companies we work for from falling victim to data breaches and stolen information. I found this article titled, How to Test Application Security – Web and Desktop Application Security Testing Techniques, and it discusses the issues I have just introduced.

The author of the article defines security as meaning “that authorized access is granted to protected data and unauthorized access is restricted.”  They then go on to distinguish between desktop and web-based software and the different security needs for both. Essentially, they suggest that both types of software require similar security measures to protect sensitive data, however, most web based software will require a little extra security measures since this type of software is accessible to anyone on the internet.

In the Article the author brings up a number of interesting points regarding testing how secure a piece of software is but I would like to focus on three of their main points as I feel they are really important. The three points I’d like to focus on are data protection, brut-force attacks, and SQL injections/ XSS.  To test for data protection in your software, the author suggests, you should ensure all passwords in your DB are being encrypted when they are transmitted. Also, if your software is web based, you should be using the HTTPS protocol rather than HTTP and you should test certificate validity on the server side. When it comes to testing whether your software is vulnerable to brut force attacks, the author says you should have some kind include “some mechanism of account suspension” into your software.  Finally, in order to test for SQL injections and XSS attacks we must treat any part of the code that accepts user input as a vulnerability.  The author advises that make sure there is a maximum length of characters for valid input as well as a checking mechanism for basic SQL injection techniques.

From the blog CS@Worcester – Caleb's Computer Science Blog by calebscomputerscienceblog and used with permission of the author. All other rights reserved by the author.

Positioning in CSS

Recently while working on our final project, my partner and I ran into an issue involving the positioning of courses on a schedule. We were trying to figure out a way to place elements (courses) on top of another element (the schedule). Naturally on our way to a solution, we stumbled upon absolute positioning. Using this we were able to place the courses in their correct positions on the schedule.


Even though that solution seemed to work, there was something about it that didn’t sit right with me. For whatever reason, the thought of using an absolute position on the page to place elements on another element just did not seem like a smart thing to do. What would happen if I added elements above the table?

Oh no! What happened?


Because the table uses the default position, its placement is based on its order in relation to other elements. However, the courses are using an absolute position relative to the page.

The course CS248 is positioned relative to the page.


The solution to this is relatively simple, but not necessarily one of the most obvious solutions for those who are new to CSS.

CSS Positioning Blog

In the blog CSS Positioning: A Comprehensive Look, Louis Lazaris discusses the main types of positions used in CSS’s position property. The positions are:

  • static – positions the element statically, following the normal flow based on its order in relation to other elements, typically unnecessary.
  • relative – behaves the same way as a static element, except that if you give it a positioning attribute, such as: “left: 20px;”, it will be offset 20px left from its original spot.
  • absolute – causes the element to be completely removed the the document’s normal flow, no longer interacting with other elements. Absolute elements are positioned relative to the page, or to its parent assuming its parent is relatively positioned.
  • fixed – behaves similarly to absolute elements, however it won’t move when the document is scrolled or relatively to its parent element.

The key part of this is that absolutely positioned elements can be changed by added a relatively positioned element as its parent. Thus the simple solution to our problem was just to change the schedule (or table) to use a relative position, even though we weren’t making any changes to its position visually.

The course CS248 is positioned relative to the schedule, its parent element.

Not only does this change where the elements are positioned relative to, it also makes it so that if I were to set the width or height of the course’s container using a percentage instead of pixels, it would be relative to the size of the schedule instead of the page.

The reason I chose this blog was because it contained exactly what I was looking for: a way to place absolutely positioned elements relative to its parent.


From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

Thoughts on “AI Test Automation: The AI Test Bots Are Coming”

In this article, Greg Sypolt talks in brief about the role of AI as a software testing assistant.  I chose this piece because it combines a field I’m interested in (AI and machine learning) with the content of my software testing course.  I am interested in AI task automation already, so a piece that dovetails these two topics is a perfect fit.  The author has chops as well — he oversaw the conversion from manual to automated testing at his company, and offers training to help other teams transition to automation.

Sypolt starts off by outlining three uses of AI in testing:

  1. Automatic test case generation that reduces level of effort (he abbreviates as “LOE”) while maintaining consistent standards.
  2. Generating test code or pseudocode from user stories; a user story is a use case or use sequence for some kind of product (software or hardware).
  3. Codeless test automation, or testing without writing tests as code.

He then outlines the necessity of properly training the testing bots, and some of the difficulties that may be involved:

  1. Identifying the proper training algorithms.
  2. Collecting a massive quantity of useful data.
  3. Ensuring that bots behave in a reasonable fashion from a given set of inputs, and ensuring that they exhibit new behavior (generate new tests) when the inputs change.
  4. The training process never really ends; each new set of tests and results gives the bots another data point to learn from.

I firmly believe that we are at the very start of a revolution in machine learning.  Why not apply those principles to software testing?  There are, of course, a couple of issues that arise which Sypolt didn’t mention: quality of tests and accuracy of tests.

A point firmly pushed by other articles and texts I’ve read is that quality is more important than quantity.  There can be little difference between running ten tests and running one hundred tests if the extra ninety don’t teach us much of anything.  The trick isn’t to create an AI that merrily runs thousands on thousands of unit tests; it’s to create on that identifies the important tests which reveal faults we don’t know about and confine itself to executing exactly those.

It’s also very important to ensure that the AI has learned properly and is up to standards — and that means testing the AI.  Which means testing the AI that tests the AI, and it’s digital turtles all the way down.

I can take away from this article two things: Firstly, it’s reasonable to combine two fields that I’m interested in (AI and testing) and that resources exist or will exist to support the two together.  Secondly, the field of testing is constantly and rapidly changing.  Additional learning is crucial, just like AI systems continue to learn from each new piece of data.

Article link

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

Clean Coding- Coding Blocks

Episode 49 – Clean Code – Comments Are Lies



Coding blocks podcast is presented by Joe Zack, Michael outlaw and Allen Underwood. In this podcast episode, the authors discuss about creating good and clean code and eliminating as much comments as possible. Initially, I was very confused with this concept by pro developers because in my first intro to java class, my teacher emphasized on making sure that we adequately commented thoroughly on methods and functions that we wrote. There were even points that was taken for now properly commenting codes then all of a sudden, my CS 443 my professor tells me that commenting is not really a good practice since your code should be written so well that understanding the though process and program should very easy. But the more I thought about this, the more I understood what was being taught by the teacher and now this podcast episode. No one writes comments for print statements because it’s so rudimentary that, everyone basically understands it by looking at it. That’s how our algorithms should be designs. Code Readability and understanding should be the goal of all developers who walk out of school. Again using comments in clean code has its pros and cons. They almost never get updated while the code gets updated and fix. They tend to mislead because they are not often updated. They propagate lies and misinformation’s because as the code gets modified and updated, they are often left untouched. The only exception to this rule of thumb is when one is coding a public API that would be used by other developers. Comments are looked as a way for programmers to make up for their shortcomings in programing. If methods and variables are named and designed properly there would be no need commenting. Time used to create comments can be used to optimize the software program to increase its readability and logic flow. Another bad thing about comments is when they are not obsolete but just misleading. Also inaccurate comments put the developer in the wrong frame of mind and logic. The proper approach is utilizing refactoring and clean code techniques that build program structure and design instead of attempting to explain bad coding with comments. Ultimately, it makes sense that developers wanted to explain their thoughts and processes with comment but its just more effective when the thought process is explained in the logic and functionality of the codes and method.



Link – Episode 49

From the blog CS@Worcester – Le Blog Spot by Abranti3 Dada Kay and used with permission of the author. All other rights reserved by the author.

CS@Worcester – Fun in Function 2017-12-04 23:52:05

The article this blog post is written about can be found here.

I chose this article for this week because I was curious about integration testing, as most of what we’ve done up until now has been unit testing.

Integration testing, broadly speaking, is defined as testing used to determine if the connection between two systems work. Systems can be a lot of different things – different parts of the code in one software product, multiple software products working together, your code and a database, a database and the internet, etc. Sometimes individual pieces can work fine on their own, and yet the whole breaks down once they are combined.

The article offers a scenario where someone takes a picture, uploads it to twitter with a caption, and sends the link to a friend as an example of where faults discovered by integration testing might be found. If one of those steps fails and the tweet never shows up in TweetDeck, testing would have to be done to determine where in the chain of connections the fault lies, and then what specifically went wrong within that connection. The article suggests starting this process by reviewing the log files, which should offer an indication of how far the tweet managed to get.

The article gives electronic health record systems as another example of complex systems where integration testing is needed. There are about 20 different popular EHR systems in use, as well as ones created by healthcare companies, which all store data in one way and send it out in a different way. Records go out to insurance companies that want to receive them in different formats. There isn’t one record to represent all the medical information about one person, but scattered records containing different information based on what each party needs. This situation demands thorough integration testing of the connections between the EHR systems, billing companies, and insurance companies. With so much that varies, there’s a lot of opportunity for failure.

Reading this article helped me understand the different scales on which integration testing operates, and that I can’t think of a piece of software as existing by itself – it’s going to interact with others’ code and with elements in the outside world. It’s necessary to consider not just the software itself but the bigger picture. With this in mind, I will think about the ways in which my code interacts with other components and have an idea of where to start testing those interactions.

From the blog CS@Worcester – Fun in Function by funinfunction and used with permission of the author. All other rights reserved by the author.

Software Complexity


This week I looked up Software Complexity blogs. I found a blog called “Five Reasons You MUST Measure Software Complexity” written by Jonathan Bloom. This blog talks about how sometimes complex code aren’t the best thing. He gives you a few methods developed for measuring software complexity. Which are Cycomatic Complexity, Halsted Volume, and Maintainability index. With these methods companies and use the information found by them to capitalize how they are writing the code such as. Greater predictability because knowing the level of complexity of the code can make it easier to maintain and show how much maintenance a program will need. The software risk mitigation which manages the software complexity lowers the risk of introducing defects into production. Reducing cost because with lower mateine cost the origination can spend that money on other things. It extends the value of the programs because excessive complex application causes issues. With this it keeps the software in cheack and keeping the complexity of it in check. Finally, decision support with this it allows the owner the information to tell if it is worth the cost of even fixing the code or if writing new code be worth it.

The benefits of software complexity analysis are that it improves code quality, reduce maintenance cost, heighten productivity, increase robustness, and meet architecture standards. Because of this a lot of bigger and smaller business try to add this analysis to make sure that they are not losing money because the software is too complex for what they need. I like this blog because it backs up one of my other blogs that talked about keeping code short and sweet. We should do code as basic as we can to keep things neat and organized and don’t make it crazy so that way we don’t waste time doing things we didn’t have to do. I think I will keep this in mind when I move on to my next step of my life. Keeping code nice and simple is the best way. I also think that I will keep this in mind when I am working on the final project for many of my classes because we don’t want to write too complex programs for our robotics class and our software constr class as well


From the blog CS@Worcester – The Road of CS by Henry_Tang_blog and used with permission of the author. All other rights reserved by the author.