For my final blog post this semester, I want to discuss my personal in class experience.  During the last class, our Software Testing and Quality Assurance class did an in class code review that I found to be very interesting.  Basically, were given some code for a solitaire game and were told to individually look through it and record our feedback.  At the start of the class, the team leader put all of our issues we each found together into one sheet.  We then all projected the code/issues on the wall and discussed our findings.  It was very interesting to me how many different things we all found when looking at the same piece of code.  For example, the problems with the code that I found mainly had to do with the visual display of the program.  While, someone else in my code had issues with the programming style and suggested to use a Driver class.

As a developer, you will quickly learn that there is a million ways to do everything.  Although one way might work, it doesn’t mean it’s the best way or the way it “should” be done.  Practicing clean, elegant, efficient code is a huge part of programming.  You need to not only make the program do what it’s supposed to, but also properly comment, come up with good names, have good spacing and much more.  A messy program is much more prone to problems that will be unresolved or difficult to fix; especially in the real world where there will always be multiple developers working on the same stuff.  I found this activity to be a great learning experience.  I enjoyed being part of a code review and having some input into what I thought could be better about the program.  I hope to do something like this again next semester before I’m off into the workplace for real!

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

Week 11, I found the blog that talks about the Software Testing Clinic and what exactly it is.  I have never heard of this clinic until coming across this blog so it was very interesting to learn about it.  Basically, the Software Testing Clinic is an environment for people who are new to software testing and or want to enhance their skills that they already have.  The all day clinic consists of a team of mentors/senior testers that guide people how to be great testers.  The mentors are available for questions at any time. There is also meet-up sessions in which the mentors hold interactive exercises, discussions, and whiteboard lessons.  The meet-ups will cover things like how to do well in an interview, automation, testing tips, communication skills, note taking, and technical testing.  2017 is actually the first year that they will be holding an full day clinic, in which they will be able to cover much more then they usually have time for.

I found this testing clinic to be an awesome idea.  This is a great way to educate new testers and to give them all of the knowledge they will need to be successful in their careers.  This is an all day workshop that seems to be a fun way to learn the proper skills you need as a tester.  Although the idea of testing seems easy, there is a lot of things that go into it that you wouldn’t necessarily know if you weren’t taught the correct way.  The fact that you will be able to talk and meet with both experienced testers, and people just like you who are starting out seems really cool.  I wish I knew about this before I started my first year at my internship.  A clinic like this would have been very beneficial.

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

For week 10, I picked to read a Quora blog answering the question, “is 30 years old was too last to start a career as a developer?”.  Reading through all of the responses gave me a good indication of both what a bunch of engineers thought about this question, and also what I thought.  The majority of the responses said that it is never to late to learn something knew.  There was one response in particular where a grad student at Stanford talked about challenges regarding starting a career so late.  These challenges included difficulty in interviews.  He said that if you decide to all of sudden change your career, you will have to be prepared to answer those type of questions in interviews.  Also, you might have to face being the “old guy” amongst a bunch of young kids right out of school.  You not only would be older then them, but also you may not be as educated and experienced on the things you are doing.  Many college students have had many years of internships and stuff.  Age discrimination can be a challenge in the workplace, but that doesn’t mean it’s too late.

I personally believe that it is by no means too late to start an engineering career at 30, or any career at that.  To be a developer/tester you only need 4 years of schooling. Although of course it will be more difficult at times to catch up to everyone else, that doesn’t mean it’s not possible.  You can do anything if you are willing to put in the time and effort to do so.  You only have one life so why not do everything you can and always wanted to?  Most people in the workplace are very excepting of everyone, and they wouldn’t judge you because you are “too old”.

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

