Model Based Testing

According to Michael Fritzius, model based testing is building a less complex representation of how the system is supposed to work, taking the test data and running it through the model and the system and comparing the outputs. The model that is used in testing is usually a giant if-else structure generated by a different program, and the test data should be similar to the data the system is expected to use. If the outputs don’t match, there’s either a bug in the system or the model needs to be updated. Using model based testing helps find problems much faster and speeds up the automation phase.

Michael says Model based testing should be used when a lot of tests need to be made for a system or a lot of data data needs to be tested. Model based testing would make boundary testing, especially worst-case and robust boundary, much faster than writing out individual tests, given there is also a lot of data that must be tested. Model based testing may be useful when there’s a lot of tests that need to be made, but seems like a waste of time if there’s only a few tests needed. You’d just be rewriting code, but a bit simpler.

Michael also says that there’s not enough time to test everything. Model based testing would be used in a pinch when there’s not much time to actually test every aspect of a system, or perhaps when making a prototype for a complex system. These models would be used on what the customers need to have working first, then the next important working part and so on. I feel like using model based testing in this way is a huge risk, but saves a lot of time that could be put towards getting other aspects of a system done or to get a working example up and running. I would think afterwards any of the more problems that come up with the system could be fixed later on.

Podcast Link: https://www.joecolantonio.com/testtalks/191-model-based-testing-devops-michael-fritz-fritzius/

From the blog CS@Worcester – Joshua Farrar's Blog by jmfarrar1 and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective – 2

Hi readers, on my sprint 2, we planned making sure everyone’s was ready to start with the testing. some team members were able to start with the angular and get the sever up and running. Some were stuck, like me. With me, i was able to get most of the things to work, like installing the latest java, nodejs/npm, the karma and the angular itself. Everything felt alright till i tried building the up the project given to us. When i did run the build command, it gives a lot of warning and also many errors. Did not no where i went wrong, so i consulted one of my team member who has finished with his set up and was able to build and also run the server command. He went through, noticed my @angular-devkit/architect was not installed. And also many many of the angular packages were not installed. So he decided for me to uninstall it and reinstall it back.

So i tried uninstalling it but to no avail. So i decided to use the vmware application to install linux OS since i was not able to uninstall the angular. I also learned, linux is pretty very cool when it comes to these kind of stuff. So after installing the linux OS, i did the same process as i did on the windows. Installing the latest java, nodejs/npm, protector, karma and angular. Everything worked fined and when i test for the angular as in the version. I noticed maybe all the packages were installed. That was great till i tried building on the project. when I run the build command, it game me a whole lot of warnings. But this time, it did not give me errors unlike the windows.

For now I am just stuck with making my angular work. Hoping will get help from a team member to see if that will help. If not, i will have to share with someone who’s program is working fine.

While i was also trying to fix my “angular problem” , i was also learning a whole lot of things on angular. Did a whole lot of search, searching on what could be the problem why my angular is not setting up. This made me start learning from scratch. It was really annoying. But i had no choice if i wanted to make this work. I followed most examples and also practiced most of them on my own. I notice when i tried creating a new angular application, it works fine but when i tried running an old project or building on an old project, it give me all kinds of warnings.

Through the week on my angular project and finding ways to make my angular project work. I got to find out that javascript has been upgraded. Which is not called ES6. ES6 is a major update to JavaScript that includes dozens of new features. With a focus on simplicity and readability, this course is an efficient way to find out what is new in JavaScript and most importantly when and how you should use it.

I went through this new updates on javascript. I notice a lot of differences and was almost like typescript. It wa very easy to understand and work with. Has less codding comparing it to the old javascript style of coding.

The second sprint, made me learned a lot on angular, learned new things i did not know and also got to know about the new upgrade of javascript. I like working on web development stuff. so i was really excited i got to know about this new update on javascript. I hope the next sprint, things became very smooth and easy.

From the blog CS@worcester – Site Title by Derek Odame and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective

This reflection is based on the work done from 2/20 to now, 3/5. In this time, our team has only met two times and I missed one of those meetings, so not a whole lot actually got done together during sprint two. We met in class and made progress on 2/20, I was absent from the meeting on 2/25. On 2/27, class was expectedly canceled with the optional choice to meet in class anyway, which we decided against. We figured we could wrap up anything that we needed to work on in the upcoming Monday’s class. Yesterday, on 3/4, Worcester State canceled all classes and events due to inclement weather, and the end of the sprint is next class at 3/5.

