Category Archives: CS-443


The article Test Case Design Techniques to Ensure High-quality Software on ReQtest brings up the three major categories test design techniques are generally classified into. These techniques are specification-based, structure-based, and experience-based. Each of these techniques covers different testing methods we covered in CS-443, especially structure- and specification-based techniques.

Specification-based techniques are also referred to as black-box techniques, which should give you some idea of what kind of testing this category covers. Testing techniques under this category are generally written to the technical specifications and client’s requirements. These testing techniques rely more on an understanding of what a program’s intended functions are, and what different states it can find itself in performing those functions. The actual structure of the code is not considered. Using specification-based testing, you can verify that your program works the way it was intended and is written to specification.

Structure-based techniques are conversely referred to as white-box techniques. As expected by the name, these testing techniques test the actual code that is written, and requires knowledge of the code and its internal structure. Many of the testing techniques of this type involving changing conditions and values and making sure code works in multiple cases, validating each branch of the code. Structure-based techniques help highlight any glaring structural or logical issues within your code you may have overlooked.

The final category is experience-based techniques. This category is pretty broad, mostly involving techniques that rely on prior knowledge or information that couldn’t be gained just from testing. This is the type of testing you just can’t plan for. However, the more you test, the more you can apply knowledge from previous tests to fix issues before they become back-breaking.

Dividing the testing into different categories makes their usefulness easier to understand. Structure-based techniques are more difficult and require more knowledge, but are exhaustive and effective at finding issues in the code. Specification-based techniques verify that the parts of your code that matter are functioning correctly. Experience-based testing simply leverages your knowledge of an area to improve testing. All these techniques have valid uses in the world of testing.

From the blog CS@Worcester – Let's Get TechNICKal by technickal4 and used with permission of the author. All other rights reserved by the author.

Testing Gone Wrong

In his post Six Things That Go Wrong With Discussions About Testing, James Bach lists six different things that can often go wrong when testers are discussing testings. His six reasons can be summarized as testers misunderstanding the purposes of testing and not following the proper procedure when it comes to testing.

Your goal when testing is to discover any vulnerabilities in your program, but also to find strengths and things your program is doing well. This covers James’ first two points. When it comes to testing, quality is much more important than quantity. It is better to have a more complete coverage of your program and all its branches than to have a bunch of tests doing the same thing and missing different parts of your program. This is why it is important to think of tests as events instead. What is important is what your test is testing and how it goes about that, and it shouldn’t be thought of as some ‘Generic X Test.’

Often times people get carried away with automated testing and rely too much on it. While it is good to use automated testing, developers have strength far beyond that, and should use automated tests as tools to better accomplish effective testing, not as automated workers that do your work for you. Thinking of automated tests in this way also distracts from the purpose of testing, and makes it easier to forget why you should run certain tests in the first place.

James’ last point is probably his most important one. Testing isn’t just some set task that can be navigated a certain way every time. What I’ve learned this year is that testing is about thinking critically about a program and the way it COULD act, and design your tests according to those parameters. Consider where things can go wrong, and try to test the strength of weak parts of your code. But most importantly, be ready to learn, as every program has a different set of tests with a different strategy that is most effective for testing. Testing is a dynamic thing, and testers must be dynamic people.

From the blog CS@Worcester – Let's Get TechNICKal by technickal4 and used with permission of the author. All other rights reserved by the author.

The Value of Testing

The blog post How Do I Know My Tests Add Value? by AutomationPanda discusses the value of proper testing. The author brings up the common issues that sprout from use a bug-fixed count as a metric for successful testing, and highlights why testing is important and can help improve development.

Testing is important because it validates that your program is working as it is expected to. Well-written tests with the proper amount of coverage give you information about your program and whether any changes need to be made. A passing test indicates correctness and that your program is working as expected. A failing test points out a bug that needs to be fixed and helps highlight weak parts of your code.

The absence of testing might not necessarily lead to bugs, but we all know as programmers that even when it seems your code is running exactly as you intended it to, logic errors can happen and sometimes things weren’t written with every situation in mind. When testing is in being implemented, developers are accountable for the code they write, and must think carefully about the issues that may arise.

Tracking bugs isn’t necessarily effective because it encourages testers to find issues even when there may not be any. All tests passing is still good news and a sign of progress, even if it just means you are doing everything right. Enforcing bug quotas and forcing testers to find issues means they will expend effort looking for things that aren’t there and nitpicking small issues rather than writing more tests or making sure they have good coverage, which are far more effective and finding issues in your code.

At the end of his post, the author suggests some different metrics to use: time-to-bug discovery, coverage, and test failure proportions. All of these serve as much more accurate and effective measures of determining whether your testing has value. Whatever metric you use, it is important to think about why you are testing and whether you are doing it in a way that tells you something about your program.

From the blog CS@Worcester – Let's Get TechNICKal by technickal4 and used with permission of the author. All other rights reserved by the author.

An Introduction to Code Reviews

In my Software Quality Assurance & Testing class, we recently did a group-based code review of a simple Sir Tommy Solitaire program that my professor wrote a few years ago. It was a really fun and interesting group activity that I enjoyed quite a bit, so I decided to look more into common Code Review practices to get a better understanding of how to conduct them in a better way. This article written by Trisha Gee I found on was a great resource for learning more about them.

