During this week, my team and I got more organized and set up our work environment. First and foremost, all the teams including ours decided to use the program Slack, which is pretty much a chatting software like Skype and discord but allows us to use different channels to talk as well as other beneficial communication features. We got together in our own channel which was named after our team, Zolinq and started to get everyone together on their as well as pinning messages on our channel board.

When we met up in the beginning of the week, we started to use Trello, a program to manage tasks and improve communication and organization throughout our team. After we accessed the Trello board from our course, I created a Trello for our own team and Kyle copied the tasks from the professor’s board onto our. Later on that week, I organized our Trello into 3 categories “Backlog”, “Doing”, and “Done”. I put all of the cards (tasks that we created for our team to maintain) into the appropriate pile and then decided to make another category for the writing aspects that are due more frequently, such as the blogs and daily scrums.  I learned how to maintain a Trello board for the team which is really cool.

One assignment that I didn’t expect to do was the Daily Scrums, which each team member have to post about their progress on the project so far in our chat channel. I understand why we must do it and the team didn’t upload their daily scrums the first time around since there really wasn’t much to report on. It was a bit unorganized, but now I learned I should have took the professor’s advice by making another channel for our team, specifically for daily scrums. I did that this week so that should not be a problem.

After getting the management duties settled, I started setting up my work environment to start coding the angular tutorial. I decided to do so on my PC first since its more powerful and I wanted to code on it first, so I installed the Webstorm IDE with the free one year license and also installed Node.JS which came with npm. I downloaded the quick start file and imported the project and then ran npm and it all worked well. It was really interesting setting up that environment.

While doing the tutorial, I had issues with the local host page on my browser compile successfully and refresh automatically. It turns out even the slightest syntax error can cause the application to freak out and I had to revert it a couple of times. I have to be careful of angular when i do JavaScript as it feels less robust than java or C++. The syntax for an app environment is sort of new to me but the web elements that I learned from web development was recognizable so I was able to understand it quicker than i thought.

Afterwards, I installed the environment on my laptop and helped my teammates who were having trouble installing it (its worse with different OS) and now we are all on the same page. The next time we meet, communication with my team will be all set, as we also made a Facebook group to keep us up to date with each other’s work. Communication with your team is important, as it was learned in the QA class, and I think we got that down. Next up is more angular and finding out the features we need to build for openMRS.

From the blog CS@Worcester – Dan's Tech Rant by danbarbara and used with permission of the author. All other rights reserved by the author.

In the first chapter of The Clean Coder, the author makes the message clear of what the coder is aiming to achieve and how it may not be the right goal to meet. The first chapter talks about professionalism where the coder wants to be recognized as a professional but may be unaware of the expectations people put on that role. Mainly focusing on taking responsibility that the manager would have done, the author gives examples including  running by code to the QA testers with little or not bugs to maintaining the structure of the code.

This chapter was interesting to me as I never thought to see myself as a professional coder and the higher responsibilities will catch me off guard as I don’t think i will be qualified for it. I wonder if the team will want me to revise their coding approach, they might look at me as a supervisor even though I have no experience with doing so.

In the second chapter of The Clean Coder, the author explaining the importance of saying no. Sometimes tasks take longer to accomplish or may not be possible to do with the given resources, however the higher-ups may not take that into consideration and impose closer deadlines and impossible requests. Developers have to be brave enough to say if something can not be done and give valid reasoning as well. Saying yes will only put more of a load on their shoulders, load that developers will regret if they did not think it through.

I can not elaborate enough on the moral of this chapter. Even after learning about this scenario from watching Office Space, sometimes a person can only take so much and saying no is the healthy choice in the name of sanity. At least take each request into thought instead of saying no right away so show that you care and are being fair, but if you can not do it in the end then no is the right yes. There is always a workaround.

From the blog CS@Worcester – Dan's Tech Rant by danbarbara and used with permission of the author. All other rights reserved by the author.

The first week of my capstone was pretty much just preparation for the project. When I walked into the class, people kept telling me they wanted me to be a team leader. The fact that I missed the first day of class due to having my wisdom teeth removed put me in a completely clueless state as I did not know what exactly was going on. I ended up being elected as one of the team leaders with no clue what i was doing, but i ended up noticing people were picking pairs to work with so i guessed it was a recruitment kind of thing. After the processor told me what I had to do, i ended up picking people for me team as well as the other folks who picked people for their team too. From that experience, I learned some bits of being a recruiter.

Afterwards, the professor told us that we are working with OpenMRS which I heard briefly about. After setting up Slack, a chatting system that makes communications easier for development, my team and I did research on the project as well as AMPath. We worked together to organize the project we have to work on and are currently planning to start learning Angular (a programming language) since that is what we will be coding in.

