On the semester

Well for my last blog of the semester I figured I would give some thoughts on the semester and my experience blogging. I don’t anticipate this to be very long but here goes. At first I was unsure what to make of blogging as I had never done it before, but as I got into it I thought that it is a great idea to get your ideas out there and to have others see what you’re up to and what the latest testing and development tools and techniques you have been using. It seems to be great as well for others to possibly give feedback on what you’ve written or input on experiences they may have had and can give advice on how to improve on what you have been doing.

That being said, as far as having to try and come up with something to write every week after checking out 5 blogs on testing and picking one that seems to be interesting to you ended up feeling more like a chore to me. I am not saying I didn’t learn anything or that I didn’t enjoy seeing what types of testing styles and techniques folks are using in the industry as I have never worked in the industry as of yet and it gave me a glimpse into what I might be working with and getting involved in possible. My main issue was that I was writing about something that I have had no practical experience in so it was hard to talk about something I haven’t used. I mean it was fine for a few blogs, but after writing about testing techniques that other people are writing about, you begin to realize that there seems to be only so many things and a lot of the blogs talk about similar things or experiences, just in different companies or settings. The name changed but the test stayed similar.

Overall it was a great learning experience and I would take any of it back and I hope that some of you had a good experience as well and it was a pleasure to spend the semester with all of you.

In memory testing

I really enjoyed this blog because I had never heard of in memory databases before this. They do however make sense to me. I had always thought of databases as their own unit, but never really gave much thought to an in memory one. The fast access for certain programs makes a huge amount of sense and I can see the uses for them as he gave examples of routing tables and event poster.

What was interesting is that I can see the use for things such as router tables, but didn’t give much thought to the testing uses part of it. Databases can be overwhelmingly large and when it comes to testing, I imagine that that size comes with a cost, speed. In comes in memory databases to the rescue. It drastically reduces the time to test because of the speed that memory works at which in my mind can increase the output of the product possibly.

I think that if I ever do a lot of testing this is something that I may indeed try out. You can read more about it here:

http://www.martinfowler.com/bliki/InMemoryTestDatabase.html

On bug prevention

I really enjoyed this blog. The main theme more or less was can bugs be prevented? He goes on to talk about how in testing we go at the software from many different angles looks for bugs, but just how often is it that we actually think about preventing them and are they actually inevitable and can they even be prevented in the first place? While bugs are inevitable he believes that they can be somewhat prevented and after reading his blog I believe he is right.

He goes on to explain the general things we can do about prevention such as better communication, trying to make less mistakes in the code, understanding the platform that is being worked on and the list goes on. The main question he asks is this; What can a tester do to help with bug prevention? Testing happens usually after the bug is already in place and it is the then too late to prevent the bug right? Well maybe not. He goes on to say that the testing and the results report can actually influence the teams thought in some areas or things. He says, “For example, something as ‘innocent’ as an email saying: ‘I’m planning some testing of feature X and I wanted to make sure I’m not duplicating work on this. What kind of unit tests have you done on this?’ can gently nudge coders to think about unit-testing their code (and the bug prevention benefits that come from writing code that is unit-testable in the first place).”

I really enjoyed this blog as he makes many good points and if I am ever in the tester role I will surely take some of his points to heart.

You can read the full blog here:

https://offbeattesting.com/2016/12/13/preventing-bugs/

Software Project

I figured that I would start a blog about my software development project that I am doing in coordination with another classmate. I have to say that I was very excited about this because up until now, aside from a few projects of my own (small to say the least), I have never been involved in really working with someone to create something from idea to release. The finished product will not be complete by the time it is due but we will continue after classes end to complete it. We are using the agile development process for the project which is nice because we don’t necessarily have to have the whole project complete all at once, but instead base it upon what is important based upon the client’s need and timeframe.

On to the project. We are creating a web application called Web Hall Pass which is based on a program a teacher at Leicester high school developed in Visual basic, but wanted it redone in a different language so it could be used on a server. What the program does is allow students to check out to the bathroom, principal, gym, nurse, etc. and generate a hall pass either by printing it or the student can take a picture with their phone via the program which is running on a computer in the classroom. This is good in that the student can get up and check out when he/she needs to go somewhere without interrupting the teacher mid class.

