Sustainable Motivation

For this week’s blog, I chose the Sustainable Motivation pattern from the Apprenticeship Patterns book. The Sustainable Motivation pattern is about keeping your motivation while working in the industry. While working in the industry, things can get tedious, real projects are more rigorous and can be exhausting and often frustrating. As an apprentice, you will encounter these problems while developing your technical skills. You will often find yourself working in the messy specified projects for customers with the always changing demands.

Of course, there are times when you love your job, and your ability to write code seems too good but they will not be your ordinary days. Most of the time there are going to be nasty problems, bugs, and to add to that, your manager wants it soon. That is why you gotta stay calm and focus on the long road. You will most likely stay in the craft because of money and would try to endure the long road. While sticking with it, you then find your love for programming returns. It is going to be a cycle of love and hate relationship. Many programmers get trapped by their motivation. Learning something new gets harder and you see no point in doing so when you are already getting paid for the things you already know.

I totally agree with this pattern. There are going to be an up and down moment while working, I’ve already experienced this problem with my current internship. As an intern, they do not really expect you to do a lot. They do not expect you to actually contribute much to anything they do but expect you do to what is minimally expected of you, and most of it is learning. In my internship, I usually finish the task that was given to me earlier than expected. I would always try my best to finish it without wasting time, and always check with my supervisor if it is what they wanted, but sometimes they are also busy or are not around so I am stuck there with nothing to do. What I do in such situation is go to another department or another employee, then I would always ask if there is anything I could help them with and try to learn new things.

Test Case VS Test Scenario

For this week’s blog, I chose to read the Test Scenario VS Test Case from the softwaretestinghelp website.

Test Case – a concept which provides detailed information on what to test, steps to be taken and what the expected result would be. It is more about documenting details. It’s important when testing is in another place than the development team. Easier to get the devs and QA team in sync. There is only a one-time documentation of all the test cases and can be easily tracked in the future. Test cases are also helpful to when reporting bugs. Testers have the reference to the case ID’s and do not require mentioning every detail of the case. It is also helpful to new testers since all the test are already laid out.  But it is time and money consuming as it requires more resources to detail everything.

Test Scenarios – a concept which provides a one-line information about what to test. It is more about thinking and discussions rather than listing everything. It is more important when you have a time constraint and most members understand what is happening.  It is better because it can save time and makes everybody think about what to test. A good test coverage can be achieved and it reduces repeatability.  But, if created by a specific reviewer or other users, they might not be in sync and cause confusions. This type of test also requires more discussion and team efforts.

I think this is a great read as it talks about the standard or old way of testing against the preferred testing by the new generation of software testing community. Test Case is the standard way of testing systems. While using a Test Scenario is new, it offers easier documentation when it comes to testing (assuming everybody understands what the system does). Although it seems like it is not beneficial since most companies change employees here and there, I can see test scenarios saving a lot of time just in the documentation. Learning about it opens up a lot of possibility in the way we think about testing but then again, there are already automated testing so test scenarios might not offer much in the future.