This week I read a blog on excuses that testers must stop giving.  The first excuse they said that testers give was that they only have read-only permissions, and can only look at the logs.  Testers tend to blame why they can’t figure something out because they don’t have access to it, only the developers do.  The second excuse they give is that they “don’t deploy a build, some other team does it for us”.  The author, Mahesh C., basically was saying that testers need to learn how to do this type of stuff on their own.  If a tester can’t deploy a build because they don’t know how, and all of the developers are busy, the the solution is to learn how.  Testers can learn a lot form something as simple as creating a new build of the product, and seeing why and how it failed for themselves.  The third excuse that blog talked about was that testers say that they don’t debug an issue, they only log it.  However, the author is arguing the point that many of the times the logs will say it all.  A log can pinpoint the exact problem, and that’s exactly where a developer would also go to look.  The fourth excuse is when they say “I don’t know why it happened. Developer resolved it and I simply verified it”.  Mahesh said that as a tester it is your responsibility to ask the developer what he/she did to fix the issue.  It is not good being in a black box and being oblivious to how things work.  Finally, the fifth excuse that Mahesh talked about in the blog is that “I didn’t get the opportunity to work on anything else except for manual testing”.  He basically went on to say that testers need to find the time to do everything and work on time management.  Overall, I thought this was an okay blog.  However, was a bit aggressive, and I felt like it was saying that ALL testers say these things.  The author kind of made testers seem lazy and like they didn’t care which I don’t find to be true at all. He did apologize at the end for being “harsh” but that doesn’t make up for the fact that he was making harsh assumptions throughout the whole thing.

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

For my week 8 blog post I came across a title that read, “Women in Testing“.  This immediately caught my eye, because I am in fact a women in testing.  The majority of engineers are male, so to see something specifically talking about women was interesting to me.  Software Testing Magazine navigated it’s readers to the Women in Testing website.  The purpose of this website is to increase the visibility of women in the software testing field and help them network.  I really liked the whole idea of this site and thought it was a great way to give women testers the credit they deserve.  Women in the engineering field tend to be extremely overlooked.  This website shines the light on women and gives readers a good indication of what we are capable of.

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

Reading up on tips is always interesting to me.  This week I read about some ways to improve your writing skills as a software tester.  As a tester, you spend a lot of your time documenting; whether it’s to keep track of your findings personally, emailing co-workers, or professional documentation.  The blog this week was written by Renuka K, a software tester that has 11+ years of experience.  She discusses how being grammatically correct is extremely important for QA people.  To start off, she gave an example of a small portion of two resumes saying the same thing.  One of the resumes was grammatically correct, while the other was not.  Although the two resumes had the same exact information, one of them seemed like an extremely better candidate for the position.  Renuka stresses how important it is to be grammatically correct, but as a tester you don’t always need to speak so technical.  There are appropriate and inappropriate times to be formal.  For example, if you are sending an email to a fellow co-worker, you don’t nessacarily need to make it sound so professional.  It’s okay to be friendly and non-professional sometimes.  However, you need to make sure you are professional when necessary.  Whenever you are dealing with a customer or documenting something that a customer will see; you need to be professional and grammatically correct.  Some of the tips she shared that can help a software tester be a better writer are;

1. Knowing your audience
2. Read!!! (to write well you must learn to read well)
3. Format your work to make it appealing to the eye
4. Keep it simple
5. Use an active voice
6. Review and edit before submitting
7. Practice every day

These tips were very helpful to me; not just in testing but anything I may choose to do.  It is very important to keep in mind the quality of what you are writing as a tester, not just how fast you get it done.  It is always better to have less of something exceptional then more of something mediocre.

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

I found the blog, How to Solve the Common Web UI Test Automation Problems Using the Katalon Studio Free Toolset interesting this week.  Although I initially had no clue was Katalon Studio was, this blog enlightened me on what exactly it is.  The blog starts off with stating a few things that are common problems found with web UI automation.  It says, “Wait-time issues, Iframe Issues, pop-up issues in automation, and issues in locating deeply nested elements”.  I am pretty familiar with UI automating and I know exactly what they mean when they say wait-time and pop-up issues.  You could have an automation working perfectly, but as soon as one unexpected pop-up comes up; the whole test is going to fail.  It talks about what a simple “wait” is when automating.  Wait is basically a pause in the automation which gives the system time to load or do whatever it needs to do to carry on.  Katalan Studios is a tool that generates test script that helps your automation from failing.  For example, if an alert keeps randomly popping up, you can use Katalan Studios to help you handle those issues.  The blog didn’t go into too much detail about Katalan Studios but it talked about some cool things that it is capable of doing.  Now that I am aware that this type of tool exists, I may even use this tool at work someday!

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

With Halloween around the corner, the blog The Tester’s Horror Stories (Halloween Special) interested my this week.  The blog talked about the different types of things that can be very frightening to a tester.  It listed things like:

• Buggy software
• Inferior Test Environments
• Missed deadlines
• Feel underappreciated
• Breaking bad news
• Catching up newer technologies
• Onsite-offshore model
• Accidentally turned ON/OFF or deleting something
• Low status in the industry

