My blog today is on this article in which the author is talking about what she believes are the goals that software testers should have when working on projects. Right off the bat the author points out that a tester should clearly be trying to find bugs but she also points out that a tester should try to prevent bugs as well. I agree with the way that the author points this out because if a bug can be found in a certain area in a program, the developer probably used the same logic in other places throughout the program. This means that finding that one bug could mean that you have found some flaw in the logic of certain parts of the entire program and should check to see this other possible areas affected by this flawed logic. The author also makes a point that a testers job also includes being able to assess the overall quality of the program, since they are the ones testing it, they should have one of the better understandings on whether it is ready to be delivered or not. I agree with this in the fact that a tester will know the current state of the program, however the tester does not know the full scope of the program or what could still need to be added to it. Another important point the author brings up is to not be afraid to say something about difficulties in the programs usability. Essentially, the author is saying It is worth delaying the release of the program to users if it increases the usability of said program for users. This is an idea that I personally think should be used more in most programs being released, bugs and other difficulties for users at launch create a negative feeling/connotation towards the program/developer, so it is worth delaying a little bit to alleviate these feelings of the customers. In the end it is better for business for these companies if they focus more on testing and quality before release.

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

My blog today is on this article which talks about some things that a person should consider before starting testing on a program, a sort of checklist to complete before testing. The first thing the author points out is understanding the idea/concept that the client has as in mind as well as understanding the scope of the audience for the program. This is similar to being assigned a project, the first thing I try to do is fully read through and understand the project at hand. If the program is one for something like a bank, then the functionality and worst case testing takes priority, while a program for something like social media would be more focused on aesthetics and testing on different platforms/devices. Once you understand the needs of the client you can start crafting your testing strategy, where you start addressing what kind of testing is applicable to the program that is being tested. The author points out that it is generally inevitable that during testing several testing tools may need to be used, giving the example of how simulating stress/load testing can be very difficult especially if trying to do it with just one machine. Once a test strategy and plan have been setup, you have to then begin planning on how long each phase of testing may take you and to also develop plans for if complications during testing makes it take longer then expected. I agree with the author on this point with it being very important to budget time on a project to prioritize and finish more important aspects the project(or testing) first and then move on to more minimal items. With all of these items on the “checklist” having been thought about, it is time for the actual test plan document to be created. One thing the author brings up in this is there is a standard for these test plans, called “IEEE892 Standard”. After researching this standard I found is a series of 8 documents that fully outlines all the aspects of the testing plan for a program, including items to be tested/not tested, test deliverables, and environmental needs.

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

Link To Article

In this article, the author is talking about steps to take to actually reduce software defects in programs before release through several steps. The first step seems kind of obvious for a goal but nonetheless it is to stop believing that you can’t put out a program that doesn’t have defects. Defects are nothing more than simple mistakes that could have been avoided but were not, of which these bugs could be trivial or system breaking. So instead of believing that these programs are bound to release with problems and defects, aim to write your programs without any defects. Another thing the author points out is if you are given code to test, not to simply point the finger at the developer of the code being lazy. The people writing the code are not simply trying to skimp on their end to save their time. Instead they are often overworked and simply could have missed something. It is also explained in the article that often the first thing to be done for reducing defects is to develop unit test coverage. However, although this unit test coverage could cover most of the program, it could be ineffective. Something the author points out in his article is the concept of “bug bash” which doesn’t seem like in the end it would be very productive. It is the idea where a team takes the software and tries to break it, and then repair it. While this may provide more knowledge of the software, it seems this kind of practice would be a focusing too much on the knowledge of the software instead of getting a product out to clients. Finally, some of the things that are pointed out in the article is to try to avoid tendencies that will lead to errors in the first place. These sort of tendencies could be things such as when copy and pasting from files, missing some small statement, or could be having files that may be too complex, leading to inattention errors.  

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

Link to Article

This article is about a software tester who is trying to help those new to the field to avoid some mistakes that he has experienced in his career. Some of these mistakes and pitfalls that the author highlights are things like running out of test ideas for a project, missing simple little mistakes, self doubt about issues in the program, and the priority of what to test in a program. For each of these mistakes that an inexperienced tester can run into, the author gives a few examples of what someone can do to in such a situation. One thing the author mentions is when you may be lost on what the testing goal is to ask plenty of relevant questions to help you understand. It is better to admit you’re not clear about something in the project and ask for clarification about it, then to be ignorant of that actual goal. I agree with the author as well on his point about a testers self doubt about a bug they think they have found but are uncertain. In this situation, the author suggests a practice I personally use as well; take a break from the project and come back with a “fresh set of eyes”. This break from the testing gives you time to clear your mind and come back to the project with a new focus. One thing that I learned from this author was the concept of BCA(Brute Cause Analysis) in which two people work together, with one person brainstorming possible bugs and the other thinking about the different ways those bugs could manifest. This can be a very good idea because it is always helpful to be able to see a problem(or bug) from another person’s perspective. One final thing that the author suggests is to trust in your gut when you think you may have found a bug but are not sure. In the worst case you simply find out that it could have been something you did wrong, or in the better case your gut could have payed off.

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

