Category Archives: Week 12

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.

schedule1.png

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?

brokenscheduler.png
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.

absoluteschedule
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.

fixedabsoluteschedule.png
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.

Source: http://blog.teamtreehouse.com/css-positioning

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

https://player.fm/series/coding-blocks-software-and-web-programming-security-best-practices-microsoft-net/episode-49-clean-code-comments-are-lies

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

Source: http://www.castsoftware.com/blog/five-reasons-to-measure-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.

C4 Diagrams

Source: http://codermike.com/starting-c4

This week I decided to look up C4 Models and I found a blog that talked about what C4. This blog post called “getting started with C4” by Mike Minutillo talks about what the C4 model is. The C4 model is a way to let users communicate and describe software architecture. This is really good because when working in a group and asked to draw out the architecture of your code besides having everyone draw up a different drawing than each other everyone would have the same kind of structure across the board. C4 models is a toolbox that allows the team various well-defined layers of abstraction to develop and communicate the static structure of a solution. He then goes and talks about what the toolbox is and abstractly it is a software system that is made up of one or more containers, each of those contain one or more component which in turn implements one or more classes. With C4 there are 4 different levels of abstractions. Context, Container, Component, and Class (which is why I guess it’s called the C4. Makes sense, right?) Context shows key systems, the dependencies between them and the actors that access them. Container shows the high-level technology choices, how systems are decomposed into containers and how those containers communicate. Component shows the internal structure of a container and how it is decomposed into collaborating components. And finally class is a typical UML class diagram showing the internal structure of a component.

Why I like this blog is that in the blog Mike tells the readers step by step how these C4 diagrams are made and the perks of using it. They are very similar to UML diagrams so that way when showing these to the customer it would be easy for them to understand what you are writing and also I like this a little bit more because I feel like with the C4 diagrams they are more meant for programmers to share with each other and if someone were to join the project later on they would look at the C4 diagram and would not be lost on what to do. I think it is great that we have many ways to show our work besides UML diagrams and we are not stuck into one way of showing things and I would be using these types of diagrams in the future. This would be useful for future project in class and even when I move onto bigger and better things.

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.

Agile Testing Can Make or Break The Business