Our workload was fairly light anyway, we only had two sprint backlog tasks; make sure every team member could build and run the project, and learn more about angular testing. We could independently conduct research into testing, and we are encouraged to branch out to find potentially helpful content, so the snow day didn’t slow us down significantly.

To study angular testing, our group particularly focused on the two programs karma and protractor. Using the trello project management board we set up in the last sprint, two links were shared for the group to look over. For karma, I used the following link:

https://karma-runner.github.io/3.0/intro/how-it-works.html

This website explains in general terms how karma works. It loads multiple browsers and tests given code on each one, displaying the results conveniently to the developer. We will have to practice hands on with karma once we get some code and tests. For protractor, we used the following link:

http://www.protractortest.org/#/tutorial

All the information on protractors site is very hands on and literal. It explains steps and shows exact commands and lines for example, it should be easily set up and modified to our project. Since we downloaded the latest version of node.js in the last sprint, and have experience using npm, protractor will be a useful resource.

Our more major goal for sprint two was to have every member a working build of the AMPATH project in an IDE of choice. Right now, everybody besides me has a running project since I missed the last meeting. I will need to communicate with them for help troubleshooting and follow the same steps they took the next time we are all in class together.

At the same time, during our next meeting we will be planning for sprint three. We don’t have much on our plate currently since we’ve been making pretty good progress so far, so I’m not sure what to expect for sprint three. I think Professor Wurst will be giving us more concrete things to do, which we can add to our trello board.

We’ve also been keeping up to date on slack, every group member answers automatic check-ins two times a week. This keeps us all updated on what we’ve done since the last check in, what we are planning to do before the next check in, and state any obstacles blocking our progress.

From the blog CS@Worcester – CS Mikes Way by CSmikesway and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns – The Deep Ends

For this weeks blog post I will be looking at the pattern called “The Deep End”. The context behind this one is that taking small safe steps leaves you unsatisfied and you are beginning to fear that you may be in a rut. Instead of diligence that could attain the next level you are in a rut where bland competence eventually will decay into mediocrity. The problem with this is that you need to grow your skills, confidence and portfolio of successful work. Challenging yourself with bigger things like bigger projects, larger teams and more difficult and complex tasks, new workplaces and more. This will again help you grow as a developer instead of settling for a rut. The solution to this is to jump in at the deep end, taking it head on almost. Waiting until you are “ready” can turn into a disaster or a pattern of never doing anything. When offered a higher profile role or a more difficult problem grab onto it with both hands take it head on. Personal growth will only occur if you are doing something out of your comfort zone and doing things that stretch your boundaries. This of course will have its risks without a doubt. If you get it wrong and way in over your head you could drown. But thankfully in the business there are many places where you can take risks without destroying your career if you were to fail. These risks are opportunities that will help you grow. It means taking a foreign assignment when its offered, even if the possibility of failure is staring in your face. Acting on this will be extremely beneficial to you when in a rut. Thinking of the biggest projects you have worked on and then writing down the answers to these questions pertaining to the difficulty of other projects is a good way to start. Using metrics to measure every project, in a sense, of your own projects. I find this pattern to be very on par with the be the worst mentality. In a sense you are putting yourself in an environment that may or may not cause you to fail miserably but if you succeed you will grow immensely.

From the blog CS@Worcester – Dcanton Blog by dcantonblog and used with permission of the author. All other rights reserved by the author.

Sprint -3

In this last sprint my team and I ran into a few complications. We were trying to figure out how to go about creating these components that we are supposed. The class as a whole decided the best route to take was to break the amrs app down even more on GitHub so that each group would have their own component and there would be a ‘master’ branch so in the end we could push and merge everything onto that.

Some difficulties we had to work around included having to know what the layout would utilized because everything was sent over Zeplin but created off another platform (maybe adobe). We definitely are on the right path moving forward for the next sprint.

From the blog CS@Worcester – Life in the Field of Computer Science by iharrynguyen and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern Blog: Find Mentors