First and foremost, the most important thing to remember when conducting code reviews is that your job is to view the code within the parameters of the project you’re working on. For example, if your company uses Checkstyle and prefers Google Java Conventions vs Sun Code Conventions, then the team must keep that in mind when reviewing code. All reviews must be viewed through a lens that corresponds with the vision of the project at hand.

When you’re actually conducting the review, what are the easiest things to look for? The article from DZone mentioned these four topics:

  • Formatting: Things line curly braces, spacing, line breaks. 
  • Style: Is the code laid out in a logical way (variable declarations near their usage, etc.)
  • Naming: Are naming conventions upheld throughout the program? Are they descriptive enough?
  • Test Coverage: Are there tests that cover the code and what it interacts with?

However, there are plenty of tools that exist to mitigate the potential errors which come from these easily spotted issues. Humans aren’t so great at noticing minute details — something that machines are perfect for. Formatting tools like Checkstyle that I referred to earlier will usually ensure that formatting standards are upheld, and tools like JaCoCo can assist test coverage (we’ve used both of these in class and it’s remarkable how helpful they are).

Really, the job of the reviewer is to focus more on the design choices and quality of the code. Not only should the code run, but it should be readable, maintainable, it should be written with good design principles in mind. Are any parts reused, are design patterns used in elegant ways or do they needlessly increase complexity?

I haven’t quite yet read through all of Clean Code by “Uncle Bob”, but from what I know it seems like many of the principles in that book are ones that should be deeply considered when conducting a code review. I think anyone looking for further elaboration on the topic of Code Reviews should read both the article I found on DZone (and other DZone material, frankly), and Clean Code — it’s as popular as it is for a reason.

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

Post #8: Cross Browser Testing

Hello and welcome back to Benderson’s Blog, this week we are going to take a look into cross browser testing using a technique that is talked about in a Software Testing Class blog. You can check out the link to the full blog at the bottom of the blog if you want to learn more about it. There are some pre-requisites to perform cross browser testing, they are selecting the number of browsers and the proper browser OS device combination, check for browser incompatibility for the browsers and lastly fix the issues and perform regression testing. If you have all those boxes checked that you are good to go in cross browser testing.

Now that you have checked all the pre-requisites you got to select a browser and operating system combination. To figure out what combination you should use, you can use analytic tools or you could create a testing matrix which is described in the blog by Software Testing Class. Now that you have a combination you can use LambdaTest to exectue cross browser testing wiht your website. There is a list of combinations you can use also in the blog that will be helpful for you to be able to begin cross browser testing your website. At the end of testing you hit the end button to end the testing session, you can also hit the switch feature to change configuration without ending the session you’re in. Lastly, you got to fix the bugs you find in your website after cross browser testing and just get assured and you’ll be set.

The reason I chose this blog is not only because the course I’m taking is about testing and this is a testing blog but it did seem interesting to me considering a goal of mine is to actually make a website that is successful. To have my own successful website, I need to be able to test my website for bug and being able to cross browser test my website would be a great tool to have on my belt for when my goal is achieved. The browser that I would use to test it would probably be Google Chrome because I’m so used to it but I would probably find another browser that is better if I actually had a website to test on. In the blog they discuss actually that Google Chrome and other browsers like Mozilla Firefox use a lot of space and may not be that good for cross browser testing so I might have to figure something else out. The other cool thing about this blog is when they discuss using LambdaTest to execute the cross browser testing. There were many combinations that someone could use to execute the LambdaTest and they give you steps on what to do such as “Start running cross compatiblity tests of your webstie” and “capture screenshots if a bug is detected”. Which is helpful for someone who hasn’t done any cross browser testing. Well thank you for joining me this week on Benderson’s blog, see you next time!



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

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.

Be Lean Don’t Unit Test

Eugen Kiss writes in his blog about some of the disadvantages of unit testing and offers an alternative to unit testing which is lean testing. His focus is about “return on investment” of using lean testing over unit testing. Basically the focus on what is being returned for the work of unit testing. The argument is that you put resources into creating a unit test for one specific outcome when lean create end to end testing that covers the critical paths that the user would actually take.

He continues to say that the problem with unit testing is inherently in coverage. The argument is made that even with 100 percent coverage the code may cover zero. Since you create code to match that of what you expect the result can be different from the user path that is actually followed. Additionally another issue he brings up is the quality of the tests “Imagine you have three components, A, B and C. You have written an extensive unit test suite to test them. Later on you decide to refactor the architecture so that functionality of B will be split among A and C. You now have two new components with different interfaces. All the unit tests are suddenly rendered useless. Some test code may be reused but all in all the entire test suite has to be rewritten.” This would cause a come back turn around where since you are rewriting the tests you are investing more time into unit testing costing more to “payback”. Finally another point of cost efficiency is when actually designing your code. You are coding with the tests in mind, and potentially making code that you don’t need to fulfill the tests.

The blog offers incite that unit testing isn’t always the best use of time and suggests that time can be better spent focusing on user interface.

From the blog CS@Worcester – Computing Finn by computingfinn 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!


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.


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