A recent blog post from Cigniti discusses the importance that Agile Testing has in enterprises (http://www.cigniti.com/blog/agile-testing-really-helpful-enterprises-stay-innovative-competent/).  The post does not argue whether or not Agile Testing is essential for enterprises, but instead discusses why it is essential for enterprises to employ this method of testing in it’s daily operations.   It is becoming increasingly clear that their are many benefits to incorporating Agile Testing in their enterprise.  Enterprises need to be flexible and able to change in order to stay competitive and try to keep an edge over rivals.  One of the biggest and most obvious advantages of Agile Testing is the flexibility it provides to not only the testing team, but all teams involved.  The short sprints that Agile Testing provides allows companies to adjust their goals quickly and easily if the customer or the development teams changes their desired outcomes.  This is essential to businesses that want to maintain an advantage over other companies and stay attractive to clients.  Agile Testing also helps improve the overall customer experience.  The flexibility and constant ability for change helps a business adjust to a customer’s inevitable desire to change their minds on what they want from their product.  Agile Testing also helps the testing team and development team communicate more and relay information back and forth to work with each other rather than against each other.  While there is always risks in producing a product Agile Testing greatly cuts down on these risks.  Being able to stay in constant conversation and working in sprints it allows teams to catch and resolve issues as they arise.  Companies can then adjust time frames as well as end user products in a timely manner rather than waiting until closer to the release date and having to push the launch back completely or risk losing the contract with the customer.  These all boil down to communication between all teams involved on the project.  Without proper communication Agile Testing falls apart and loses much of its efficiency.  It’s important to realize that the completion of a quality product that satisfies the customer’s needs is more important than the pride of any individual or team involved.  Programmers should be ready and willing to bring up any issues or faults that are found as well as be receptive to any constructive criticism from other team members.  This allows Agile Testing to work effectively and efficiently throughout the entire development process.

 

From the blog CS@Worcester – Tim's Blog by nbhc24 and used with permission of the author. All other rights reserved by the author.

#6 – Testing Talks

Testing Talks – Episode 169 With JeanAnn Harrison.

 

In this week’s testing podcast episode, Joe interviews JeanAnn, a Software testing manager who has been in the software quality assurance field for over 2 decades. JeanAnn begins by addressing techniques and best practices that make for a fluid testing process. I chose this particular episode because JeanAnn addressed automation in testing and critical thinking in testing. With the development of modern technology, software automation is the next big thing in the world today.

Another big thing she talked about was critical thinking. Critical thinking often refers to the ability to try different thought processes and develop new methodologies to achieve an already familiar goal. The ability to think outside the box, pushing yourself to look at things in a different way. To evolve ones thinking ability in testing, we can try to look at things outside the software-testing field. By doing this, one is able to develop logical means that are often necessary to find product boundaries and limits. Asking yourself questions like how? , when? , what ? , where ?. These simple questions often answers most of the questions for the software testers and help develop solutions and bugs that need to found. By asking these questions, you are able to see how the software or product could be integrated into computer systems, the kind of problems that can arise by implementing the new product/technology and what can be done to resolve issues should they arrive. Another big thing that she addressed was understanding software’s users and customer base. Developing apps and programs without expected audience leads to many problems in the software world. Imagine developing a mobile application for 70 year olds but its integrated into the latest iphone technology. This would not work out because most of the people in that range no longer have the ability to adapt to new technology or even use a cellular device. Again imagine developing a walker for blind people which has an activation switch installed on the side with an on and off reading. This will be physically challenging and difficult for the blind to optimally use the product. It might be the best product that all blind people needs but its inability to incorporate and account for the blind would instantly make it a bad design or a bad product to acquire. Simply put if you know your user base, you are able to find out what needs to be designed for the product to properly fit the needs of the users and customers.

 

 

LINK

 

https://testingpodcast.com/169-critical-thinking-in-testing-with-jeanann-harrison/

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.

Four Practical Steps to Execute a Software Quality Strategy

In this blog post, Pratik Kothari talks about software quality and gives us some tips on how to develop quality code. Software quality has been more important recently, as companies slowly learn asking for a realistic time-frame allows bugs and quality assurance issues to be caught early, saving time wasted on debugging later on.

What Does Software Quality Mean?

Organizations have different quality standards, for the author, “software quality means that your code is meeting the bare minimum business expectations and do not have serious usability issues.” He goes on to say that it’s next to impossible to implement software without any defects, and that having defects in the system does not indicate poor quality software.

“If the software is meeting business expectations at the end without compromising the user’s ability to perform their tasks, the quality of the software is acceptable.”

Who Owns Software Quality?

The author says that software quality should always be at the center of the software development process and should be owned by a team, not one person. Testers take the brunt of identifying quality issues but it’s everyone job to ensure your product is clean and free of major bugs.

When to Define a Quality Strategy

The strategy for maintaining quality should be one of the initial steps of a product. Everyone should be on the same page on what quality standards are to be met and what is considered done.

Quality Strategy

Having a quality strategy is key to ensure everyone knows the expectations of quality and done-ness. The quality strategy “should be owned and defined by the Project Manager along with Architects, the Testing Lead, and the key team members. Ideally, it should cover the below quality-related objectives.”

  • How to identify personas.
  • How to write and store test cases.
  • Unit testing plan.
  • Regression testing plan.
  • Automation plan.
  • Performance testing plan.
  • Code Quality Review.
  • How to measure quality.

Step 1: Communication

Giving team members a clear picture of what is expected, and who is accountable for what. Like giving developers a heads up if they need to add test development to a project, allowing them to give accurate estimates.

Step 2: Training

Ensuring that gaps in skills are filled with time to learn skills or new members who know the skills. It pays to keep team members up to date on the latest skills.

Step 3: Infrastructure

It’s important to “utilize the greatest and latest infrastructures for quality strategy.”

Step 4: Continuous Improvement

The team regularly reviews what is, and what is not, working well.

I chose this blog post because it had good information on ensuring quality standards in code. The content of the article had good tips for ensuring success and communication is possible in a team. I learned the importance of communication, training, good infrastructure, and continuous improvements. I will use this information in the future when working on a team of people, and strive to do my part in creating quality code.

The post Four Practical Steps to Execute a Software Quality Strategy appeared first on code friendly.

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