(Picture was taken from a google search url here )

Scanning through the blog posts on the Ministry of testing I came across an interesting post title Evolution is hard – Testing is Evolving. I read a post about how testing is evolving from Manual to Automatic and if this trend will continue to eliminate the need for testers. This blog led me to a blog post discussing pros and cons of both (oddly enough the post has the same name as this one. I promise that was a coincident) First post here. Second post here. This post will try to sum up these two posts. I really suggest you read both post because they were very informative.

There are some out there who believe that automated testing will completely take over manual testing. This is just plain nonsense. The need for manual testers is still there because everything cannot be automated “yet”. The job titles have changed and moved on like the first blog post says “they Evolved” Moved on to be more than just manual testers to specialize more into things like Data Analysts, Performance Analyst, Security Analyst, Automation Specialist, and Technical Analysts.

The second blog post details the pros and cons of manual vs automated testing. To summarize this post i will say this. Automation stands to deal with repetitions and annoyances more so than to completely consume manual testing all together. The process of automation helps more people to focus and specialize into the areas of software development that need the help. Like automation in factories, it might start to take some jobs but it is already proving to be a benefit.

From the blog CS@Worcester – Conundrums In Computing by patrickgrahamblog and used with permission of the author. All other rights reserved by the author.

Chronicles of Testing posted an interesting article on pair testing on October 27, 2016. Jyothi Rangaiah elaborates on how pair testing has helped her as a software tester.

Pair Testing is a technique where two team members work on the same build on the same machine. One team member works with the mouse and keyboard and the other takes notes and makes scenarios.(From Midfiretesting blog)

Jyothi Rangaiah  states that pair testing is for everyone testers and non testers alike. This is because pair testing is for anyone who wants to learn about testing. Pair testing is also for anyone who wants to get help with testing. Pair testing is also for anyone who wants to share their ideas. She states that pair testing is a good experience for management and coders to analyze a problem together.

When pair testing the result is almost always a combination of both participants and turns out better than the effort of one tester. There are obvious faults in pair testing though. Some of these faults are if the pair do not get along or if the test only requires one person to work on it.

To find out more check out both the blogs listed in this 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.

Debugging is something that has been used in my studies, but some have not been properly introduced to this topic. So this post is meant to share some basic information on debugging and some techniques that can be implemented to help exterminate those pesky bugs.

Technopedia.com gives a formal definition of debugging as “The routine process of locating and removing computer program bugs, errors or abnormalities. Debugging checks, detects and corrects errors or bugs to allow proper program operation according to set specifications.”

The number one technique that can be used is print statements. Inserting a print statement into a segment of code that could be the problem would give a fast response letting the coder know what part of the code wasn’t executing correctly. Print statements are one of the easiest and fastest ways to find what is wrong with a program. When there are too many print statements a logging system can be implemented.

Another method of debugging is to use a debugger tool. Some environments have these tools built in. This tool allows a programmer to step through the execution step by step. This allows the programmer to see exactly what variable or method is being called and the value before and during and after execution.

A program will never only have one bug. This is why a bug tracker can be useful. When  one bug is fixed it could cause something else to break, and cause a huge avalanche. When the programmer is done cleaning up there could be 100 fixes implemented. If there is no log to show what bugs were fixed that fix could later on cause more problems. This is why it is useful to keep an accurate bug log.

A few other techniques such as proper documentation and code comments are also just as vital to the debugging phase but those are more self explanatory.

This blog post Hackable Projects – Pillar 2: Debuggability explains a few ways that google helps to aid their developers in the debugging experience. The theme of this post is that you need to build the ability to debug into the software you code. They mention debugging on a localhost, on Mobile apps, and on real time systems. Some of the tips they mention are proper logging, monitoring, and statistics.

But after all this by far the technique that has helped me the most is Rubber Duck Debugging. This approach has the programmer explain out loud to someone or an inanimate object, like a rubber duck, step by step how the code should function in simple terms. This technique makes the coder think in a different way about their code. Most likely they will trip up and find the mistake during the explanation.

More information on debugging can be found here or here or here.

From the blog CS@Worcester – Conundrums In Computing by patrickgrahamblog and used with permission of the author. All other rights reserved by the author.

Searching through blogs  I came across a post about acceptance testing. This stood out to me because I had not heard of it so I thought I would find out what it is and make a post about it.

The full name is User Acceptance Testing. This type of testing is a step in development after unit system testing where you find out if the product will be accepted by the customer and if it is ready for release. This seems kind of obvious but it is one of the more important types of testing to make your customers happy.

The official definition in the International Software Testing Qualification Board Glossary is Acceptance Testing: Formal testing with respect to user needs, requirements, and business processes conducted to determine whether or not a system satisfies the acceptance criteria and to enable the user, customers or other authorized entity to determine whether or not to accept the system.

Most video gamers know that there is a recent trend in video games that allows players to get early access to the game. Or known as Alpha or Beta. I mention this because this is one kind of Acceptance testing known as Internal Acceptance testing and external Acceptance testing.

More information can be found here or here.

From the blog CS@Worcester – Conundrums In Computing by patrickgrahamblog 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.

Welcome to my blog! I have never used a blog before so go easy on me. This post will be an introduction of some things to come and to the writer.(Who just so happens to be me, Patrick.)

Currently the reason for this blog is that I am in a Computer class that requires it. But just maybe this blog could  out last that class and I could become famous! Well we all can dream can’t we? Anyway more about the blog. The class  that I am currently in is all about computer testing. Therefore this blog will mostly consist of content relating to software testing and anything I find interesting that has to do with Computer Science.

Now a little about Me. During  the week I am a full time student at WSU. (Worcester State University) My major is Computer Science and I have a minor in Mathematics. On weekends I work for the local grocery store in the butcher shop. Not the best job, ?But it does pay for gas. I am currently in the search for a job/internship in the Computer Science discipline.

My love for computers started young. I played video games with my father and brothers all the time. But, I was hooked the first time I played Zelda. Ever since then I have been getting the next gen gaming systems as soon as they came out. I had all of them growing up. Everything from my dad’s old Atari to PlayStation 4.

The beginning of the end was when I received my first PC for Christmas. I would be thoroughly embarrassed to find out the actual number of hours or more likely days or even months I have spent playing video games. Owning a computer was fine but I wanted to build my own. So I saved up some money and built one. It wasn’t that long before I wanted to know how the other side of computers worked. That is the hardware side. This just so happened to be when I was looking into colleges. This gave me the idea that since so much of my time was spent with computers I would try to make it my career. That is the Quest I am on To try and make my love of computing into a career and not just a hobby.

From the blog CS@Worcester – Conundrums In Computing by patrickgrahamblog and used with permission of the author. All other rights reserved by the author.