After discussion we chose a PHP web framework called Laravel that uses the Model View Controller (MVC) architectural pattern. There are some challenges because neither of us have ever used this before so a lot of reading and doing tutorials was a necessity. Once we got the basics down, working with the framework didn’t seem as intimidating. The great thing about Laravel is the ease of creating tables, and html pages(blades) and how seamless the integration is between the framework and the database. You run commands using PHP artisan to create models, controllers, migrations and too much to discuss here. That being said we have barely scratched the surface of what is capable. The nice thing about it is that it takes away the daunting tasks that you face in just using PHP alone. Validation, security, authorization and more is already taken into account with Laravel, where as in PHP you have to write all of that.

The main thing I think that I see with web frameworks is that they allow you to go from idea to release faster than ever, and as we all know time is of the essence.

Tackling your to-do list

Ok so this week I found a blog that was fairly insightful to me. It was on tackling a to do list. I find that I have a hard time at this and I think it is partly because my mind wanders around and I get an idea or thought and next thing I know I am off to the races on something completely different than what I was just doing. So this guy talks about 8 strategies to help getting your list done and I think I am going to try and put this into practice.

1       Priority

The idea is this, the whole list is not a priority and just doing the things on the list and marking them as done does not necessarily determine your progress, focus on priorities.

2       No second thoughts

Do not overthink things or starting your project. Jump right in and get it going. This is by far one of my not so good qualities, I tend to overthink everything and make it far more difficult than it needs to be.

3       Limit distractions

This is another biggie for me as I can easily get sidetracked. Focus on the task at hand. Whatever that something is that is distracting you now can be taken care of later.

4       Learn from mistakes

I am a proponent of this and I think it is key no matter what environment. Mistakes are unavoidable, it’s what you do with them or about them that counts. Learn from them and move on.

5       Set a short-term goal

Making a goal helps to force us to get things done.

6       Break big activities into small pieces

Do not overwhelm yourself because of the size of the task, big problems are best solved by breaking them down into smaller, easier manageable tasks.

7       Fire the perfectionist

Do not demand perfection because rarely if ever is it going to be or ever will be perfect. He quotes Voltaire who warned against letting the perfect be the enemy of the good. You will never make a perfect decision.

8       Think about it

Very important. Replace counterproductive thoughts with positive ones that help motivate and keep you on track.

Links:

http://www.franksonnenbergonline.com/posters/8-ways-to-tackle-your-to-do-list/

http://qahiccupps.blogspot.nl/2016/11/the-anatomy-of-definition-of-testing.html

https://testkeis.wordpress.com/2016/11/14/back-end-and-front-end-validations/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+mottestingfeeds+%28Testing+Feeds+-+Bloggers%29

http://blog.coverity.com/2014/11/14/dissecting-19-year-old-bug/

https://testkeis.wordpress.com/2016/11/14/some-basic-stuff/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+mottestingfeeds+%28Testing+Feeds+-+Bloggers%29

Whether or not to use old test data

This week I read a great blog on starting from scratch or using old test documentation. The writer formed the blog based on a question asked by one of his fellow testers, “How can I find old test documentation for a completed feature so I can re-use those test on a similar new feature?”.

My initial thought was that’s actually not a bad idea, but the more I read the more I was swayed and started thinking about times when I was either asked about a similar situation or posed the same question. Though I wasn’t software testing at the time nor even in the industry this can be applied to other scenarios as well.

While I do think that it is a good idea to track and refer to past tests to see what has been done, I agree with the writer that “a skilled tester can usually come up with better tests…today, from scratch.” He makes many valid points and I will go over a couple that I thought to me stood out, you can read the blog to get the rest if you’d like.

• ·         A skilled tester knows more about testing today than they did last month.

         How true. The more you do something the more you learn about it and the better you become at          it.

• The product-under-test is different today than it was last month.  It might have new code, refactored code, more users, more data, a different reputation, a different platform, a different time of the year, etc.

          As the development process moves through the different iterations, things change. Looking at             past tests may help, but more probably than not it will probably slow you down. You have first           locate the tests that were done and figure out what the tester was thinking if it wasn’t you, and             then try and decide whether or not it even applies to the new code. By the time you figure that             stuff out I would imagine you could have written several test cases according to the latest                     iteration.