Hello and welcome back to benderson’s blog! This week are going to discuss another apprenticeship pattern from the Apprenticeship Pattern book that my classmates and I have been reading and taking notes from. The pattern that I would like to discuss today is “Find Mentors”, which is a kind of a self-explanatory pattern. It follows the rule of “If you hit a roadblock and need help, ask some to be there apprentice and work under them and learn from them”. You’re not a master at the craft yet and at some points you don’t know what to do next, one of the best things you can do is find someone that has already gone through the process and you can ask them questions on what they did and how you should approach your future. I have a friend actually that graduated from Worcester State with a Computer Science degree, where I plan to graduate this coming May and also graduate with a Computer Science degree, and I asked him a bunch of questions regarding what he did after graduating and what are the steps I should take so I can get a well paying job and be able to be successful for the coming years. He gave me some pointers and what I should know for interviews and stuff so he was very helpful in that sense, still finding internships and job opportunities will be a challenge in them selves but I will cross that bridge when they come.

The pattern itself wasn’t really thought provoking because as I said earlier, finding a mentor is kind of self-explanatory. You got there, find someone you consider to be really good at the craft and you ask them if you could learn from them if you aren’t too intimidated by them. If you’re too intimidated by them, just ask them out to lunch or something and generate questions to find out what you can do to better yourself in the craft. This pattern could honestly be used for many different subjects such as business, teaching or being a doctor. All those jobs have people learning under people that have already mastered the craft and are willing to teach them so they can succeed them when they retire. The pattern has not caused me to change the way I think about my major as I know one day, I will have to find a job such as an internship and learn from my experiences there, hopefully from someone really good at computer science and willing to share information with me. Finding a mentor is just one step in the journey to becoming one of the best computer scientists out there as to become the best, you have to learn from the best. Thank you for joining me this week on benderson’s blog!

From the blog CS@Worcester – Benderson's Blog by Benderson's Blog and used with permission of the author. All other rights reserved by the author.

Going Deep

The Deep End describes the situation where you feel like your skills have plateaued and you are having difficulty finding ways to improve. As it sounds, The Deep End is a pattern that encourages you to “dive in” to the deep end. That is, to take challenges that you know you could fail, knowing at least that you can learn form your failures and improve yourself as a result. It is not about taking uncalculated risks or lying to get opportunities, it’s more about taking on things that you aren’t certain you could do, but have the means to do so.

The Deep End is a pretty intuitive pattern. When you feel like you aren’t improving, push yourself in ways you haven’t before and turn it around. However, it can be very intimidating in practice to take on projects that you aren’t certain you can complete, especially if you think you have to worry about potential consequences. Although learning from failure is a very effective way of learning, it can also be very costly, and that definitely gives me anxiety.

That being said, it is important to take risks and leaps in my life and my career. It is the only way I am going to improve myself and get what I want, and being too nervous to take chances and opportunities as they come my way certainly wont help. I will make note of the lessons taught by this pattern and try to take more risks in the future. I think it will especially help me with my directed study this semester, which has begun to push me into learning many new languages and concepts all at once.

The Deep End is a cool pattern, and the it makes sense practically. Most people are definitely aware of the idea of taking on harder tasks to sharpen their skills. Most people want to improve, but it can be scary to tackle hard challenges and face the unknown. However, getting over that anxiety is crucial to becoming a smarter, more well-rounded individual. Life isn’t easy, and you need to be ready to solve hard problems at any moment.

From the blog CS@Worcester – Let's Get TechNICKal by technickal4 and used with permission of the author. All other rights reserved by the author.

Reflecting on “Apprenticeship Patterns” – The Deep End

Overall, I consider myself a person who tends to enjoy my comfort zone. I appreciate settling into a routine, whether this routine appears in my part-time job or is reflected in my academic projects. But is remaining stagnant the best decision for me, going forward into my career? Probably not, considering that I want to grow in knowledge as I gain more experience in the field. This week’s apprenticeship pattern, called “The Deep End,” provides more insight about how I can nip stagnancy in the bud, so that I can break away from a more comfortable routine and challenge myself further, becoming more confident in myself and my skills at the same time.

The problem that The Deep End aims to solve is one that I’ve started to already describe. As I spend more time in my career, I may become concerned that establishing a more mundane routine (like sticking to familiar projects which keep me in my comfort zone of work) is not the ideal choice if I want to continue to improve my skills.

