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.
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.
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.
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.
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.
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.
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.
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.