Types of Testing

There was an article I found the other day that took a different approach on types of testing.  The article is from ITpro, a site based out of the United Kingdom (http://www.itpro.co.uk/software-development/29994/types-of-software-testing).  The author breaks down nine different types of testing.  The article doesn’t try to state that the types are exclusive and that you should pick one or two and use those types.  Instead it just breaks down the different types, the different times they are carried out, and who carries out these tests.  Some are performed by the software testers during development and some are performed by the user to test different aspects.  For example alpha testing is performed by the software tester before release to search for all possible issues and errors.  Whereas beta testing is performed by the user in a deployed environment.  It can be as controlled and closed off to as group of a desired size in order to test for real time failures.  The control group is to ensure that it is not widely deployed across an environment and causing business failures.  Beta testing is similar to acceptance testing which is performed by the customer to ensure the product meets all requirements and expectations set by the user and the developer.  There is also a type of testing called security testing.  This type is performed by a special team outside of the standard testing team and usually performed by security consultants.  It is usually done to find out if there are flaws in the software that can allow it to gain access to computers or networks that it shouldn’t be able to and could cause damage to these networks.  Another specialized type is stress testing.  This is performed to push the software to its limits and usually beyond the normal operation that the standard user will put it through.  This is used and needed to get a clearer picture of what your software can do and what the limits are.  The one type that stood out to me the most and struck my interest was smoke testing.  This is done when a new build is sent to the testing team.  Simple tests are performed to find out if it crashes the program indicating bigger issues.  It makes sense to do, before digging deep into tests to just run quick simple tests to see if it can even pass that stage.  It just never occurred to me to make sure to do this step first before fully jumping into alpha testing.  I think that reviewing the different types of tests every once in a while to remember that there is a full spectrum of testing and how important the testing process is to software development.

Testing Really Does Matter

This week I read an article called “Why Testing Matters (https://blog.smartbear.com/software-testing/why-testing-matters/).  It’s easy to take testing for granted and start to think it is less important when everything is going right.  When testing is not taken seriously though serious problems can arise.  The article touches on a  few recent issues to further cement the point of the article that testing plays a critical role.  The first issue is that the iOS 11.1 update causing the letter “I” not typing and a crackling sound during calls.  This can be detrimental to a company especially one like Apple that has strong competition with Android and people are quick to switch phone types after a few issues.  Android is not without their own testing issues though.  The Android OnePlus 5 disconnected users who tried calling 911.  It’s important to remember that faults and errors are not only a slight annoyance to the end user, but can also cause dangerous situations for your users.  The one that stood out to me in the article is a software bug that revealed the names over 1,000 Facebook moderators to hate groups that were being watched for posting inappropriate content including potential terrorist organizations.  This puts Facebook’s own employees and their families at risk.  Beyond that it is also a reminder how easily our personal information can be exposed just by ignoring or overlooking a few simple tests.  A few additional hours of testing and work can save your end users many months or even years of head aches and problems dealing with identity theft.  There were also issues that were found with the global positioning system ground software.  Due to software issues there was an error of 13 microseconds.  While that doesn’t seem like a lot that averages out to be just under four kilometers off course.  This is a very serious error in positioning and navigation and can cause errors for millions of users.  Since software testing was not seen as a priority a delay in testing caused a new fleet of passenger train cars in Oakland to deal with overcrowded trains to be delayed.  While the exteriors of the cars are being built on schedule the delay in testing is bottle necking the process.  I like this blog because it shows a broad spectrum of issues and in different industries.  That’s good because it helps promote the idea that software testing is needed everywhere and it’s not just for a company that only produces commercial software.

Testers Need To Know How To Code

The blog that I chose this week was written by Trish Khoo.  She was previously a manager on an engineering team for Google Maps until she decided to leave and return home to Australia.  Her blog post (http://trishkhoo.com/2017/08/yes-all-testers-should-learn-how-to-code/) discusses the need for all testers to be able to effectively know how to code.  I was going through some of her blog posts when this post caught my eye.  I never realized that there was as big of a split as the poll showed that there is.  The Twitter poll showed that 55% of the voters believed that all testers should be learning how to code.  45% felt that is was not necessary.  This shocked me because up until now I was so rooted in the opinion that all testers should know how to code or be learning coding skills that I didn’t realize that it was even possible to be a software tester without having coding skills.  I believe that testers should have coding skills because it will help when writing tests and analyzing code to find the bugs.  If you don’t have coding skills then all you can really do is run pre-written tests and report back if it passed or failed.  With coding skills you can rewrite codes that may improve your test results and productivity.  Also if you are running white-box testing instead of just finding the bugs you can realize what the error is and what caused the failure.  Then while you may not be authorized to change the code at that time it can help you learn more and help advance your career.  Trish Khoo feels the same way and states her suprise that anyone would consider programming not essential in today’s software development workforce.  She has done some research and found that programming is being entered into the school curriculum in Australia, the U.K. and the U.S.  In some places even down to the elementary school level.  In a world that is constantly becoming more computerized and connected I’m glad to see that here in the U.S. we are seeing a basic level of programming as a necessary tool for entering the workforce.  At the end Trish Khoo also gives her reader two sites that are excellent starting points to start learning code.  The resources are both free and easy to navigate with step by step instructions on a wide range of languages and instructions for users of all ages.

A Structured QA Process

The blog post I chose this week comes from stickyminds.com and discusses how the quality assurance testing process is changing.  In the post (https://www.stickyminds.com/article/4-strategies-structured-qa-process) Praveena Ramakrishnan gives a general overview of the old way of testing where the tester was just focused on finding bugs.  Then they discuss how their next job gave her a different perspective.  That her job wasn’t just to find the bugs and try to break the program, but to work as a team towards the overall improvement of the software.  I think she has a positive view of her role as a tester and how employ some strategies to continue that positive mentality.  Her first strategy is to review documentation.  This is a good reminder for testers at all levels.  When approaching a project we need to remember not to rush into writing tests before we read the documentation and have a solid understanding of not only what the program is doing, but also try and gain some perspective of what the designers want the program to do.  The second strategy is to research past defects.  When we look at the past issues we can try to identify if there are any patterns.  This could help speed up future testing by improving the efficiency.  She then emphasizes that it is important to triage the defects.  When we as testers find a bug we should report it as soon as possible, but that is only the beginning.  After that we should look into what caused the issue to occur and what version it was added to the code.  This again helps paint a fuller picture of the defects and the code in general so that we can identify any patterns and try to improve in the future.  This goes into the last strategy which is to go beyond the reported issue.  Try and look beyond just your tests.  If you have logs review them as well.  The tests may pass, but you notice other errors occurring.  Catching these can improve future performance as well as prevent future defects.  Going above and beyond the minimum also typically results in higher pride in your work.  Employing these strategies will have a snowball effect to your job.  While you may not see a clear difference overnight keep working on implementing them and over time your skills will improve leaps and bounds over your peers.  Remember that it’s not just about breaking the application until the developers fix all the bugs, it’s about being a part of a team that strives to create the best product possible.

Testlio Changes the Game

There’s a small company out of Estonia that is making a big splash in the world of software testing.  Testlio was founded after CEO Kristel Kruustük was on the team that won the 2012.  A September 15th 2017 article by zdnet.com does a profile of the CEO and the company to provide insight on the software testing company’s mission and outlook on testing (http://www.zdnet.com/article/how-testilio-wants-to-rethink-software-testing/).  The CEO Kruustük worked at several companies around the world and noticed flaws that she saw within the software testing community.  Kruustük and her company take a different approach to their hires and their view toward junior level testers.  Testlio has found that companies that had strong diversity in their employees also had a clear improvement in their productivity.  Testlio has implemented this diversity hiring practice at their own company and have found the same increase in productivity.  Another practice that Testlio follows is putting more emphasis on junior level testers and move away from senior testers.  While Testlio has aggressively embraced this outlook on hiring youth it may not be what most people think..  Kruustük goes on to explain that this is not necessarily just the age of the tester or how long the tester has been in the business, but staying away from testers that have been in the same position and are less willing to try different methods or take advice from outside sources.  Kruustük and Testlio does not see testing as just a mundane task that has to be done, but instead as its own separate business.  This mentality has allowed Kruustük to grow Testlio into a business that has two offices, one in San Francisco and the other in Tallinn.  They also have 200 testers that work with roughly 650 million monthly users.  With the number of users and testers that Testlio has it is hard to deny that their unique approach to testing and employment process yields significant results and is part of a sustainable business model.  Testlio is a new company that is embracing junior testers that it’s found are more open to new ideas and thinking outside of the box.  I have a feeling that Testlio is a company that will continue to grow as they open their doors to a younger more diverse workforce.  They will soon become a very common name in the industry and I think will be a pioneer for a new outlook on testing, embracing diversity, and constantly bringing in new talent to their ranks.

Software Tester Characteristics

This week I read a blog post from TestLodge talking about the characteristics that make up a good software tester.  The post found at https://blog.testlodge.com/characteristics-good-software-tester/ helps identify some of the attributes that a tester should have in order to be proficient in their testing as well as excel in their career.  I chose this post because it provided a different perspective than most.  As a student initially learning these skills I often get too focused on how to do different testing procedures and sometimes forget to look at why I’m doing them and what purpose do they have. Articles and posts like this help me to take a timeout and look beyond the skill set that I’m trying to acquire to help put me in the right state of mind.  The post breaks it down into 13 different characteristics.  Characteristics like testers have to be a strong communicator and be a team player.  This is good to remember, especially early on in our careers, so that we don’t ignore failed tests or improperly communicate what failed in the software to the rest of the development team and let an inferior product be released simply because we were to scared of upsetting someone by telling them part of the code is wrong.  Other characteristics like thinking creatively and paying attention to details.  These attributes will help us examine closer what the goal of the test that we need to write is and think outside the box in order to write the most effective test.  We need to be able to realize that just because we did a test a certain way in class for a project one time, that may not be the best way to write the test every time.  A good tester should also be organized and should meet deadlines.  Time management is crucial in the software development process.  Staying organized with all your tools, notes, and team communications will allow you to complete more tests.  It will also help you keep track of your deadlines and prioritize your tests so that way you are not delivering a product late of missing important tests and creating too many tests for less important features.  I felt like this post is good to revisit from time to time so that I don’t get too focused on just trying to write a perfect test and develop a broader skill set that allows me to recognize the right approach to each situation and to stay organized without rushing into a project and failing from the start.

Six Pitfalls In Testing

A recent blog post I read is entitled “Six Things That Go Wrong With Discussions About Testing”.  It is a post from August 27, 2017 on James Bach’s blog http://www.satisfice.com/blog/ .  In it James Bach talks about six big pitfalls that developers fall into when thinking about and talking about testing.  I chose this blog post because after reading it the information stuck with me.  He takes a step back from testing and writing tests and talks more about how to effectively test.  I thought it was a good topic that a lot of testers and developers overlook.  The first point is that people care too much about the number of test cases and losing focus on writing effective test cases.  This is a sound piece of advise to remember especially in college before getting too far into a career in software development; it’s more important to write a few strong tests than to write a lot of weak tests.  The second is that people treat a test as an object rather than an event.  This one interested me a lot.  It’s a good way to look at tests.  A test isn’t just an object, it is an activity and no test will be the same between two testers.  The third topic he talks about is when testers can’t describe their test strategy.  It’s a good reminder that as testers we need to constantly reevaluate our testing strategies and adjust it as necessary.  When we don’t step back and check ourselves we stop progressing.  The fourth point is that people talk about testing as if it is an automated process.  When we do that as testers it removes the human aspect of creating the tests.  This creates a division between testers and the tests.  We start to stop taking responsibility when a test doesn’t go right and that responsibility is important to have in order to learn from mistakes in testing and get better.  The fifth is when people talk as though there is only one kind of test coverage.  Even if a tester develops their own style and favors one type of test coverage during their career, it is important to remember that there are many kinds and a tester should keep them in the back of his mind so they can be ready to switch to the most effective kind depending on the situation.  The final pitfall is when people talk about testing as if it is static.  This is a fundamental concept that, in my opinion, should apply to almost all aspects in life.  When you think you are done improving then you are.  A good tester needs to always be open to new ideas and ways of doing things.  That mentality helps a tester to improve and avoid becoming stagnant. Which fits perfectly since thats the idea behind this assignment of blog posts.

Intro Post

Hello, my name is Tim Kmiec and this is my new blog for CS-443 at Worcester State University.