Category Archives: Week-14

A Unique Idea for Designing Tests

Katrina Clokie, author of “A Practical Guide to Testing in DevOps“, offers us her unique insight into developing effective tests in her blog post “Generic Testing Personas“. In this article, Clokie explains how developing personas can be helpful in modeling expected behavior of users. This information is very valuable when designing different tests.

Clokie begins by explaining how good tests should cover all possible behaviors, to make sure that the software being tested is as adaptable as possible for different individuals. Developing “personas” for expected or stereotypical behavior can give an informed perspective when designing tests.

When designing personas, each individual should have clearly distinct behavior patterns and needs from one another. In this article, the author gives us an example of six personas that could be helpful when writing tests. Here I will just briefly describe two that I feel compliment each other and demonstrate the point nicely.

“Manager Maria” is a persona who is always busy and rushes through the software, consistently using shortcut keys, making mistakes, and constantly going AFK while using the program. For example, Maria might be frustrated with slow response times, so the tester ought to make sure the software is running smoothly even during times of high traffic.

In contrast, “Elder Elisabeth” has trouble with new technology and may require simple user interfaces, need to zoom far in, or may need to reach out for assistance. In Elisabeth’s case, the tester should make sure the program is visually stable, and can be run on older systems.

Both of these personas are stereotypes of real users who have different needs and behaviors. The more defined the characteristics of each persona, the more information about their needs can be inferred. It is the responsibility of both the developer and the Software Quality Assurance professional to make sure all of these different needs and desires are met to deliver the best possible product.

I very much enjoyed this article and I found Clokie’s perspective both interesting and helpful. I definitely enjoy and find important the application of heuristics in software design, and it makes sense that this knowledge would be helpful in the context of designing tests as well.

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

Parsing HTML and the Document Object Model

In A List Apart’s series “From URL to Interactive“, Blogger Travis Leithead describes in his article “Tags to DOM” how HTML documents are parsed and converted into the Document Object Model (DOM). Through the course of his post, Leithead explains encoding, pre-parsing, tokenization, and tree construction.

The first step to parsing an HTML document is encoding. This stage is where the parser must sort through each part of the input and sent from the server. Since all information computers handle is binary, it is the parsers responsibility to figure out how to interpret the binary stream into readable data.

After all the data has been encoded, the next stage is pre-parsing. During this step, the parser looks to gather specific resources that might be costly to access later. For example, the parser might select an image file from a URL tagged with a “src” attribute.

Next, the parser moves on to tokenization. This process is when all the markup is split up into discrete tokens that can be organized into a discernable hierarchy. The parser reads through the text document and decides which tokens to declare based on the HTML syntax.

Once all the document has been tokenized, each token is organized into what is called the Document Object Model, or DOM. The DOM is a standardized tree structure that defines the structure of the web page, organizing it into sections with a parent-child relationship. The root of the tree is the #document/<html> tag, and its children are <head> and <body>, the body may contain multiple children, and this organization contextualizes the data into a readable layout. The DOM also contains information about the state of its objects, so this allows for a degree of interaction that make complex programs.

I would highly recommend this article and this whole series to any budding developer such as myself, as understanding the entire process of how programs transform from code to an interactive website is integral knowledge. And the authors at A List Apart do a great job being both thorough and concise in their explanations. I definitely feel more knowledgeable after having read this article and found it valuable.

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

Journey Into The Top 7 Web Application Testing Practices for QA Professionals

As I take another step towards Software Quality Assurance Testing. The blog I will talk about is “Top 7 Web Application Test Practices for QA Professionals” from the TestingWiz  blog site.

This blog covers the top 7 web application testing practices for quality assurance professionals. It discuss how now and days mobile apps is being used more than desktop browsing. Which in terns is requiring enterprise to build more “mobile-friendly websites”, and because of that the QA professionals should be testing all aspects to ensure that website are performing more efficiently. It then goes on to list the 7 practices for skilled QA Testers to accelerate Web Application Testing with a brief description of each. Software testers must

  1. Concentrate on Cross-Browser Compatibility Testing
  2. Measure Application’s Performance Under Multiple Circumstances
  3. Test Each and Every Element of a Web Application
  4. Execute the Load Tests in Intervals
  5. Test Web Services Individually
  6. Pick Up the Right Factors for Usability Testing
  7. Work with an IT Professionals

