Week 3: Multitasking Through Tests
This week I was met with some interesting new tasks. I was finally assigned to the hardware corner! I didn't actually get to do much with it, other than play with some cables, but it still felt more significant than when everything I was doing was just on the computer. 
I did learn a few things about testing, though. 1: Test Synergy Sometimes, tests just do not work when used together or directly after one another. This was the cause of a few hours of frustration one day on-site. In our case, we could not figure out why one test kept producing a failure, until we attempted to run it over again after a different test. The previous test would leave the system in a state such that it could not pass the next test. This is a major concern that needs to be looked at while creating tests, as it could lead to not only failures, but false positives, which would be much more harmful and dangerous to the tested product. 2: Waiting 
When automating tests, waiting can be a very good thing. Though it seems to prolong the time needed to get results, waiting is very necessary while testing is being completed, and, since no user intervention is necessary, it gives the user the ability to do something else, such as other work, brainstorming ideas, or even just sleeping. This is one of the main appeals in automated testing: a cut in the amount of man-hours necessary to be sure that a program works. That's all for this week! Please, check back in next time! -Chris Varanese
How long is the waiting process? What could be some potential damages from false positives? Do you know how they could occur in the testing?
ReplyDeleteSophia,
DeleteThe waiting process varies between tests. Sometimes there is none at all, while other times it can take days.
Damage from false positives is severe. It could lead to one thinking that the program runs fine, while it actually cannot complete its task. If you are looking for an example, imagine that a roller coaster passed the test of being able to stay on the track, but when it actually ran, it flew off in the middle of the ride.
They just simply occur, as with most other things, when there are errors written in the code, or when a previously run test has left the program in a state such that it is no longer fit to be tested.
It wouldn't be a complete week without a picture of your workspace haha. Sorry to hear that one of your tests is having issues, is there any way to modify how you are doing the test in relation to others in order to fix the problem? Hope things go well!
ReplyDeleteOf course there are ways to modify it! However, I'm not really trusted with it yet, so one of my supervisors will be fixing a few things and turning it over to me when he is done.
DeleteHi Chris, I just got to peruse your blog. sounds like you moving along in C and automated Testing. I am I am intrigued by DAVE. Could it be it is named after Dave the nemesis of HAL (Heuristically programmed Algorithmic computer) from 2001, A Space Odyssey?
ReplyDeleteThanks!
DeleteI did some research, and could not really find anything on the origin of the name DAVE. I did find that it stands for "Digital Application virtual Engineer (DAvE)," though. Perhaps the creators had the work in mind.
I totally understand the waiting process! It occurs a lot during editing video too! Are you going to be able to work more with the hardware corner?
ReplyDeleteOf course! That's all I've been doing recently.
DeleteHi Chris, I am Noah from Lutheran High School in Parker, Colorado, and I was wondering what exactly you were coding? I work with C quite a bit as I am the primary coder on our Robotics team (I use RobotC if you were wondering) so throwing out some technical terms won't scare me. Finally I was also curious as to what kinds of tests you were testing, and what they look like?
ReplyDeleteHey Noah. I'm not sure exactly what you're asking, but I'll try to give a brief explanation. The company that is sponsoring me creates large battery cells or use mostly on cell phone towers, for when they do not have a steady supply of power. I have been working on creating tests (at this point, only really basic ones) that make sure that the batteries are able to communicate back to HQ properly. Mostly, I have been using an add-on called Unity to test the code that has already been written by the company. Recently, I moved on to more in-depth testing, and started to look at if the hardware that is put in to the battery cells is able to give the correct information back to HQ. The results of both of these tests that I have mentioned will be used in my research and will help me come to a conclusion.
DeleteThanks,
Chris