This week in our Software Testing class; we were assigned the task of software technical reviewing some code that was provided by our professor. It was quite exciting since that was the first legitimate testing in a group I have done in my programming career. The concept of software technical review so fairly simple and straight to the point so it was not difficult to dissect what it was that we needed to do in order to effectively review the given code. The outline of the assignment was to first individually review the code by ourselves without discussing our results with other team members. Afterwards, you would then meet up as a whole team and discuss about what each other found in terms of errors and faults within the code. The designated recorder of the group records any changes made during the meeting and compiles together a master list of all of the members’ combined discovery.

Although the testing process itself was new and exciting, there were a couple of complaints I had. The only factor that made the assignment frustrating is that some team members did not individually review the code before the meeting. Due to this, instead of delegating time to discuss our findings, we spent most of the class time waiting for some members to look over the code so we barely had any time to actually discuss as a whole group. Besides that however, it was a fun and memorable new experience in which I learned a lot!

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.

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.

An important and on-going question that QA testers always ask is how good their test cases are. This can be measured in many ways; one way being code coverage. Code coverage is a good method to check if all parts of your code was executed; although it still would not tell much of how good your tests are even if your program has good code coverage.

An alternative to test how good your test cases are is through mutation testing. This was an interesting read for me because I had just read an article that briefly touched upon mutation testing last week so it was a cool follow-up article. Mutation testing is a technique that is used to assess how well your test cases react to faults that are intentionally injected into your code. This can be useful to evaluate how efficient your test cases can handle those faults and how it reacts to any unexpected issues.

Article: http://www.softwaretestingmagazine.com/videos/evaluating-test-cases-quality-with-mutation-testing/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+SoftwareTestingMagazine+%28Software+Testing+Magazine%29

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.

I read an article this week about which programming language hackers use (http://www.softwaretestingclub.com/profiles/blogs/which-programming-language-do-hackers-use) and while at first, I didn’t see the relationship between hacking and software testing, I came to realize that they have a good amount of similarities. Thinking more in depth about it, the act of hacking is just finding vulnerabilities in a software or program which is the same objective as QA testers (although the intents may be different).

Something interesting about the article was that when asked, “what programming language do hackers use”, the answer given by an expert hacker Adrian Lamo was totally not what I was expecting. He responded that he does not use a programming language which caught me off-guard because I didn’t think it was even possible to hack / test without the use of a programming language. The most memorable and significant piece of information I got out of this article was when Adrian Lamo further explains his answer by saying that its more important to learn how to read code rather than learning how to code. By learning how to efficiently read code, you can dissect how programmers think, what their tendencies are, and what common mistakes they make which can give you a better idea of what to test.

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.

I read an article this week entitled “How to Write a Test Case Structured for Your Project and Your Team” (http://blog.testlio.com/how-to-write-a-test-case-structured-for-your-project-and-your-team) which at first I did not find fascinating because as Computer Science majors, most of us should already be familiar with the general structure of test cases. However, despite the initial lack of interest I gave the article a chance and skimmed through its content and it turns out that there were some interesting test case structures that I have never heard or though of before.

One in particular that caught my attention was the “Verify-using-with-to test cases”. The article outlines the type of user of this structure to be beginning testers or employees (which is basically us once we graduate!) This test style can be applied to projects or any magnitude and is mainly focused on the actual language of the tests. The reason for the naming of this structure is because it follows the 4 key words: verify, using, with, and to. Instead of going into the definition of these 4 key terms, the example used in the article is this.

Verify: Courses send to bookstore
Using: Student ID, “Look up books”
With: Student is registered in at least one course
To: Show student courses list in student bookstore

After reading the article and going over the examples provided, I did find this particular test structure to be not only useful, but pretty easy to use so it’s something I look forward to using the next time I test!

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.

We as humans are naturally built to adapt to changes. One of which includes the adoption of new forms of testing techniques for program testing. In today’s modern technological society, you would be crazy not to take advantage of the various benefits automation testing has to offer. Like, why do the testing by hand when you can have a computer do it for you?

I read an article this week that addressed that very same question; why do we need manual testing? The article entitled “13 Reasons Why Manual Testing Can Never Be Replaced” (http://blog.testlio.com/13-reasons-why-manual-testing-can-never-be-replaced) sheds some light on why manual testing should still be a relevant and significant form of testing. Out of the 13 reasons that were mentioned, there were particular ones that stuck out to me. One reason was that “bugs are found where you least expect them” meaning that by manually testing, you may find bugs you weren’t intentionally trying to find which can’t be done with automation testing because it can’t catch issues that the testers themselves, are unaware of. I found this quite refreshing because its true; tests cases can’t exceed the scope the developer intended it to have. Another reason I found to be interesting is that “mobile devices have complicated test cases”. This is something that can quickly become a nuisance because while an automated test case may take a while to program and create, manual testing for that same test case may take much less time and effort. So while new technological developments are progressive and useful, sometimes you just got do things old school.

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.