I should have gotten information previously before going to class since i missed it, i would have been more aware if i read all the alerts on blackboard. This could apply to actually working at a company and not knowing whats going on since I did not ask any questions. Let alone, this act could have injured communication with my team if i kept acting that way. As learning in the level 3 course, communication is important while developer software. Even though the course was talking about QA testing, the same principle of communication applies here too. In the end, I’m more interested in seeing how to approach working on features for AMPath, as i have not programmed with a team before. That will be a true learning curve.

From the blog CS@Worcester – Dan's Tech Rant by danbarbara and used with permission of the author. All other rights reserved by the author.

Hello world, again. If you are not familiar with my blog posts that were posted between the past couple of months, that’s ok. I took a break and I am back to using this blog, however this time I will not be talking about software testing. As part of my final Computer Science course, I am working on my capstone which entitles a software development project where I am with a group of 6 working on features for an initiative called OpenMRS. OpenMRS is a open source medical record software which is currently powerful and expansive with a lot to offer to the world. This blog will be used to document my progress on this project as well as the readings that have been assigned for me to do as well. The aim is two blog posts a week, unlike one blog post a week like last time.

For more on OpenMRS, you can view it their site here: http://openmrs.org/

From the blog CS@Worcester – Dan's Tech Rant by danbarbara and used with permission of the author. All other rights reserved by the author.

“Developer: There is no I in TEAM.  Tester: We can’t spell BUGS without U”  – Dima Al-Adham

At the 12th week approaches, this post will cover what I think is the most important aspect of Software Testing (even development in general) which is to be funny! Yes I know, you may be confused of how being funny adds on to being a Software Tester. Its understandable that there are not any humorous people out there as well and the fact that they even try to be funny might completely turn against them. But as you may –hopefully — have noticed, each of these blog posts are written in a way with a touch of unique personality, right?

” Why did you test it that way? The users should never do that.”  – Herbert L Warren

In the real world, reading a blog full off information about a topic could be boring and can give you stress if you are not able to skim through it since you may be looking for specific information. People who read whatever is written needs to feel welcome and know that everything that they are experience was created by a human being with their own personality. In the end we are not automated robots! In software testing, take a look in the code of the project that you are working on. Take a look at the comments made in the files, does it seems like a robot wrote those to you? When you are making reports that seems stressful and dull to read, do you think your supervisor wants to have the impression that they have robots working for them? In the end of the day we are all human, and if possible a little bit of laughter, even when something is slightly different, is enough to put a smile on someone’s face when they are repeating their everyday job.

“To tell somebody that he is wrong is called criticism. To do so officially is called testing.”  – Gaurav Khurana

Just remember you are a human being, and not just a software developer or a plain worker. In the end of the day, no matter what we go through whether its creating projects or reading a bunch of students blogs, at the end of the day humor is everywhere and can lift the spirits of everyone, like I hope I did when I wrote 12 weeks off somewhat different blog posts with a touch of who I am.

Source: http://www.mindfultester.com/adding-humour/

From the blog CS@Worcester – Dan's Tech Rant by danbarbara and used with permission of the author. All other rights reserved by the author.

There may come a time in your life as a software tester, where you do not know what to test. The guided path that your leader should have instructed you to base of your testing skills off of are completely blank and un-given. What do you do? The answer is simple, you do not take this moment as a stress-full event in your life where you may think one wrong, un-sure move is going to ruin your entire career, but take it as a opportunity so a blank slate with no requirements can turn into a free-style session and let your bug breaking mind run free!

Are you not given what to specifically test for and a strict deadline to go as the cherry? While, you could ask your supervisor for a list of requirements since they have not created them or misplaced the information to give you by accident, but chances are they do not have any and want you to go wild!

But how do you go wild when it comes to testing? Well, when the key phrase “oh i do not know what i am testing for” comes around, as a tester a familiar key term should pop in your head and that is the key term Black Box Testing! You can go crazy finding errors and bugs in a project and by the time the project is done, you have flexed your creativity muscles but enriching the curious experience of being a tester. The best of Black Box Testing can be found here.

Source: https://testzius.wordpress.com/2016/12/13/testing-without-requirements/

From the blog CS@Worcester – Dan's Tech Rant by danbarbara and used with permission of the author. All other rights reserved by the author.

There are many testers in your department, but only a few (in some cases only a very few) are in charge of the heart of all life in the creation everyone is pouring their figurative sweat and blood and a ton of coffee, the database.

