Hello, My name is Jonathan Paiz. I am a student at Worcester State university and am studying to be a computer scientist. On this site, i will be posting blogs about software testing, and what we are being taught in class.
From the blog CS@Worcester – Site Title by jonathanpaizblog and used with permission of the author. All other rights reserved by the author.
I have been doing some reading on different testing techniques and will briefly go over a few of them here this week. The first is pair testing. I had never heard of this before, but the concept is rather simple, which I will quote from the blog. “If you have an idea, give your keyboard to your pair and explain what you want to do.”, so basically you pair up with someone and one of you outlines what the test needs to do and the idea behind it and the other person writes and performs the tests and vice versa. I think that this could definitely be useful in certain circumstances. I often have ideas on things and how I would like to do them but sometimes find it hard to actually get it out and end up getting insight on how to do it from a friend or colleague.
Next up on the list is test driven development. This concept seems to me to be an effective testing technique. If you can come up with tests for what you want to build it can make it easier to actually build in a sense. I have barely scratched the surface of this methodology, but am looking forward to learning more about it. In the introduction the writer described two rules. 1. Write a failing automated test before writing any code. 2. Remove duplication. How to use those two rules is the narative of the book and I cannot wait to dig in farther and keep you updated as I progress through the book, Test Driven Development: By Example.
A Haiku by Amanda Shankle-Knowlton I thought was pretty good that to me makes sense.
I will work through lunch
Stay late, tracking down a bug
Just to hear “good catch”
The last testing strategy I would like to learn more about is Oblique Testing. Apparently the concept was used by a music producer to make artists try something new. The testing method provides a set of cards that are based on fictional reviews for the application. The method is mainly using mobile apps, but can be used in other applications as well. The full software dev team is also involved and not just the testers. This seems like an interesting take on testing that I will definitely be gaining more insight on in the future.
The following are links to the blogs or titles of books.
Test Driven Development:
Test Driven Development: by example, by Kent Beck.
From the blog format c: /s by c-braley and used with permission of the author. All other rights reserved by the author.
Serverless architectures: game-changer or a recycled fad? by Gojko Adzic.
This article discusses something that i had not necessarily heard of before this point, or at least not in a formal sense, “serverless architectures”. Much like noSQL databases the name can be a bit misleading, meaning that there are in fact servers involved, perhaps even more than a normal “server architecture”. Serverless actually refers to the fact that you do not have to maintain your own server hardware, nor do you have to rent racks at a traditional data center.
In order to understand why this new idea is such a big deal i will attempt to explain the more traditional architecture, from there i can elaborate on the incentives of going “serverless”. Gojko talks about the most important thing when considering server architecture is “keeping the hardware busy”. This was to get the most bang for their buck in a way. In order to accomplish this they would bundle a number of processes together to make the most out of the hardware. Of course this meant at some points bundling things that shouldn’t necessarily be bundled for purely financial reasons. He goes on to discuss how the introduction of cloud computing did not address this issue and the need to bundle remained the same. This caused situations where you could have a bug in a rarely used process that was bundled with more important ones, and that bug caused every one to be held up.
The “serverless” architecture changed all of that. The idea is based on the “container farm idea”. Although i am still working to completely understand the implementation the financial aspects are quite obvious. Instead of reserving computing capacity you only need to pay for the time that a process spends executing. This means that it doesn’t matter if a process is rarely executed since we only pay when it does, instead of having to allocate space for that process regardless. Which then means that there is no need top bundle eliminating a large deal of the headaches that go along with that.
It was quite an interesting article and i suggest it to anyone who may even be slightly interested, the author does an amazing job of explaining the technical details.
Other Interesting Articles:
From the blog CS@Worcester – Computer Science Journal by jtassone93 and used with permission of the author. All other rights reserved by the author.
More and more devices are now having the ability to connect to the Internet. With all of these devices testing is becoming more and more abundant. In order to test all these applications coming from all of these new devices, test automation is something that should try to be implemented as quickly as possible. With test automation on these devices, users will potentially experience less bugs and down time.
From the blog CS@Worcester – Software Testing by kyleottblog and used with permission of the author. All other rights reserved by the author.
While looking through a few blogs and websites I came across an interesting post. This post discusses the idea that there is not a specific way to analyze the amount of time the testing process takes, and tries to elaborate on some helpful tactics. The post is written by Lee Copeland and Matthew Heusser.
Within every company there are thousands of variables that can possibly change the necessary amount of time testing will take. Estimating this time is a big challenge for the team because management will always want a finite time. But not many people can look into the future and see what will go wrong. For all of the rest of us we have estimations. In the article they detail some of the big factors that can influence this estimation.
In the blog post they elaborate on some of the techniques that can help narrow the window of estimation time. Some techniques listed include:
- Gathering more data
- Getting to know the team you are working with
- Knowing the stability of the requirements
- Knowing the size and complexity of the system
The more data of past projects you have the easier your estimation will be. Knowing your team will make it easier to know the realities of the effort to time ratio. Knowing the stability of the requirements and the size of the system will allow a more accurate estimation of bugs in the project. In the post they mention an evidence-based scheduling method by Joel Spolsky.
My favorite part of the post is the closing line stating “perhaps we would be better off investing the time we would spend estimating, in doing the testing instead”. I think this is a very interesting way to say that estimation is sometimes pointless.
For more information click here to read the full post.
From the blog CS@Worcester – Conundrums In Computing by patrickgrahamblog and used with permission of the author. All other rights reserved by the author.
Platform-led Testing by Lakshminarasimhan Rajabather
In this article, Rajabather goes over the positives of using platform-led testing to help with automation across all the stages of the software development life cycle. The first advantage that he lists for using this approach is that it cuts down on the cost and time to use assurance across the development’s life cycle. This is also positive to businesses since their goal is to minimize cost and time, and maximize quality.
Rajabather points out is that platform-led testing makes sure that the software is constantly being checked and validated at every stage of development. This is able to be done because, as previously stated, it is now possible to have software assurance constantly being implemented through the entire life cycle. Platform-led testing also works well with Agile development because it “promises quick sprints, rapid sign-offs and a measurable transfer of value from one sprint to the next.”
The last two advantages of platforms that Rajabather lists show that they are beneficial to businesses. He states that platforms allow businesses to build upon both industry and third party analytical tools which makes it so that the tools can be customized to fit a certain need. The last benefit is that platforms are not “restricted only to the requirements, design or execution stage of the lifecycle.”
Please read the full article for more information on this subject.
From the blog CS WSU – Techni-Cat by clamberthutchinson and used with permission of the author. All other rights reserved by the author.
This week I was reading a book call Learn Git in a Month of Lunches by Umali. The book was very good in explaining how Git works and is written in a very easy to understand way. My understanding of Git has improved by a lot after reading this book. I would recommend this book to anyone who wants to understand Git.
From the blog Software Testing – The blog about software by MegaMind and used with permission of the author. All other rights reserved by the author.