Scott’s Spot – New Samsung Phone and SmartSwitch

Show Date: 1/13/2020

Guests: None

What Happened?

• My Samsung Galaxy S7 Edge had started re-booting several times a day.

What my wireless provider did about it?

• The first customer service rep looked over my phone and account info and recommended that I talk to the warranty repair/replacement people since I had replacement insurance on the device the whole time that I owned it.
• I tried to call this line several times and got consistent 20 minute hold times (when my phone didn’t re-boot during the call).
• The one time that I talked to someone from warranty, they picked up just as I pulled into my Vet for a pre-scheduled appointment. I was told I would get a callback around 4 pm that day…. It never happened.
• The second customer service rep that I talked to looked at my account and entered a replacement ticket for me. No Hassles.
• I got my replacement phone the next day.
• The transfer directions stated that one option was to use the Backup to Google Drive option, but I found that this did not want to copy my contacts for some reason.
• I used the Samsung SmartSwitch to move all my data from my old device to the new one. It was fairly smooth even though it said it was going to take about 1 hour and 10 minutes and was finished in about 25 minutes…...darn the luck.

So don’t just listen to the first rep you talk to….no matter who your carrier/provider is. Try another store or rep and you might get a better result.

Good marks for the SmartSwitch app which made moving to another device mostly painless.

Episode #18 – The journey of 1000 miles starts with a single step ...... Unit Testing

Date: 1/12/2020

Guests: none

Welcome and greetings

Recap of last episode

• In the last episode, we discussed Test Automation and how it can be used to accelerate your pipelines. We also discussed some of the methods of automating tests and some products that can help you with your automation.

Summary of this episode

• In this episode, I’m going to discuss the lowest level of testing possible by a developer, and that is Unit Testing. I’m going to give a brief description of what it is, what value or benefits that it can bring to the table, when to start it, and some examples of how it can be implemented.

What’s in it for you?

• After listening to this episode, you should have a better understanding of what unit testing is, how it is different from other types of testing and how it can be used to speed up some of your development efforts.

Episode Content

• What is it?
  • Unit Testing is when a developer writes tests to validate the smallest piece of code possible.
    • Methods, functions, procedure calls, etc.
  • A Unit is a self contained piece of code that typically has a small number of inputs and outputs.
  • A Unit Test can have constructor and destructor methods to ensure that any needed data or structures are created before the test is run and cleaned up once the test is done.
• What benefits does it provide?
  • Testing smaller pieces of code is faster than testing the whole program.
  • Tests are simpler since they cover a smaller set of code.
  • Defects found in unit testing are cheaper to fix since the change should be smaller.
  • Debugging defects found in unit testing is faster due to the smaller set of code to review.
• When should I start using it?
  • When you write the first method, function, procedure call.
  • You should write your unit test cases in tandem with your program code.
  • The earlier the better.
  • It is one of the predecessors of Test Driven Development.
• What can it be used with?
  • Any of the modern programming languages should have their respective unit testing framework. Java has Junit, c variants have xunit, python has pytest…..you get the picture.

• How to use it? A real life example for Java (kind of)
  • method call

public int addNumber(int x, int y) {

return x+ y;

}

• Unit test

public void testAddNumber() {

double result = addNumber(2,3);

assertTrue(result == 5)

}

• Unit Tests are grouped into TestSuites
• Test Suites are executed by TestRunners
• Test Suites are classes that contain a grouping of individual Unit Tests that relate to a specific Java class that you are developing.
• TestRunners are classes that are written to consume the Test Suites, execute any test cases found in the TestSuite class, and raise the result for the entire run of the TestSuite.
• There are several different types of frameworks, Junix, xunit, pytest, mockito.
  • You should choose the one that is appropriate for the program that you are developing.
• Each framework while similar, has its own syntax and procedures.
• How to get the most out of your Unit Testing?
  • Pick the framework that is designed for the language that you are working with.
  • Keep the test unit as small as possible (single method or function).
  • Run your Unit Tests often – faster feedback is better.
  • Update your Unit Test Cases as changes are made to your codebase. Don’t wait until the end to write new Unit Tests or update existing ones.