After its listing of the 7 practices for skilled QA Testers to accelerate Web Application Testing. It goes on to mention that “TestingWhiz follows a thorough QA strategy that manages the unique challenges and requirements in relation to testing web applications. So, connect with our QA professionals to enhance and perfect the complete user experience of your application with our latest testing strategies.”

I found this blog to be very interesting and useful. I like that it gives you a list of things that should be tested to ensure that the application will work in various type of base that being either web, mobile or desktop and it also insure that the application work on different devices whether old or new. The best part is if you do not want to deal with having to do all of this testing you can contact their QA professionals that will help you out with the testing process. This is honestly useful if I am working on an application along with other work and I do not have time to concentrate on performing a quality assurance on my code. However, for the mean time I will insure I do the testing myself and make sure that I do follow these 7 practices for skilled QA Testers to accelerate Web Application Testing. I do not disagree with much of this blog. In fact I find it interested enough to recommend others to read it. the title of the blog above provides a link to the blog, I suggest you check it out. Thank you for your time. This has been YessyMer in the World Of Computer Science, until next time.

From the blog cs@Worcester – YessyMer In the world of Computer Science by yesmercedes and used with permission of the author. All other rights reserved by the author.

Path or No Path!

Source: http://www.professionalqa.com/path-testing

This week’s reading is about Path Testing. It is said that a vital part of software engineering, is to ensure that proper tests are provided such that errors or issues that exist within a software product will be resolved before it could turn into a potential costly threat to the product. By turning to path testing, it will help evaluate and verify structural components of the product to ensure the quality meets the standards. This is done by checking every possible executable path in the software product or application. Simply put, another structural testing method when provided with the source code. By this method, many techniques are available, for example, control flow charts, basis path testing, and decision to decision path testing. These types of testing include its fair share of advantages and disadvantages. However, path testing is considered a vital part of unit testing and will likely improve the functionality and quality of the product.

What I found thought-provoking about the content is the section on the significance of Path. By providing an understanding what the term “path” means will certainly break down the importance of this test. Knowing that path is likely describing a programs execution path, from initialization to termination. As a white-box testing technique, we can be sure that the tests cover a large portion of the source code. But it’s also useful that they acknowledge the problems that can be found while doing path testing. These errors are either caused by processes being out of order or code that has yet to be refactored. For example, leftover code from a previous revision or variables being initialized in places where they should not be. Utilizing path testing will reveal these error paths and will greatly improve the quality of the code-base. Also, I agree that path testing like most white-box testing techniques will require individuals who know the code-base well enough to contribute to these types of tests. Which also includes another downside where it will not catch other issues that can be found through black-box testing. This article allows me to reinforce what I had learned in class about Path Testing and DD-Path Testing.

From the blog CS@Worcester – Progression through Computer Science and Beyond… by Johnny To and used with permission of the author. All other rights reserved by the author.

Test Yourself Before You Wreck Yourself

CS SERIES (14)Testing, testing. I may need your approval on this article I read by Software Testing Magazine on Approval Testing. Approval testing, as defined by this article, is a way of software testing that results in presenting the before and after of an application for a user (ex: software development team) to review it and potentially approve it. It’s more of a visual representation of testing and one of the major cons is how the results have to be checked manually.

Some testing tools mentioned include: Approval Tests, TextTest, Jest, Recheck, Automated Screenshot Diff, Depicted (dpxdt), and etc.

The main purpose of the software testing tool, using TextTest for example, is checking that the text output after running program from the command line in different ways.

What I found interesting is how a user can see that a test technically could have “passed” or “failed” but still decide to mark it as the other because they choose what feature they are looking for in the end. This makes it a little more flexible to use approval testing as it is more of a guide or guideline for a user instead of only seeing one word and then a short description of what could have gone wrong. I think this process is much more transparent or descriptive with a user about what could have gone wrong or what went right.

One way the content has changed how I will think about the testing is how there are so many more types of software or programs out there than we can imagine which help us better code or create our own software and programs. This one is especially good for visual coders and testers who like to see their results firsthand to compare what they are expecting with what they actually got.