In order to fix this issue, I need to jump into the deep end. To do this, I should seek out projects or other opportunities that are challenging enough that they are straying away from my comfort zone. I need to also understand that this sudden change to more difficult work can come with risks, including the possibility of failure. This balance of striving to test myself with different, tough tasks, while keeping an eye on my progress so that I am not in over my head, must always be maintained. If the likelihood of “drowning” continues to increase, it is also essential that I have the capability of reeling myself back in and find help if needed.

I completely agree with everything this pattern encompasses. Even though it would be nice for me to remain comfortable with the work I am doing, I know that it is imperative for me to continue tackling difficult problems and projects so that I can remain at the top of my game and keep my skills fresh.

Thanks for reading!

From the blog CS@Worcester – Hi, I'm Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.

Diving Deep

This series explores Apprenticeship Patterns by Adewale Oshineye and Dave Hoover. This week, I decided to read the apprenticeship pattern “The Deep End.” 
To be completely honest, most career opportunities that are on the horizon are somewhat intimidating. I wonder if I have the ability to do a lot of the work they require. The chapter talks about getting into a rut, but my rut is working fast food. Making a transition to a career-oriented position is a big step, and it is a bit out of my comfort zone.
Instead of reluctantly accepting a task that I am not confident about, I should have the self-assurance to jump in at the deep end. This gives me permission to take on a task that might seem daunting when it presents itself. This is easier said than done, and I find it hard to entirely  abandon my initial timidness.
It is important to note that they also warn about getting too far out of your depth. It is okay to jump in the deep end, but “you still need to remember that if the water level is above your head it means you’re drowning.” This is key. They offer two other patterns for helping with this, which is “Finding Mentors” and “Kindred Spirits.” The titles seem descriptive enough to give a general sense of what you might need to look for. Perhaps one of these will be the topic of a future blog post to dive in more in depth.
The action it suggests is to measure the biggest projects I’ve accomplished based on a few factors of complexity. When the next project comes along, see how it compares. It claims this is a good indicator of where my career is heading, and it might be the basis of choices I make.
Already, when thinking of mapping my projects like this, I think to myself, “I need to do more independent projects.” I’ve done quite a bit for school, but I haven’t done anything incredibly ambitious on my own. I have vague goals of what I want to do, but I have done few concrete steps to fulfill them.
Most of my goals for independent projects are somewhat formidable at this point in the game. For example, I would like to make some sort of a web app that I would have to develop full stack. I have a few ideas in mind for what to do.

From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.

MINIX3: Scheduler Research II

I’ve had to change my approach the past week or so with this independent study. When confronted with the source code, I think I began to feel overwhelmed by the amount of concepts I had to dive into. As a result, I attempted to take it from square one and relearn many systems concepts while also working on understanding the scheduler. As it turned out, this was a bit stressful for me. So I have decided to instead look at the relevant source code and, line by line, take notes learn things as they come. Perhaps this is the traditional way to handle diving into a large system of work, but since I don’t have a large amount of experience in large-scale work this is a learning process for me. It seems that this new direction is working a bit better for me.

Let’s start with /minix/servers/sched/main.c. The main() function is the primary function of the scheduler. When a message is passed into the scheduler, the main() function defines variables for the message, system call number, the caller’s number, and the result of the system call. Then, it enters an infinite loop. This loop saves the message’s info in the variables that were defined for it, and then checks for special situations such as system notifications, etc. (I’m not totally positive on the function of that, but it says that the balance_queues() function is called in this event.) Then, based on the call_nr (the system call number), a switch statement determines what call from /sched/schedule.c should be executed next, with functions like do_noquantum() (which executes when a process is out of quantum) and do_start_scheduling() (which seems to start the scheduling of the process). So long as the process is executed correctly, a reply is sent back that communicates success, and the loop continues on to the next kernel message.

So hopefully soon, I’m actually going to start tinkering with the scheduling policy and see what I can come up with. In the scheduling report I discussed in my previous post, it was suggested that with the current interface a Round Robin, Priority Scheduling, Staircase Scheduler, or Rotating Staircase Deadline algorithm can be easily implemented, so I’ll learn one of those and aim for that. I’m sure it’s going to take me longer than just a week to fully implement, but we’ll see what kind of magic I can work. I’m also sure I’m going to have to write a couple more of these research-related blog posts before I fully understand the workings and can proceed forward, but having changed my plan of attack, I’d like to finish those this week. Ready to move forward once again!

From the blog CS@Worcester – James Blash by jwblash and used with permission of the author. All other rights reserved by the author.