Recap of this episode

• In this episode, I discussed unit testing, how it benefits developers and development efforts, and examples of how it can be implemented.

Like me Like my podcast – share, like, thumbs-up, review, subscribe

Next Episode: Family Feud - Component Integration Testing

Episode #17 – How Fast Are Your Tests? - Test Automation Concepts

Date: 1/8/2020

Guests: None

Welcome and greetings

Recap of last episode

• In the last episode, I discussed various types of testing and where they are typically found in the SDLC. This is not an all encompassing list and does not dive too deeply into each type but is a general overview of how they can be used and how you might want to think about using them to testing your applications.

Summary of this episode

• In this episode, we discuss Test Automation and how it can be used to accelerate your pipelines. We will discuss some of the methods of automating tests and some products that can help you with your automation.

What’s in it for you?

• After listening to this episode, you will be able to determine if your tests are good candidates for automation and how you can integrate test automation into your CI/CD pipelines.

Episode Content

• What is Software Test Automation?
  • It is simple the act of executing a set of test cases without any human intervention.
• Why is it important?
  • This takes the human factor out of test execution. All steps are executed in the same manner every time that the test case is run. This restricts any variation in test results from a human hand controlling the execution of the tests.
• What are some of the benefits?
  • Repeatability – Easy to duplicate your results
  • Consistency – minimal variation in test execution
  • Speed – automated scripts don’t need bio breaks
  • Reliability – no human factor
  • Schedule-ability – can be set to run automatically
• What makes a good automate-able test case?
  • Frequency of execution – provides more value quickly
  • Known inputs and outputs
  • Simple test cases
• How can we automate a test case?
  • It can be scripts that are written in house?
  • It can be done with third party tools such as Selenium, Unified Functional Test, and other automation tools such as Jenkins
• Maven can run your unit tests as one of its “goals”: clean, verify, compile, test, package, deploy
• Gradle can run your unit tests using a task of type test.
• Selenium can be used as a scripting engine to test your application
• Unified Functional Test is an example of a 3^rd party tool that creates a “script” of test steps that are then executed as part of your automation.

Recap of this episode

• In this episode, I discussed what test automation is, some of the benefits, and some types of test automation.

Like me….. Like my podcast…. Please share the link, click on the like, give us a thumbs-up, leave us a review, hit the subscribe button, and tell your friends!

Next Episode: The journey of 1000 miles starts with a single step ...... Unit Testing

Episode #16 – Testing 1,2,3

Episode #16 – Testing 1,2,3

Date: 1/5/2020

Guests: None

Welcome and greetings

Recap of last episode

• In the last episode, we talked about the need to start your testing early in your Software Development Life-cycle (SDLC) where it is cheaper to remove defects that are found. We also discussed some of the reasoning by why you need to start early testing, some types of early testing, and costs of early testing…..or starting early.

Summary of this episode

• In this episode, I’m going to discuss some of the different types of testing and where they typically fit into your SDLC.

What’s in it for you?

• After listening to this episode, you should have a better understanding of the types of testing that are typically seen in a SDLC and what they are composed of.

Episode Content