Overall, I found this article was useful because it introduced me to thinking about a better way of logging the differences between what the reference result is versus the actual result. I did not disagree with any of it since it showed us how we can use approval testing to our advantage while still being honest about its limitations.

Article: http://www.softwaretestingmagazine.com/knowledge/approval-testing/

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

Top 5oftware Architecture

CS SERIES (13)When using architecture patterns, how will you know which one to choose? Peter Wayner, an independent author for TechBeacon takes five architectures that the majority of programs today use and broke them down into their strengths and weaknesses. Through this, it seems like he is hoping to guide users to selecting the most effective software architecture pattern for their needs.

If this article does not clear up enough information, Wayner also brings up a book, Software Architecture Patterns by Mark Richards, which focuses further on architectures commonly used to organize software systems.

The fives types discussed in the article are:

  • Layered (n-tier) architecture
  • Event-driven architecture
  • Microkernel architecture
  • Microservices architecture
  • Space-based architecture

The one I found most interesting is space-based architecture because at first when I thought of space, I was thinking of the other kind. The one with the sun and the stars and the moon. But then I realized–what does that have anything to do with software architecture? Space-based architecture is listed as “best for high-volume data like click streams and user logs” and I think this one is pretty important, especially during times like Black Friday and Cyber Monday. I personally experienced the frustration of not being able to access a site (adidas) due to high volume and it really does not help a business.

Another architecture I found thought-provoking is micro-services architecture because of the way Wayner introduced the concept, “[s]oftware can be like a baby elephant: It is cute and fun when it’s little, but once it gets big, it is difficult to steer and resistant to change.” The author providing an example of this made me think about how a site with so many users and things happening at once actually just had many different separate services but they were put together as one. I was a little surprised to think of Netflix in that way after all the times I’ve used it but it makes much more sense now.

Overall, I found all of the information pretty useful and clear to understand as Wayner described what they were and then listed the caveats and what they were best for. I would recommend using this as a reference or quick review of common software architecture designs if someone needs it.

Article: https://techbeacon.com/top-5-software-architecture-patterns-how-make-right-choice

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

You don’t no smoke

For this weeks blog post I will be looking at smoke testing.

A smoke test is used to describe a suite of basic tests that verify that the major features of an application are working properly. A most common se of this is simply to determine whether a build is stable and ready for further testing or a final check before you submit something.  The result of this testing is used to decide if what you built is stable enough to proceed with even further testing. The terminology behind the name comes from a similar type of hardware testing in which the device passed the test if it did not catch fire the first time it was turned on. The testing covers most of the major functions of the software but none of them in extreme depth. The result simply is whether or not you must go deeper or not. If it fails you stop further tests and try to fix what you already have. This testing helps expose integration and other major problems early in development cycles. It can be conducted on both newly created software and enhanced software. A smoke test is almost always performed manually with some help of automation tools or scripts but if the builds are prepared frequently automated smoke testing is the best to use. After an application becomes more developed and mature in a sense with more functionality the smoke test will need to be made more expansive. Sometimes even just one incorrect character in the code could render an entire application useless. The advantages of this smoke testing expose integration issues and helps you uncover the issues early.

 

http://softwaretestingfundamentals.com/smoke-testing/

From the blog CS@Worcester – Matt&#039;s Blog by mattyd99 and used with permission of the author. All other rights reserved by the author.

Copy Pasta: Te AntiPattern

For this week’s blog post I will be taking a look at another antipattern, another very common AntiPattern that creates maintenance nightmares. It usually takes the form of several similar segments of code that are interspersed throughout the software project. Programmers who are learning how to develop software who are following the examples of more experienced developers usually fall prey to this unwillingly. They do this by modifying code that has worked for them before in a similar situation and they think by potentially customizing it to support new data types they can get by but this causes code duplication which may cause positive outcomes but long-term problems. Symptoms of this antipattern include the same software bug that reoccurs throughout the software despite local fixes, lines of code increasing but overall productivity not being affected. Essentially this antipattern re-uses code that you may or may not need adding to your lines of code without any actual assistance being provided from the length. The most common cause of this is a lack of abstraction among developers who are often accompanied by a poor understanding of inheritance, composition, and other development strategies. And is most likely to occur when people are unfamiliar with new technology or tools as a result, they take a working example of something and modify it, trying to adapt it to their specific needs. Some solutions to this involve white box reuse through the developers extending systems primarily though inheritance. On the other hand of this black box reuse has other advantages such as the object is used as-is, through a specified interface where the client is not allowed to alter how the object interface is implemented. In a way this antipattern is very similar to spaghetti code but spaghetti code is not structure for easy component reuse because of this Cut and Paste Programming is the only means available for reusing preexisting lines of code.

