Bug Hunting

There is many ways to go about looking for bugs, defects present in the software,  obstructing the program from its desired performance.  The presence of the bug decreases the quality of the software. While we build test cases to catch these bugs, you need to make sure you are exploring beyond just what the rules are. Since it is impossible to be 100% bug free, a good tester would know to not always stick with the test strategy and blindly follow it, it might make you unintentionally blind to the real problems. Another thing to do is to keep monitoring the bug catching mechanism, with old tests even helping out. Unless you have prior knowledge of the software, you will not be good at testing it, or be able to gather requirements which is a must for test cases. So instead of waiting for requirements, you could test wrong and inappropriate things to see if the software is producing the right output or not. And even after you have thought that you might have fixed a bug successfully, don’t be happy just yet, note it down because it could become a problem in your code once again, just to come back to bother you again. And testing these bugs more deeply can even reveal more harmful bugs that you didn’t know about before. Most of all, always bug hunt with someone else so they can catch the flaws that you overlook in your own code.

From the blog CS@worcester – CS Blog by Gautam by csblogbyg and used with permission of the author. All other rights reserved by the author.

Posted in CS@Worcester | Comments Off on Bug Hunting

Video Game Testing

For any game, game testing is one of the most important steps. No matter how well a game, a game cannot be good without being thoroughly tested. Expert-level testing is of the highest importance. So while testing, watch out for game authentication challenges (bugs in their authentication modules). This could cause game breaking issues like the game forgetting what data you last saved and having everything vanish in front of your eyes. More problems could be made better by picking the right game engine. With so many engines available pretty much everywhere, it is hard for people to decide, but the best option will be the one that you feel most comfortable working on, the one you are most trained and ready to test. One of the major thoughts going into game testing would be knowing if your game can withstand a heavy, concurrent load or not. Load testing is important before the product’s launch. Your game should be tested to withstand real-time concurrent load, it should be done to achieve consistent performance across all the hardware and software on the platform.

From the blog CS@worcester – CS Blog by Gautam by csblogbyg and used with permission of the author. All other rights reserved by the author.

Posted in CS@Worcester | Comments Off on Video Game Testing

Testing Traps

A blog I read about some software testing traps was pretty interesting. It talked about some common testing traps and how you might be able to overcome them. One of these problems could just end up being tester’s block syndrome, when you just run out of ideas for things to test, making you unable to find bugs. One good way to overcome this is by testing with someone else so they can bounce ideas off of you, when you don’t have any left. Another problem you can run into is when you are so deeply invested in the testing checklist, you fail to notice the small, obvious bugs. Stop following the test cases blindly and try to explore related areas even though they aren’t mentioned and keep your eye open for whatever is happening during test execution. And lastly, sometimes you might come across some issues that you don’t report as bugs or defects because it might not actually be a bug, just something you did wrong, and now it is a problem. The way to overcome this is by letting a pair of fresh eyes look at it. Take a short break and come back to the code, reset and look at it again, to make sure if it is really a bug or not.

From the blog CS@worcester – CS Blog by Gautam by csblogbyg and used with permission of the author. All other rights reserved by the author.

Posted in CS@Worcester | Comments Off on Testing Traps

Software Project

I figured that I would start a blog about my software development project that I am doing in coordination with another classmate. I have to say that I was very excited about this because up until now, aside from a few projects of my own (small to say the least), I have never been involved in really working with someone to create something from idea to release. The finished product will not be complete by the time it is due but we will continue after classes end to complete it. We are using the agile development process for the project which is nice because we don’t necessarily have to have the whole project complete all at once, but instead base it upon what is important based upon the client’s need and timeframe.
On to the project. We are creating a web application called Web Hall Pass which is based on a program a teacher at Leicester high school developed in Visual basic, but wanted it redone in a different language so it could be used on a server. What the program does is allow students to check out to the bathroom, principal, gym, nurse, etc. and generate a hall pass either by printing it or the student can take a picture with their phone via the program which is running on a computer in the classroom. This is good in that the student can get up and check out when he/she needs to go somewhere without interrupting the teacher mid class.
After discussion we chose a PHP web framework called Laravel that uses the Model View Controller (MVC) architectural pattern. There are some challenges because neither of us have ever used this before so a lot of reading and doing tutorials was a necessity. Once we got the basics down, working with the framework didn’t seem as intimidating. The great thing about Laravel is the ease of creating tables, and html pages(blades) and how seamless the integration is between the framework and the database. You run commands using PHP artisan to create models, controllers, migrations and too much to discuss here. That being said we have barely scratched the surface of what is capable. The nice thing about it is that it takes away the daunting tasks that you face in just using PHP alone. Validation, security, authorization and more is already taken into account with Laravel, where as in PHP you have to write all of that.