• Requirements review
• Unit Testing – testing of a specific piece of code. This is a test for the smallest functional piece of code. Think of this as testing a specific function or method.
• Component Testing – This is used to test the complete functionality of a class. All of this testing should be stand-alone and only involve the functions and methods of this class. It can be thought of as method a calls method b and passes a defined set of data and expects method b to return a defined response (data, true/false, etc.).
• Component Integration Testing – This consists of testing how the components of your application interact with each other. It can consist of passing a specific set of data between the functions in your class to ensure that they output of the class meets the defined criteria.
• System Integration Testing – This testing is usually performed when your application is deployed to a defined testing environment. The environment should have all the infrastructure, middle-ware, and data to support your testing. This type of testing is used to evaluate how your application interacts with external entities. It could be a call to another application or website, a call to an internal company API (Application Programming Interface), or writing to an external database for logging. This type of testing can be very extensive and time-consuming if it is done manually.
• User Acceptance Testing – This testing is done after you have deployed your application to a stand-alone environment and your business users are the only ones that are allowed to test against it. They should be trying to determine if the application or changes meet the needs as outlined in the business requirements (remember when we said the easiest type of test was a requirements review).
• Regression Testing – this is a defined set of tests that are run every time that a change is made to an existing application.
• Smoke Testing – This is a sub-set of your regression test suite that can be run around a specific change to ensure that the application is performing as expected.
• Non-functional Requirements
  • Performance Testing – uses a defined load against the application (ex. 100 http sessions started per second)
  • Load Testing – tries to determine how the application will work under a higher than normal load or usage.
  • Break Testing – ramps up the load until the application breaks. This is done to determine what your real capacity is for the infrastructure that you have set up for your testing (ex. 1 web server can handle 1,000 http sessions per second). Then you can use that to extrapolate how much infrastructure that you will need for your expected production capacity.
  • Spike Testing – This testing tries to determine how your application will handle unexpected spikes in traffic. Will the application continue as normal, will it slow down, or will it stop working and crash unexpectedly.

Recap of this episode

• In this episode, I discussed various types of testing and where they are typically found in the SDLC. This is not an all encompassing list and does not dive too deeply into each type but is a general overview of how they can be used and how you might want to think about using them to testing your applications.

Shout-outs- Mike Lyles and his new book – The Drive Thru is NOT Always Faster

Like me Like my podcast – share, like, thumbs-up, review, subscribe

Next Episode: Test automation

new promo video - Check it out if you haven't Listened

Check this out and let me know what you think.   I'm thinking of using a small video like this of each episode to advertise on Instagram

Here is the link to the podcast website:

http://scott-talks-tech.buzzsprout.com/

Episode #15 – The need for early testing in software delivery

Date: 1/2/2020

Guests: None

Welcome and greetings

Recap of last episode

• In the last episode, I discussed the Wyze suite of home automation products. I spoke about my experiences with each item and any issues or gotchas that I encountered while setting them up and using them.

Summary of this episode

• In this episode, I am going to talk about why you need to start your testing while you are writing the code for your applications. I’ll give you example of how, what the benefits are and what costs are associated with doing it right and doing it…….not so well.

What’s in it for you?

• After listening to this episode, I hope you understand why it is important to start testing early. Go back and discuss it with your team and start today if you can. Start small and build on it.

Episode Content

• Why test early?
  • Testing early is one of the simplest way that you can cut some of the expense out of software development.

• There have been numerous studies that show it is much cheaper to fix a bug or defect before it is released to a testing environment.

• At the start of a project there are many unknowns and if a team writes all the code and no testing is done on it the first quality profile is found when it is first deployed to any environment.
• This uncertainty is referred to as the “cone of uncertainty” and is shown in a diagram that looks like a funnel with the large end to the left where the project starts and the smaller end on the right as requirements are redefined more accurately and software defects are fixed and released. The premise is that you don’t know a lot a the start of a project but should know everything about the software and how it meets requirements as you get closer to the production release.
• The best way to fix defects in the large end of the cone is to perform a super-duper simple set of tests…..are the requirements testable and do they make sense. Requirements reviews are a great way to cut expense at the beginning of the project since no code has been written yet.

• Once the code is deployed, it is then up to testers to run through test suites (manual or automated) to find what issues exist with the code.
• At this point it is more expensive in money and effort to fix the defects that are found.
  • This is true because a developer, who may not have looked at the code in weeks, will have to review the code and possibly relearn what it was supposed to do before they can make the changes to fix the defect.
  • The code will then need to be re-compiled and packaged before it can be re-scheduled for release back into the testing environment.
  • The testers will then re-test the code to verify whether the defect was fixed.
  • If not, the defect is once again re-assigned to the development team to fix.
  • You see how this cyclical code, test, fix can be time consuming and expensive.
  • The more optimal path would be to write the code and write a corresponding test to verify its functionality.

