Loadster is a tool designed for performance testing web apps and websites. It was created to be a median between the costlier tools that only big enterprises can afford, and free open source tools. Loadster is designed so that it is easy to create scripts for testing even if new to automation testing or having little coding experience. It treats everything in terms of concurrent users, which are simulated user going through the transactional flow of the website. These users can have different response times, slower connections and other changeable settings, and a report is generated at the end of testing.

Performance testing according to Andy Hawkes is anytime a system is tested to see how it behaves under load, typically with many concurrent users or requests. Instead of testing to see if a section of code does what its supposed to do, performance testing is about stress testing your app and going back to optimize your code so that the app runs more efficiently. It is important to test applications under load because it’s helpful to know how the app will perform when it is being used in a more realistic environment. It is also helpful to know if the application will have significant slowdowns or crashes and what is causing it, if the app can’t handle being under the tested load.

Andy says that tests are only as valuable as the assumptions that went into the test. This is some useful advice since you should be designing the application and tests around about how much traffic your site or application is designed for, rather than an unrelated or unrealistically high or low number. You also shouldn’t be spending too much time or resources preparing the app for traffic it will likely never encounter.

Andy also says that performance testing has diminishing returns, and doesn’t need to be done all the time for it to have valuable outcomes. Instead of doing performance testing all the time and needing to do even more testing when new things are added to an app, it could be done every so often and have similar results. This would leave more time for other parts of the app to be worked on. I’m sure there’s some exceptions to this, but it sounds like this approach would be useful, especially for smaller scale projects.

Podcast link: https://www.joecolantonio.com/testtalks/227-andy-hawkes-loadster/

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.

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.

The introduction talks of beginner developers as apprentices, experienced developers as masters and developing software as a craft. Learning from someone that’s more experienced and being able to bounce ideas off of them is invaluable. Often they will be able to suggest a simpler approach to the problem you’re trying to solve that you would have never thought of that is more effective. It also helps greatly when you’re stuck and trying to find a solution to a problem. It might take five or ten minutes to figure out something with help rather than potentially days or longer working alone. Getting things done in an acceptable fashion rather than trying to get it to be as perfect as possible is definitely something I need to work on personally. Striving for that theoretical perfection takes too much time and leaves too much unfinished rather than just good and done.

With the “Emptying the Cup” story, I agree that it’s important to be adaptable, to quit bad habits and be able to solve problems using different approaches. You shouldn’t think that you’re better than everyone else, but you should still have some pride in your skills. Everyone has something to bring to the table. I also feel that no one should be stuck in their ways, but should instead be open to suggestions. Sticking to a single approach is going to make things more difficult in the long run since you’re closing off paths to easier and simpler solutions.

I feel that “Walking the Long Road’ doesn’t matter as much so long as you’re constantly improving yourself and aren’t in over your head. Wanting a promotion isn’t unusual because in a way holding the position says you have a certain threshold of mastery. So long as one has the skills to be in the position, whether it took a long time with smaller challenges or less time with bigger challenges shouldn’t matter.

I’ve heard the “Be the Worst” approach be applied to many things, but I find that it really is an excellent way to improve yourself. You must go out of your comfort zone and challenge yourself, which often leads to identifying bad habits and finding better ways to go about solving the problem you’re facing. Although I feel that you need to back off every so often to a safer environment so that you can apply those skills elsewhere so they become further improved and refined.

The “Perpetual Learning” chapter gives some helpful suggestions on how to go about learning and obtaining information, but I feel that a couple of the suggestions go far above and beyond. It’s still possible to learn on your own in a much more casual fashion by following blogs, keeping up to date with trends and occasionally participating in something more. Having the constant flow of information would certainly be more effective than an on and off switch of being bombarded by information or not. The “Construct Your Curriculum” chapter also suggests a way to set up a reading list and some book suggestions, which is helpful.

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.

I am Joshua Farrar and I am taking CS-448 during the Spring 2019 semester at Worcester State University.

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.

Welcome to my blog! My name is Joshua Farrar and I am currently a student in CS-443 at Worcester State University.

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.