Now, first and foremost, you should be proud of yourself. You got the golden ticket from your superior being tasked to defend and maintain what is keeping the company standing with the potential of chaos if something goes horribly wrong, but that’s why you are there to help prevent such a disaster from happening! You are the one that maintains the server contain confidential, very important information (in most cases  a lot of it), but the good news is it’s not as bad as you think!

To communicate with the database, you can simply just write queries in order to talk to the monstrous amount of data. However, if you really want to mess with it because you want to ensure no threats will emerge from here on out, then you would have to make a duplicate server that will not completely destroy the entire company which gives you the perfect opportunity to do whatever you want to it in order to avoid actual destruction of the real database itself!

From using White Box Testing or Black Box Testing, you may need to have more experience with the database to promote effective maintaining of the sensitive information. You have to know the ins and outs of the database as well as becoming the database if you really want to feel a connection of how it behaves. By all means, you can start with database auditing and monitoring. But it’s a long list just to fit in this one post.

Source: http://quality-assurance-software-testing.blogspot.com/2009/03/database-testing.html

From the blog CS@Worcester – Dan's Tech Rant by danbarbara and used with permission of the author. All other rights reserved by the author.

In the world of software development, there are the software programmers and there are the testers. No, there are more than those in the software field but the two that work together like peanut butter and jelly on a sandwich are the ones that code and bring the program to life and the ones that make sure it stays living by making it not fail and fall.

The bottom line is testers are testers because either they wanted to be or ended up in life as a tester, as well as the possibility that programming did not work for them. Same for the software developers, they are who they are because they want to be or either they ended up in that life. In the end, the programmers and testers need each other because one can not work without the other. Sure Testers can be ‘second class citizens’ who are people who can not code well, i’m one of those people. I’m sure that it doesn’t meant that those are the only type of people who are software testers.

Kind of how Kualitatem states, software testers and programmers are hammer and chisel. Not to mention they both equally have challenging jobs that requires a lot of man power. Its kind of like politics with the Democrats and Republicans. Sure they both have different views, but if only one major party exists the outcome of our country would change forever due to one common set of beliefs. One needs the other in order to keep the balance and as well survive.

(source: http://www.kualitatem.com/blog/are-testers-failed-programmers)

From the blog CS@Worcester – Dan's Tech Rant by danbarbara and used with permission of the author. All other rights reserved by the author.

Ever since the dawn of man kind (and possibly before it) communication became the sticks and stones of our interaction with one another where one tower is supported with the other. Now the same applies many centuries later from throwing mud at each others faces and using smoke signals to the effective use of typing on your computer’s keyboard using the magic of electronic capabilities, innovative programs, and of course the internet.

As software tester, you communicate with your team like how your team communicates to you. Your team relies on your findings and looks forward to you, the tester, on keeping them informed in the most effective way possible. For the best possible way of communicating with your team through bug reports and status updates, the most important aspect is to make sure your method of communication allows the repentant to get the best quality from your intended message as possible.

If you are looking forward to improving your communication skills for your testing job, then some tips that would help range from how you structure your reports to asking your self questions of what you are addressing and what the other end would want to read or not receive more can be found here. .

Source: http://www.softwaretestinghelp.com/improve-written-communication-skill-as-a-qa-tester/

From the blog CS@Worcester – Dan's Tech Rant by danbarbara and used with permission of the author. All other rights reserved by the author.

No tester can’t resist a spooky story, even though there may be many of them throughout their career. Sometimes you may get put into a situation where you are taking on a higher responsibility. It doesn’t sound too bad, but in some cases one may get put into that kind of place and they may not end up being qualified. Especially if you are working in a team where they are used to certain methods being done and executed in a way where it is efficient. They may expect you to do the same thing as the person who are covering for is doing, and having high expectations on you can be quite terrifying if you are brand new.

Now, that may or may not happen to every tester but there are many more scary stories out there detailing’s ones journey. Nothing is worse than working on a super-strict deadline as well especially when you have to rush what you are doing with your team (that may consist of many more testers or a very few).  If you make a mistake or over look something during that small time frame you may get in trouble. Testing overall is a stressful job after all, it is the cause of many testing horror scenarios.

Either way, if one does have a bad experience or experiences during their testing career that may be worth a Halloween’s tale, it may not be a complete waste. After all people learn from their experiences and use that knowledge to make better of themselves in the future.  As scary as some stories sound, not all seem to be a complete nightmare, just a really bad work day. Though if you do want to see more frightening things testers go through just for the sake of the Halloween spirit, check out what scares testers the most.

(Source: http://www.softwaretestinghelp.com/what-scares-testers-most/)

From the blog CS@Worcester – Dan's Tech Rant by danbarbara and used with permission of the author. All other rights reserved by the author.