I’ll test it later. I am sure at during one point or another in all our programming careers we have told ourselves this before.

I came across an interesting article about Twyla, an engineering company who is training their employees’ to dedicate more quality time to testing practices. If you had to choose between writing code to test a program or writing code for the actual program, many would choose the latter. We feel some sense of accomplishment and progress in coding the program while coding the tests does not. “Why am I coding tests for a program that hasn’t even been created yet?” Some might think that this approach is a waste of time but I would argue that it actually saves you time in the long run because you will run into possibly less errors since the tests echo the necessary behavior of the program. Twyla encourages their QA teams to sit down together once a week for an hour for product testing which I think is a great idea because not only would it increase our testing capacity but our social abilities as well. QA testing, like anything else, only gets better through practice and what better way to do that than to sit down with others, share ideas and have a testing frenzy!

Link: https://www.rainforestqa.com/blog/2016-10-13-how-to-build-a-culture-of-quality-a-case-study-of-twyla/

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.

Okay…I might have exaggerated the title a little bit. When I say infinite testing I really mean continuous testing, which in really broad context pretty much means the same thing (that is, if the continuous testing goes on forever).

Since we are currently learning about different testing methods and techniques in our Software Testing and Assurance course, an article about continuous testing peaked my interest. As technology continues to evolve so does our software, which is why it is important to keep up to date with testing to ensure that our programs are bug-free. The article on rainforestqa.com (https://www.rainforestqa.com/blog/2016-10-11-when-does-continuous-testing-happen/) goes into details about which stages continuous testing plays a crucial role in. The objective of continuous testing is  to publish your code to customers as fast as possible with high quality releases which is achieved using several different testing methods, such as unit testing, automation testing, and manual testing.

Like almost every other program, continuous testing should start at the beginning of development and carry out throughout production. During the stage of development, unit testing is the primary use to debug and catch errors. Some companies even use test-driven development strategies where writing test code is placed before writing the program code. Once it hits the stage of production, it starts to become easier because at this point the test cases should already be fairly stabilized so automation testing is primarily used during this stage since only small feature changes are being made. Although automation test is commonly used, some companies recommend “smoke and sanity” tests as well which are tests that are manually ran to test the integrity of the core program flow to ensure everything is working properly.

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.

Cellphones are widely used today as a form of communication among different groups of people. However, nowadays that is not the only primary function of a cellphone. The other primary use for a cellphone is entertainment, and with that comes mobile apps. I came across an article this week titled “4 Methods for Mobile App Testing that Emulate Real-World Use Cases”.(link: https://www.rainforestqa.com/blog/2016-08-29-4-methods-for-mobile-app-testing-real-world-use-cases/) which talked about how different types of testing can be applied to detect defects in common everyday mobile applications.

Out of the 4 methods the article touches base on, I found the third method to be particularly interesting because it was one I had never thought of before and I found it to be a useful tool. The testing method was to “Dog food your own product”. This meant to incorporate the application and use it with your everyday life. Since you are the creator / programmer you understand how you want the application to perform and behave so you can detect issues or bugs within the program once you encounter them. Besides that, since you are incorporating it as a part of your daily activities, you are more likely to come across problems that might not have been thought of during the testing process. I found this method to not only be fascinating but also beneficial because it could also potentially exploit detailed flaws like device type, battery life and other environmental factors that may have not been considered.

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.

Admit it, we as the people want technology to do everything for us. People want something that can play music, download movies, track fitness levels, helps concentration, schedule appointments, socialize, shop online, and complete assignments simultaneously for them all in one app. Now an app like this doesn’t exist (at least I don’t think it does…) but imagine the flexibility the app would possess if it did. Ultimately, when we think of qualifications for “good technology” , flexibility is a key requirement.

When it comes to software testing the qualifications are mutual. The goal is for test suites to be flexible; meaning it is adaptable in any given condition and is able to correctly handle any given situation that may be presented to it. This seems great and all but if you ask me, the greater the flexibility is, the greater the complexity becomes.

To test whether or not this is true: assertTrue(flexibility.equals(complexity);

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.

With the increasing fast development of technology in today’s society, you can almost guarantee that 99% of people have some type of advanced device on them at all times. For those of you who are not included in that 99%, you may like doing things on your own without having to rely on technology to do so for you, which includes manual testing.

While manual testing is still active today, it is not very practical or time-efficient. Us as humans are imperfect which leads to the chance to make mistakes with manual testing, not to mention the amount of hours it will take depending on the scale of the program.

An obvious solution to this issue is to replace manual testing with automation testing. Not only will this save you the trouble and time of having to set up tests that require complex requirements and pre-conditions but it is also helpful in inputs of data that need multiple fields of information.

Other 5 Blogs Read:

1. http://www.testingtv.com/2016/09/21/from-junit-to-mutation-testing/
2. http://www.softwaretestingmagazine.com/knowledge/oblique-testing/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+SoftwareTestingMagazine+%28Software+Testing+Magazine%29
3. http://www.softwaretestingclub.com/profiles/blogs/why-manual-tests-are-error-prone-and-what-to-do-about-it
4. http://www.softwaretestingmagazine.com/news/blazemeter-acquire-by-ca-technologies/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+SoftwareTestingMagazine+%28Software+Testing+Magazine%29
5. http://www.testingtv.com/2016/08/30/code-quality-in-practice/

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.

Hello, my name is Tan Trieu. I am currently an undergraduate attending Worcester State University as a Computer Science major. Many people may not know this but CS 443 is my favorite course!….

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.