• The test environment might be different.

          This is true as well, things seemingly change frequently so you may have changed the                         environment and once again wasting time seeing what you or someone else did.

The bottom line here is that while in some cases the old data may help, but more than likely it will, in my opinion slow you down. One more thing I think can happen is can stagnate your thought process as you are looking at old ideas instead of coming up with new ideas.

http://www.testthisblog.com/2016/03/start-from-scratch-vs-old-test.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+EricJacobsonSoftwareTestingBlog+%28Test+This+Blog+-+Eric+Jacobson%27s+Software+Testing+Blog%29

http://www.testthisblog.com/2016/03/couple-automated-checks-with-product.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+EricJacobsonSoftwareTestingBlog+%28Test+This+Blog+-+Eric+Jacobson%27s+Software+Testing+Blog%29

http://www.testthisblog.com/2016/02/automated-checking-is-very-human.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+EricJacobsonSoftwareTestingBlog+%28Test+This+Blog+-+Eric+Jacobson%27s+Software+Testing+Blog%29

http://www.softwaretestingmagazine.com/knowledge/how-to-give-better-code-reviews/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+SoftwareTestingMagazine+%28Software+Testing+Magazine%29

http://www.developsense.com/blog/2016/05/testers-dont-prevent-problems/

Insights from the Test Obsessed Blog

This week I found the Test Obsessed blog interesting. The title of the post is “I Prefer This Over That’. The blogger goes on about a tweets she had made about her preferences. They are: Recovery over perfection, Predictability over commitment, Safety nets over change control, and Collaboration over handoffs. I will talk on just two of them and if you seem interested check her blog out at the bottom of this page. It will be the first in the list.

·         Recovery over Perfection

The overall gist of this is that something will go wrong. Basically the software might not do what its suppose, the server may crash, or any other plethora of things, but the key is not to aim for perfection otherwise you’ll be too afraid to actually deploy. She says basically that there is the plan B. Make sure you can roll back if the deployment fails, and update the software quickly if it behaves badly.

I like her idea on this as I often find myself trying to perfect things only to have a setback along the way and end up mildly discouraged. She makes a good point and I will try and put this into practice. I mean nothing is perfect, there will always be some sort of speed bump. The question is will you be prepared? As long as you plan for unforeseen events all should be ok.

·         Collaboration over Handoffs

The overall theme of this is pretty straightforward. Instead of passing the buck and blaming others for issues that go wrong over bad communication, work together on issues.

I may not have any experience in the programming world as far as employment, but I will say that it never ends up pretty when you hand off work or a checklist to someone without actually going over it with them. Something generally goes wrong, the boss gets ticked, starts yelling and people look for other people to blame. It all comes down to communication and collaboration. I mean when you are at work you are all supposed to be on the same team, not a bunch of solo artists. I have seen it work beautifully when the team works together and communicates. So much less stress involved and I think that this comes into play in the programming industry when multiple people are working on different parts of the whole. If there is no communication or bad communication things go wrong and you end in a mess of in fighting.

Here other points are well written in my opinion and hit the nail on the head. A lot of it is common sense, but we all lose sense at times and need to be grounded. Overall I thought there were some good points she made and I hope that you think so too.

http://testobsessed.com/2015/05/i-prefer-this-over-that/

http://www.satisfice.com/blog/archives/1649

http://agiletesting.blogspot.com/2016/10/creating-ec2-and-route-53-resources.html

http://martinfowler.com/articles/refactoring-adaptive-model.html

http://testertested.blogspot.com/2014/06/a-question-on-exploratory-testing-from.html

A bit off topic on Agile