https://sourcemaking.com/antipatterns/cut-and-paste-programming

From the blog CS@Worcester – Matt&#039;s Blog by mattyd99 and used with permission of the author. All other rights reserved by the author.

The Joel Test: 12 Steps to Better Code

This week I read a post of Joel Spolsky, the CEO of Stack Overflow. This post talks about his sloppy test to rate the quality of a software team. The great part about it is that it takes about 3 minutes. The test form is:

“The Joel Test

  1. Do you use source control?
  2. Can you make a build in one step?
  3. Do you make daily builds?
  4. Do you have a bug database?
  5. Do you fix bugs before writing new code?
  6. Do you have an up-to-date schedule?
  7. Do you have a spec?
  8. Do programmers have quiet working conditions?
  9. Do you use the best tools money can buy?
  10. Do you have testers?
  11. Do new candidates write code during their interview?
  12. Do you do hallway usability testing?”

The Joel Test is so easy that to get a quick yes or no to each of the 12 questions. You don’t have to figure out lines-of-code-per-day or average-bugs-per-inflection-point. Give your team 1 point for each “yes” answer. However, please remember that you really shouldn’t use The Joel Test to make sure some formal or important things like your nuclear power plant software is safe. A score of 12 is perfect, 11 is tolerable, but 10 or lower and you’ve got serious problems. The truth is that most software organizations are running with a score of 2 or 3, and they need serious help, because companies like Microsoft run at 12 full-time. Certainly, these are not the only factors that determine success or failure. For example, you would not want a great software team working on a product that nobody wants. In contrast, it’s possible to imagine a team of “gunslingers” that doesn’t do any of this stuff that still manages to produce incredible software that changes the world. However, everything often has meaning itself, so, if a team gets these 12 things right, you’ll have a disciplined team that can consistently deliver.

The test addresses generally practical issues that a software team almost needs to work productively in building and testing software products that are feasible to get into market. The issues spread from tools and control to the working environment and habits for typical software team. The technology and environment have rapidly changed over time, but the issues mentioned in The Joe Test are still helpful.

Article: https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/

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

Gradle Build

Today I will be talking about Gradle! For this I will be referencing a blog on gradle called “Why Build Your Java Projects With Gradle Rather than Ant or Maven?”. This article discusses the pros and cons of building Java projects with Gradle instead of similar programs such as maven and ant. The blog starts by talking about how project builds used to be sort of a simple process that did not have to use fancy applications such as Gradle, ant, maven, or any other build program. Most requirements for builds just entailed packaging and compiling software. As mentioned in the article, as we now are seeing an increase in high tech programming and agile formatted programming, the requirements for building/compiling/packaging software is a much larger process. So why does this blog prefer gradle to another build program such as ant or maven?

One of the top reasons this article prefers gradle is because it is simple and user friendly. One big thing this article mentions is that when using build tools frustration is a common encounter while trying to use these tools. I personally have had this frustrating experience with maven about two or three semesters ago when we were using build tools in our software class. Building with maven was a giant headache and had to be done through linux, so if you happened to be one of the few who don’t primarily run linux (Yes, that is sarcasm) then you had to use a linux subenvironment in windows and run maven through there. However when you ran maven through that, it did not have access to your windows file explorer unless you mounted your C drive every time you wanted to explore files. This was a giant headache for me, and a problem I have not encountered with Gradle. Gradle can be used simply through a git bash terminal or any other terminal on your host operating system, for that matter. I personally enjoy the ease of gradle. Building with gradle is as simple as running “gradle build” on your master branch and it will build and let you know if there are any errors and what they are. You can also run html versions of your test reports to get a very detailed debugging without having to do everything in the terminal. I personally have learned a lot from using gradle and I look forward to using gradle more in the future to build my projects with ease.

Here’s the link: http://www.drdobbs.com/jvm/why-build-your-java-projects-with-gradle/240168608

From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.