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.