The main thing I think that I see with web frameworks is that they allow you to go from idea to release faster than ever, and as we all know time is of the essence.

From the blog format c: /s by c-braley and used with permission of the author. All other rights reserved by the author.

Posted in CS@Worcester | Comments Off on Software Project

Deadly Linux Commands

When it comes to Linux, I would say I know the overall basics of how it is ran, operated and how to use it but I certainly am not a professional of knowing the more advanced commands and functions that Linux has to offer. Knowing that Linux is a very useful OS, especially for programmers, I wanted to know a little bit more about its commands. I was browsing through a couple of sites, blogs and articles and there was one that immediately catch my attention. The title of the article was “Deadly Commands on Linux” (http://www.softwaretestingclub.com/profiles/blogs/deadly-commands-on-linux) and it talked about 6 commands that are dangerous in the sense that it could completely wipe out your system if it is unintentionally (or intentionally) used. To briefly demonstrate just how dangerous these commands could be, there is a command rm -rf / – that will delete any specific file on a hard drive and all connected devices or if you want, delete all the files on a hard drive and connected devices. That’s not even the worst part; the worst part about this command is that it does not even ask you if you are sure about deleting those files, it will do it without prompting you about it. To be honest, I thought that command was pretty cool but on the other hand, I’m just thinking to myself “Why would you even have a command like that in the first place…”. But hey, after reading this article, at least now I know which commands to avoid when working with Linux!

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

Posted in CS@Worcester, Software Testing | Comments Off on Deadly Linux Commands

Exploratory Testing

This week I was reading a book by James A. Whittaker called Exploratory Software Testing. The book, obviously, is about exploratory software testing.

The second chapter starts with a quote by Alan J. Perlis: There are two ways to write error-free programs: only the third one works. Basically he means that there is no way to write error free programs!

So if there is no way to write error free programs, is there a way to prevent bugs in programs? He goes on to discuss that all bug prevention techniques are generally developer-oriented like writing better specs, performing code reviews, running static analysis tools and performing unit tests. He argues that all of these techniques suffer from some fundamental issues: the “developer makes the worst tester” problem, the “software at rest” problem, and the “no data” problem. The “software at rest” problem brings to light the fact that code reviews and static analysis techniques try to test programs when there are at rest (not running). The problem with this approach is that most bugs only surface when they are running. What is the point of testing software when you cannot identify bugs?

The author goes on to argue that manual testing is more powerful than automated testing. Manual test techniques like exploratory testing allows the full power of the human brain to be used on finding bugs. This chapter is a prelude to the rest of the book which discusses the methods and wisdom used for exploratory testing.

From the blog Software Testing – The blog about software by Sudarshan and used with permission of the author. All other rights reserved by the author.

Posted in Software Testing | Comments Off on Exploratory Testing

Why You Should Be Writing Descriptive Test Names

A non descriptive test name will cause anyone unfamiliar with the tests to be forced to read through the whole test code to figure out what is actually being tested. An example of this coming from the article is this code along with the test name:

@Test public void isUserLockedOut_invalidLogin() {
  authenticator.authenticate(username, invalidPassword);

  authenticator.authenticate(username, invalidPassword);

  authenticator.authenticate(username, invalidPassword);

Looking at this test the test name “isUserLockedOut_invalidLogin” is not descriptive enough considering what the test does. This causes us to have to look through the code and figure out that it locks the user out after 3 failed login attempts. A more appropriate test name would be “isUserLockedOut_lockOutUserAfterThreeInvalidLoginAttempts”. This test name tells us exactly whats going on and having to read through the code is not needed. The scenario and the expected outcome should be in the test name. This will save many hours by just having to read the test name instead of reading through code to figure out what the test is doing.


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

Posted in CS@Worcester | Comments Off on Why You Should Be Writing Descriptive Test Names