• Types of early testing
  • Unit testing – this is probably the one that most people are familiar with.
    • It is used to test small pieces of code as they are written or modified.
    • They are usually written using a framework such as Junit or on of the xunit variants since they have wide usage and adoption in the industry.
    • They can be very language specific, such as python where you are required to use custom libraries to implement the test framework. The first time that I had to do this for Python, I was pretty lost as my background is in Java.
  • Test Driven Development
    • This type of testing is based on the premise that no code is written before a test case for that code is created. Then just enough code is written to make the test pass.
      • For example: a program needs to determine if a file exists.
        • Test case: does file x exist at location y
        • Code is written to determine if there is a file system at the specified path x and if the file denoted by y exists at that location.
        • Then another test case is written for the next piece of functionality.
        • And the cycle continues.

• Costs associated with testing
  • When you wait until development is finished and first deployment is completed, there is a cost associated with the number of testers needed and how the tests are run (manual vs. automated).
  • If you are a manual testing shop and have a fairly complex system, the cost to develop the needed test cases is fairly high since the testers must wait until the code is completed and deployed to write their functional test cases (a test case that tests a specific piece of functionality).
  • If you are an automated testing shop and wait until the software is completely deployed, the cost can be just as high as automated test cases, even though they can be re-used once complete, can be very difficult and time consuming to develop the first time.
  • If you write your test cases with your code as it is developed, then you can have a higher degree of confidence that it will meet the needs of the requirements once it is deployed to a test environment and the system integration and functional tests are run against it.
  • Non-functional requirements (system response time, time to failure, http request response time, database response time, etc.) require a different type of testing and is usually very specialized (framework, toolkit, and resources) and complicated to create and run. The earlier that these testers can get the code and start developing their test cases, the cheaper it will be in the long run as this is also a re-usable set of test cases.

So in my opinion, the earlier that you can start writing test cases, the more expense that you can remove from your software development efforts. Don’t wait until your code is complete to let your test partners start creating tests based on what you have. Even if they have to re-write some of the test cases, it is better than starting from the beginning.

Recap of this episode

• In this episode, I discussed why you should start testing as early as you can in your development cycle. I also discussed a couple of methods of early testing that can help reduce the expense of software development. I then discussed the costs associated with software testing and how “shifting left” can help your organization reduce costs related to development and testing.

Like me Like my podcast – share, like, thumbs-up, review, subscribe

Next Episode: Types of testing

Scott’s Spot 1 – Wyze Customer Exposure

What Happened?

• Some customer data was left in an insecure state that could have allowed anyone with read level access to view the data.

Why it happened?

• The statement said it had not been determined exactly how it happened but that a security policy on a subset of data in an internal database was removed which could have allowed the data to be accessed by users without the proper clearance.
• The data had been copied from their production servers to allow queries to more efficiently be run against it while not affecting customer interactions with the Wyze systems.

What is the company doing about it?

• They issued a very long statement detailing what they thought had happened and according to the statement are reviewing their internal security controls and ensuring that all employees are trained in how to properly implement and maintain them.
  • I was impressed at the depth of the detail they went into with the statement. It shows that customer experience and customer privacy are important to them.
• This is a perfect segway into one of my previous episodes where I talked about how publicly traded companies have to comply with the Sarbanes-Oxley act regarding internal controls. This does not apply to Wyze Labs since it is a privately held company according to CrunchBase.
  • https://www.crunchbase.com/organization/wyze-labs#section-overview
• Please go back and review Episode #12 – Ball and Chain of Custody.
  • http://scott-talks-tech.buzzsprout.com/730172/2343971-episode-12-ball-and-chain-of-custody-legal-requirements