My blog this week is about an article which talks about things that could possibly go wrong while discussing about testing and how someone could improve their testing. In the article, the author points out several flaws which many testers tend to make. Some of these mistakes testers make include things such as caring about how many tests there are instead of the quality of the tests, how many people have a hard time adapting to creating new tests as a test case evolves and when people believe there is only one way to test something.

I thought the author had a lot of good reasoning behind his thoughts on testers, which can be applied to more than just testers too. This applies especially to his first point which pertains to when people care more about the volume of test cases they have written versus the quality of those test cases. The author’s point, which I agree with, is that it does not matter how many test cases you write, if they do nothing to actually test the code, than they are completely useless. This thought also makes me want to pay more attention to the test’s that I write to make sure that they are effective and proper to what I am actually testing for. Another comment the author made which makes me want to look more at the way that I move through testing is that many people have a hard time adapting their tests as the strategy of said tests changes. Being able to change and adapt your tests as the test strategy changes shows a true understanding of the purpose of the testing that is happening. Finally the author brings up the point that people often have the thought that if they are testing something one way, they have tested that thing fully. However, if they run the same test with a different data set they could discover some new bug that you would not have seen before. This is another good example by the author of pointing out a flaw that many people can and tend to make, and one that I plan to focus more on myself.

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

My blog this week will be based on this article that argues that a certain form of testing, “lean testing”, is far more helpful than something like normal unit testing and test driven development. The author goes on to explain their way of testing, “lean testing”, is essentially focusing on different kinds of tests then unit tests which will be more beneficial with the finite amount of time you may have to get certain projects done. With unit testing, you tend to test bounds of the program that will affect very few users and it is better to focus the tests on more real world scenarios that a user might encounter.

I feel the author raises a good point in this testing, to focus tests more on what a user of a program will likely run into rather then on the bounds of the program which very few to no users will encounter. With that though, I do still feel it is important to at least include some tests to make sure the bounds of a program are working and will notify the user of such. Another thing that the author included was the three dimensions they think best help to follow in testing and that is speed, cost, and the most important one; confidence. This quote from the article which I feel reflects what the author is trying to make clear in the article is from Kent C. Dodds, who said “The more your tests resemble the way your software is used, the more confidence they can give you”. The author also provides another reasoning for this testing of what the user is more likely to encounter when using the program, and that is that testing those cases tend to cover more of the code then something such as boundary testing. One final point that the author brings up that I think helps reinforce their way of “lean testing”, is that unit test code is often not resilient to code changes. While some of the test code may be reusable, most of it is often not.

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

My blog this week is based upon this article in which the author explores “shift left testing” which is simply a fancy way of testing earliest in the production of a program as possible. In this article the author goes into detail about several different forms of shift left testing, all of which try to push the testing earlier into the development of a program. The author also reviews why the common practice of testing late in production phase has been a major harm to system and software testing.

I found it interesting that the testing phase is often left so late in the development, with some major consequences pointed out by the author. One of these consequences the author highlights about this method is that it often results in “wasted time”. This can happen because “Many requirements, architecture, and design defects are not uncovered and fixed until after significant effort has been wasted on their implementation.” This article also focuses on what I feel is a much better approach to the development in which each part of the original “V-model” of production is broken into separate “V-models”. This means that for every part of the production phase, whether it be design, coding, fabrication, it is accompanied by a testing phase. This does require more time in the production but will ultimately produce a better program with fewer to no faults. I believe employing this strategy in one’s own personal work would be a very smart idea. This can be done for example while creating a program yourself, with every part of the program you write, you test it to make sure it is correct. This will help by the end of the program when you could generally have several mistakes causing errors throughout the program. One final thing the author points out which I believe could be relevant to those not employing this method is that late testing can lead to missed deadlines, whether it be for a company or for a student working on a project.

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

My blog this week is based on this article which talks about the author philosophy behind debugging and how people often fail to debug properly. One of the first things the author talks about is how it is important to once presented with a program to debug, the best thing to do is know and admit that you do not know the answer immediately to whatever problem there is. He says this to follow up with the importance of gathering the information about the problem that will help much more then just simply trying to “guess” a solution. One other important point that the author made in this article is that most programmers tend to try to find a “bandage” for the bug they are presented with. The author believes if someone debugs a program properly “you’ve actually caused some part of the system to go away, become simpler, have better design, etc. as part of your fix”.
I personally found the authors advice of trying to understand the problem further before even attempting to create a fix to be very helpful. Looking at how I’ve done things in the past I know that I would often simply try different things to come to a fix for a problem. One way the author suggests to help fix this is to gather data about the bug until you fully understand the cause of the bug in the first place. You can do this by trying to recreate the bug for yourself to see the cause of the issue, or try referring to the way a proper program should behave. Another point I took away from this article was that when you are debugging something you should be eliminating code to make the program simpler and better in design. Often times you can think the proper way to fix a problem is to add something to the code to handle whatever problem is occurring, when you should rather be making the code simpler to begin with. I feel this is a very smart way to code/debug because anytime you can make the code of a program simpler, yet act in the same way, is good for both other programmers to look at in the future and for the users of the program itself.

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

I would like to start off with saying thank you for viewing my blog. The second of two blogs on this site that will be for my class at Worcester State University, CS-443, Software Quality Assurance and Testing.

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

I would like to start off with saying thank you for viewing my blog. One of two blogs on this site will be for my class at Worcester State University, CS-343, Software construction, Design, and Architecture.

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