I think this week I would like to go off topic and talk about Agile development or Extreme programming. I believe we were able to stray off for one blog if I recall correctly. Up until now I haven’t really given much thought to actual processes for design patterns and how an actual project is created using Extreme programming and test driven development. I am finding that I may have to take a step back rethink what I have thought to be the way things were done. As I have zero experience in an actual programming position in a company and only know what I read or learn here at school, I find that I am having to rethink things out often. Anyways my thoughts on TDD and XP. I am finding some of the concepts hard to grasp, not intellectually, but just in a common sense strategy sort of way. We just finished a lab on TDD and XP and the method of programming to me seems counterintuitive in ways, but I think it is just because it is new. I do like the idea of writing a test and then the method and just doing the basics to get it to work and building from there. I have never given this much thought, but hey if you write the test you know what to code for so it’s pretty cool. I also will have to get use to the idea of not using inheritance when possible and using many smaller methods to make up the project as whole. I don’t think I will have too much of a hard time adjusting to that though as I think that this is a very effective way to do things as it is easier to compartmentalize when there is an issue with the code and to track bugs down I would imagine as each small part is part of a whole so you only have to weed out a small potion and make changes instead combing over mass quantities of code. Over all I think that once I get use to this way of thought it will only help to make me a better programmer.

On learning

As I made my way through some blogs this week, one in particular really stuck with me. It is a testing blog, but the post the blogger made wasn’t really necessarily about testing, well not any method of testing anyhow. It was about learning. What struck me about it is this. I sometimes wonder how I am going to actually make sense of everything I am doing in school and how I am going to put good use to the skills when I graduate and how can I better my skill set in ways beyond coding, testing etc. The blogger starts out by saying that she likes to learn and she thinks of testing as an exploratory process and that testing is a learning activity. She has some really good ideas that I may try in the near future. She speaks at conferences and such and learns from the people she meets there and recommends going out and volunteering to help set up and organize a meet up or volunteer to speak and such. I have been to meet ups and try to go as often as I can with my schedule, but have never thought about volunteering to set one up or given much thought that it is actually a learning experience in itself. I have started to do more I this area at school with trying to get the ACM chapter going with the help of some peers and faculty and I can’t wait until it happens. I see good things from it and it can only benefit people. I am always looking for new ways to learn something or new ideas on programming and I wonder what other people do to help become better at what they do or to better themselves. Ultimately I would like to get into a mind set that the blogger has about testing and think of it as a learning activity. That and other things and challenge myself to find new ways to learn.

Here are the links of my weekly reads:

http://visible-quality.blogspot.com/2016/10/sharing-is-way-of-learning.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+mottestingfeeds+%28Testing+Feeds+-+Bloggers%29

http://james-willett.com/2016/10/finding-the-balance-between-unit-functional-tests/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+mottestingfeeds+%28Testing+Feeds+-+Bloggers%29

https://www.stickyminds.com/print/article/testing-unexpected-shift-right-devops-testing

http://feedproxy.google.com/~r/mottestingfeeds/~3/R8IdhiiCjUI/

http://testavimas.blogspot.com/2016/10/how-can-i-break-it.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+mottestingfeeds+%28Testing+Feeds+-+Bloggers%29

My take on Agile

In my blog exploration on testing I see that it seems that testing has changed in how it is done over the years. I am still green when it comes to testing and well the development process in general so I can only speak on what I read about and the limited testing that I ave actually done so far. I am looking forward to see how this blog evolve over not only this semester, but my career. For this week I chose to talk a little about Agile development and testing.

I have noticed in a few articles that some companies, well maybe more than some have split teams that don’t communicate with each other effectively or at all in some cases. When I say teams I am talking about testing and dev teams. What happens is people end up passing the buck when something doesn’t go right or the customer runs into issues with the product. What I like about the Agile methodology is that the testers or at least someone from the team is in with the dens so unit testing can be written when they decide to make changes to the code or what not. The blog article that I read had explained that in the company talked about there were big issues because there wasn’t any transparency between teams for a while and that once they adopted the agile style, things started to turn around.

All in all, from what I can gather this seems like a great ideology to follow and lends to a better office environment and better over all cohesiveness. I look forward to actually putting some of these techniques into practice in the future and get excited as I read and do and learn more every day.

Defining Agile:

https://thoughtsontest.wordpress.com/2016/09/27/defining-agile/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+mottestingfeeds+%28Testing+Feeds+-+Bloggers%29

Software Testing Help Blog:

http://www.softwaretestinghelp.com/agile-retrospective-meetings/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Softwaretestinghelp+%28softwaretestinghelp%29

Write Clean Code For Your Tests:

https://iamalittletester.wordpress.com/2016/09/27/write-clean-code-for-your-tests-by-using-the-separation-of-concerns-principle/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+mottestingfeeds+%28Testing+Feeds+-+Bloggers%29

The Evolution of The Testing Pyramid:

http://james-willett.com/2016/09/the-evolution-of-the-testing-pyramid/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+mottestingfeeds+%28Testing+Feeds+-+Bloggers%29

My Unexpected Journey To Becoming a Tester:

http://www.softwaretestinghelp.com/my-journey-to-becoming-a-software-tester/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Softwaretestinghelp+%28softwaretestinghelp%29

A review of some testing techniques

I have been doing some reading on different testing techniques and will briefly go over a few of them here this week. The first is pair testing. I had never heard of this before, but the concept is rather simple, which I will quote from the blog. “If you have an idea, give your keyboard to your pair and explain what you want to do.”, so basically you pair up with someone and one of you outlines what the test needs to do and the idea behind it and the other person writes and performs the tests and vice versa. I think that this could definitely be useful in certain circumstances. I often have ideas on things and how I would like to do them but sometimes find it hard to actually get it out and end up getting insight on how to do it from a friend or colleague.

The next thing I came across that I found interesting was a blog on Javascript unit testing automation using React components. Facebook describes React as “ A Javascript library for builing user interfaces.”. The component that the blog talks about is the React TestUtils component. There are a couple of ways the utilities are used. Rendering them into a Document Object Model(DOM) or Shallow rendering. Using the DOM method, the component you are testing gets loaded into a fake DOM making it able to run the tests you want on your component. The Shallow rendering on the other hand didn’t seem to be as useful. It allows testing without the DOM, but only allowed testing of an output component. I have some experience with Javascript so I plan on possibly taking advantage of some of the test utilities when I do.

Next up on the list is test driven development. This concept seems to me to be an effective testing technique. If you can come up with tests for what you want to build it can make it easier to actually build in a sense. I have barely scratched the surface of this methodology, but am looking forward to learning more about it. In the introduction the writer described two rules. 1. Write a failing automated test before writing any code. 2. Remove duplication. How to use those two rules is the narative of the book and I cannot wait to dig in farther and keep you updated as I progress through the book, Test Driven Development: By Example.

A Haiku by Amanda Shankle-Knowlton I thought was pretty good that to me makes sense.

I will work through lunch

Stay late, tracking down a bug

Just to hear “good catch”

The last testing strategy I would like to learn more about is Oblique Testing. Apparently the concept was used by a music producer to make artists try something new. The testing method provides a set of cards that are based on fictional reviews for the application. The method is mainly using mobile apps, but can be used in other applications as well. The full software dev team is also involved and not just the testers. This seems like an interesting take on testing that I will definitely be gaining more insight on in the future.

The following are links to the blogs or titles of books.

Pair Testing:

http://lisacrispin.com/2016/09/22/pair-testing/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+mottestingfeeds+%28Testing+Feeds+-+Bloggers%29

Javascript Unit Testing:

http://blog.testproject.io/2016/09/21/javascript-unit-test-automation-react-components/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+mottestingfeeds+%28Testing+Feeds+-+Bloggers%29

Test Driven Development:

Test Driven Development: by example, by Kent Beck.

ISBN: 0-321-14653-30

Haiku:

http://amandashankleknowlton.blogspot.com/2016/09/testing-haiku.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+mottestingfeeds+%28Testing+Feeds+-+Bloggers%29

Oblique Testing:

http://www.softwaretestingmagazine.com/knowledge/oblique-testing/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+SoftwareTestingMagazine+%28Software+Testing+Magazine%29

My First Blog Woohoo

Well as the title says this is my first attempt at blogging and I hope that I can share some great stuff that is of use to you. For now I will stick to a weekly blog on anything and everything Software Testing for class and see how that goes. I may venture into the unknown and blog on my other classes as there may be some nuggets of wisdom on Data Mining, Software Development, and anything CS related.