I personally have been a victim of accidentally deleting something.  I had all of my test results recorded for a huge section of the product I was testing.  Unfortunately, I accidentally deleted the file with all of the information and had to redo everything.  It was by far a tester’s worst nightmare.

The writer of this blog tells the story of how he was extremely good at documentation and could get everything written up extremely quickly.  The tester went into work the day after everything was completed as he usually would.  He was called first thing in the morning into a meeting with the manager and was asked why he had written up so many invalid bugs.  The news was already spreading to the client and the manager needed an answer instantly.  Obviously as a tester it is extremely important to always make sure the bug is actually valid before you go ahead and write it up.  However, I liked how this blog more touched on the fact that you need to be able to hold yourself accountable to any mistakes you may make as an engineer.  If your name is on it, you need to take full responsibility and explain what was going on and why you did what you did.  Humans make mistakes and most of the time it won’t be the end of the world, but not owning up to it is a lot worse.

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

This week I decided to read up on Quora instead of an individual blog.  I specifically was interested in the question, “Is Software Testing easier than Software Development?”.  I found Doctor John Miller to have a very interesting and accurate response to this question.  He was the test lead at Microsoft for 7 years, and developed for Microsoft, Google and Amazon for 18 years.  He makes the point that software testing is not easier than software development at all, it’s just different.  A common misconception is that the “less intelligent” software engineers will become testers.  However, Miller says that a lot of the time Software Testing can be more difficult then actually developing the code base.  “Neither job is intrinsically harder. They require different sorts of thinking and different emphasis in code artifacts.”

I completely agree with Miller on his response.  Many of the other responses were saying that software testing is a lot easier then software development.  I find that to be very untrue.  Of course it takes a certain type of mind to be a great developer.  Having said that, you also need to have a certain type of mind to be a great tester.

One of the posts stated:

“It’s certainly true that testing is a lot easier than development. You have to know how to code in at least one programming language to do development. You only have to know how to turn on a computer to start being a tester.”

The fact that people think you only have to know how to turn on a computer to be a tester is crazy to me.  There is so much more to it then that.  You need to be able to 100% think logically to frame test scenarios beyond the box.  It can be incredibly difficult and involved.  I think software testers are very under rated and need to get more credit for what they do.

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

This week I listened to a live talk, “Fixing Performance Problems Using Someone Else’s Toolbox” by a Java expert.  The title of this video was originally what caught my eye.  As soon as I was about 2 minutes into the video, I was a little apprehensive about finishing it.  He basically was just describing what to do when the tools you depend on to test performance are no longer available.  There are tools like JConsole, Visual VM, and Java Mission Control that people usually depend on for fixing performance problems.  The Java expert talking (not sure why he didn’t say his name?!) told a story about his personal experience with a customer.  The customer went to him and said that the whole system is slow, and it’s taking forever just to login.  When the expert went to use his tools that he relies on to fix performance issues; he realized they weren’t working.  He then started to panic a little bit, but he knew that with the knowledge he had, he could figure this out a different way.  He went on to describe a series of problems that kept getting in the way of his alternative solutions.  There were things like the firewall blocking RMX, JMX not being turned on, and the system not having a X server at all.  Although I am not at all familiar with fixing performance issues, the way he went about everything and his thought process was the reason why I chose to write about this talk this week.

As a future software engineer I need to have the mindset that there is more then one way to fix everything.  When your favorite tool breaks, you need to be able to work around that issue even if it’s not the most efficient and convenient way to do it.  This video opened my eyes to the fact that all of these tools that we are so dependent on, are not by any means the only way to get things done.  We are all so used to doing things the easiest way by using tools to make things a lot quicker..but in reality we don’t NEED them.  An example in just everyday life that I can use to compare this to is, say for example your washer and dryer breaks and you don’t have the money to replace it.  Initially you are going to freak out and think, “Great now I can’t wash my clothes, what am I going to do?”  The reality of it is that you are going to have to find another option, like going to the laundry mat.  I know that may sound terrible and extremely inconvenient to have to drive somewhere just to wash your clothes, but it is possible and it’s not the end of the world.  Engineers need to be able to think logically and think about all of the possible solutions to a problem.  Your original solution may work, but what if a major component of that solution breaks?  As a computer scientist, you need to be able to apply the knowledge that you have when a tool you depend on breaks; both in the computer science world and in everyday life.

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