I will be writing a weekly reflection for my software development capstone in order to discuss what i have learned that week as well as my current progress and thoughts regarding the ongoing capstone project.

This is the first post in a series now that the first week of the semester is over. Although we did not do a great deal in the first week i have actually learned quite a bit. We have gone over the SCRUM development process as well as begun to implement it on a hands on project. This was an interesting experience because i have not done anything quite like this before. We have assembled teams of six people to work on parts of an open source project. Going forward it should be an interesting and unique learning experience.

I have also never contributed to an open source project before so i am very excited to begin learning about the project and open source as a whole. Working in actual development teams and submitting our code for professionals to review should be interesting. Hopefully we are able to get some of our code actually implemented into the project but who knows. The project we will be working on is called OpenMRS, and specifically a portion of that project known as AMPATH, which is located in Kenya.

From the blog CS@Worcester – Computer Science Journal by jtassone93 and used with permission of the author. All other rights reserved by the author.

Week 12 blog post for Software Testing

This week i have decided to read 5 Excuses Every Software Tester Must Stop Giving by Mahesh C..

As i am still relatively new to the world of software testing i am very interested in what exactly software testers do on a daily basis. What better way to do that then by looking at excuses software testers make very frequently, it was my hope to gain insight into the software testing world through this article.

The first excuse was “we don’t control our Test Environment, we have limited access”. The article then goes over the benefits of being able to fully control the environment. an example of this being ” You know all involved components, all software used along with their versions for your product to function. With time, trust me you will have many insights about their working, limitations and possible failure points.”. More importantly it discusses how you can actually do this within a team/ organization. They suggest starting to work very closely with a developer team and start to learn how they do everything and once you have shown competence ask them for control and logically they should give it to you.

The next excuse was “We don’t deploy a build, some other team does it for us”. They then discuss why this is a bad attitude to have, and their explanation is something that resonates with me personally. They suggest that deployment teaches you a lot due to it not always working and failing often means you are forced to learn and debug. This is something that i have personally learned, through my own experience.

Then it goes to “We don’t debug an issue, we find steps and log it”. In order for personal growth it is better to ask yourself a few personal questions and make sure the reason for the bug isn’t easily determined.

4. “I don’t know why it happened. Developer resolved it and i simply verified it”. This is somthing i completely understand. Learn from the developer and thenmaybe next time you won’t need them to fix it and you can do it yourself. A lot of these excuses are just plain lazy from ever perspective.

5. “I didn’t get the opportunity to work on anything else than Manual Testing”. There are time actors involved however there is always that extra bit of time where you could do these things. Again this comes down to the testers being just plain lazy.

From the blog CS@Worcester – Computer Science Journal by jtassone93 and used with permission of the author. All other rights reserved by the author.

Week 11 Blog Post for Software Testing

This week i decided to read The Complete Beginner’s Guide to Responsive Web Design Testing by Laxmi

This article was of interest to me because in my Software Construction class i am developing a web application as my final project. Therefore i have become slightly more interested in web design and the testing that is involved with it.

One of the largest issues of this generation is that you do not know if the user will be on a cell phone a tablet a laptop or even a TV and the screen sizes for all of these devices range from 4 inches to 60 inches. Therefore you need to develop your web application in a way that it is able to look good and work properly on all of these devices. they define responsive design as “one website for every screen”. Although it encompasses much more than that. They later go on further to define it as a website designed to have a superior user experience, easy navigation, clear and simple interface, able to adapt easily and work in all resolutions, browsers, screen sizes, hardware, and operating systems.

This is done through flexible layouts, media queries, and flexible media. The issue is how do you test if a website is responsive without pulling it up on all of the possible screen sizes which is impossible to do. This is where software testing tools come in that change the screen size and resolution allowing you to test for a large variety of devices.

As i am developing a web application myself i found this article to be interesting and helpful at the same time. I look forward to optimizing my website using the information that i have learned in order to create a better experience for the user.

From the blog CS@Worcester – Computer Science Journal by jtassone93 and used with permission of the author. All other rights reserved by the author.

Week 10 Blog Post for Software Testing

This week i decided to read what Test Engineers do at Google: Building Test Infrastructure by Jochen Wuttke

As google is a popular company and i am new to the world of testing, this article was of immediate interest to me. I was excited to learn what careers in testing were like and what better way to do that then by a test engineer at one of the most popular companies on the planet.  Although this article does not talk about all the different things that the test engineers do, it only discusses one aspect of their work which in this case is :building and improving test infrastructure to make engineers more productive.”

One part of this is replacing legacy systems. A legacy system at google was costing engineers countless hours that they could be spending elsewhere. A replacement takes a long time to build so they had to continue using and updating the legacy system as they went. However this allowed them to learn from the legacy system and not make the same mistakes in the new system. The engineers found two major concerns to fix in the new system. Those were “Tight coupling and insufficient abstraction made unit testing very hard, and as a consequence, a lot of end-to-end tests served as functional tests of that code. ” and ” The infrastructure used for the end-to-end tests had no good way to create and inject fakes or mocks for these services. As a result, the tests had to run the large number of servers for all these external dependencies. This led to very large and brittle tests that our existing test execution infrastructure was not able to handle reliably.”

Once they had found the problem they had to figure out the solution which is the hard part. After quite a few prototypes and a year of time a few testing engineers where able to build a new tool that solved the problems they were looking to solve. The next step was teh adoption of the new system, which is never an easy process. This process took them a couple of months in order to fully implement. The results were that the new tests were more effective at finding bugs. The new tests ran in 3 minutes compared the older suite running in thirty minutes and the client side tests are 0% percent flaky.

Although i didn’t completely the implementation it was quite interesting to see the process a tester took in their day to day lives.

Here are some other articles that i found interesting:

http://qahiccupps.blogspot.com/2016/11/something-of-note.html

https://blog.tentamen.eu/value-of-ui-automation-tests/

http://qahiccupps.blogspot.com/2016/11/the-dots.html

http://angryweasel.com/blog/teams/

From the blog CS@Worcester – Computer Science Journal by jtassone93 and used with permission of the author. All other rights reserved by the author.

Week 9 Software Testing Blog

This week i have decided to read Understanding The Difference Between Unit, Integration and Functional Testing by Sushma S.
The article uses a login page as an example to help explain the difference between unit, integration, and functional testing. The reason for this is that a login page is extremely common and usually used in most web applications. It then goes over the cases for each type of testing and they are as follows:

Unit Testing –

Field  length for username and password

input field values should be valid

login button is enabled only after valid values are entered in both fields

Integration Testing –

user sees the welcome message after entering valid values and pushing the login button

users should be navigated to the welcome page or home page after valid entry and clicking login button

Functional Testing –

the expected behavior is checked

welcome message after succesfull login

can an inactivated user login

is there a forgot password link

Unit testing is generally done by the software developer who knows the code well. It is important for finding bugs early on in the development process, and is done before any integration or integration testing occurs. “Unit tests save time and cost, and it is reusable and easy to maintain”. After unit testing comes integration testing. After everything has been tested as a unit then integration testing occurs.
This when the units are put together and tested as a whole. This tests how the system works together and verifies that the behavior is correct. Then there is functional testing. This is a black box technique where the functionality of the system is tested. This basically means that we are testing that the behavior of the application and not the code itself. In order to successfully test an application you need to use all three testing methods. This provides the best test suite where any possible bugs should be found.

Here are some other links that i found usefulL:

https://blog.tentamen.eu/cleanup-order-in-selenium-headless-test/

http://www.softwaretestinghelp.com/how-perform-software-product-testing/

http://blog.smartbear.com/api-testing/top-5-api-testing-blog-posts-of-2016/

http://rhythmoftesting.blogspot.com/2016/12/thoughts-on-agile-testing-days-2016-pt-2.html

From the blog CS@Worcester – Computer Science Journal by jtassone93 and used with permission of the author. All other rights reserved by the author.

Week 8 Blog Post

This week i decided to read 9 Ways to Quickly Improve Your Writing Skills as a Software Tester by Renuka K.

As a newcomer to the world of software testing this article seemed extremely interesting to me. The article begins by talking about business communication.

Here are a few definitions from the article that are relevant to the overall message of the article.

Communication: “Communication is a two-way mutual process where one person conveys his or her ideas or messages to the other person. The other person then provides feedback.”

Written Communication: “A way to convey your thoughts or messages using written words or symbols. In case of written communication, the medium is anything that supports writing, like Blogs / Reports / Memos or mail.”

Business Communication: “One of the types of written communication happening in organizations. Written or Business communication can be further divided into Formal and Informal Communication.”

Business Communication can be further divided into informal and formal. Informal is communication that is professional in nature but does not need to be formal. An example would be an email to another person in your department.

Formal business communication: “A way of communicating with the help of written records which are official and professional.”

An example of formal communication is Test Documents or an email to a client regarding the Testing or another process. Formal Business communication can be further divided into internal and external. Internal would of course be within the organization while external would be between the testing team and the client. Communication in all of it’s forms is extremely important. An example of why written communication is important for QA engineers begins with writing a resume and ends with all kinds of testing documentation.

Communication skills can have a profound effect on your career in a number of ways. It helps you get a job or promotion, increases trustworthiness, builds confidence, and enhances relationships.

Now that the article has outlined communication and why it is important to a QA engineer, they go through some ways that one can improve your writing skills.

1. “Always keep in mind the purpose of writing: “

This discusses thinking about what you want your writing to accomplish before you begin writing. Then making sure by the end you achieve these goals through your writing, as well as using diagrams and examples.

2. “Know your Audience”

By knowing your audience you can specifically tailor your writing so that is suits your audience perfectly.

3. “Read Read Read”

Reading is a good way to increase your vocabulary. Reading the types of documents that you will be writing can help you to gather ideas regarding the topic and ways to organize your information.

4. “Formatting your work”

A good format invites readers and gets them interested in what you have written. It organizes information in a way that is easy to read and understand. They suggest the use of graphs and say that you should limit the use of Bold or colored letters.

5. “Keep it simple and easy to understand”

They discuss things such as a logical flow, keeping writing focused, keeping sentences and paragraphs short and clear and using simple words.

6. “Active vs Passive Style”

They suggest using an active voice instead of a passive one. A passive voice can lead to longer sentences and error in the structure of the writing.

7. “Make it grammatically correct”

This seems easy enough however making errors in grammar is very common and can cause a lot of confusion for the reader.

8. “Review and Edit”

This is the most stressed part of any type of writing. Always review and edit your work no matter how small or trivial it may be.

9. “Practice it every day”

With any type of skill practice is the most important thing. In order to get better you need to make it a daily ritual and improve improve daily. Even if you only write a few sentences every day.

Here are a few other articles that i found interesting:

http://curioustester.blogspot.com/2016/10/microinteractions-designing-little_28.html

From the blog CS@Worcester – Computer Science Journal by jtassone93 and used with permission of the author. All other rights reserved by the author.

Week 7 Blog

This week i decided to read Testing in Production: A Double-Edged Sword by Rajini Padmanaban.

This article covers what testing in production is, how it is implemented and the benefits of testing in production.

Testing in production involves making sure the functionality and quality of an application holds up in a live environment. This allows a  large number of people to get involved in the testing process besides the testers themselves. It also supports the idea of “Continuous Testing” which is a good thing to have in your process. Of course with a title such as a “double-edged sword” there are some pitfalls associated with this. One of these being that it can be viewed negatively to have bugs reported after release, even though these issues are usually resolved relatively quickly and may not have been caught in a normal testing environment.

There are three large parts to Testing in Production.

“Active and passive monitoring”

“Experimentation with real users”

“Stress tests to monitor system response”

Of course these seem simple however that is not the case at all. Each part is highly complicated and involves more than meets the eye. An example of this is the monitoring of user data. With the data becomes a large security concern that needs to be dealt with. Stress Tests need to be taken seriously as well, if the system were to fail there needs to be a team ready to quickly solve the issue. Social media is a useful source for testing in production as well. The testing team can monitor these forums and be provided with a large amount of useful information to be used in the testing process.

Testing in Production is an important part of any testing process. However it is not an excuse to get lazy and not take the rest of the testing process seriously thinking that Testing in production will catch anything that the tester has missed. It should also not be used as an excuse to speed up the development process, this can cause a variety of issues from user loyalty to test team positioning to suffer in the long run.

Here are some other articles that i found interesting:

http://www.continuousimprover.com/2016/10/principles-for-successful-package.html

https://www.stickyminds.com/better-software-magazine-article/what-cucumber-and-why-should-i-care

From the blog CS@Worcester – Computer Science Journal by jtassone93 and used with permission of the author. All other rights reserved by the author.

Week 5 Blog Post

This week i decided to read the article Walking the Tight Rope of REST API Security: Best Practices Will Hold You Steady by Harsh Upreti.

This article discusses REST APIs and the security that is involved when dealing with them. APIs are a large part of the development process and the REST framework has been gaining a great deal of popularity. It is due to this that understanding the security revolving around this framework becomes highly important.

This article discusses how the best way to maintain security especially when working with the REST framework is to maintain good programming practices even in the most dire of situations. Time crunches happen a lot and sometimes taking a shortcut seems like the only route available, however in the long run the damage this could cause is catastrophic.

The security of the REST API is what takes a hit from these shortcuts and security is exceedingly important in this digital world. The article states how REST standards are often “massaged, misinterpreted, and sometimes even mauled beyond recognition (Upreti 1)”. These things can end up resulting in sensitive information residing directly in the URL which is a very big no no.

“Why is it not a good idea to have informaton in the URL? Well, because:

1. Your URL goes places, it is very much exposed to the whole world, it’s embedded in emails, in third party code, it gets shortened and gets tossed around pretty much everywhere. You do not want anything even remotely sensitive there.
2. Attacks like cross site scripting can use URL parameters to introduce malicious scripts in your API calls. (Upreti 1)”

These above listed reasons seem like more than enough to maintain food programming practices even in the worst of timecrunches. REST has a very well documented set of practices for using the framework and sticking to them is essential to the quality as well as the security of your code. The article also suggests testing for security as much as possible throughout the development process as well as understanding the REST framework well enough to know what you need to test for.

Here are 4 other articles that i found interesting:

http://www.mkltesthead.com/2016/10/in-that-moment-of-terror-evolution.html

From the blog CS@Worcester – Computer Science Journal by jtassone93 and used with permission of the author. All other rights reserved by the author.

Week 3 Blog Post

This week i decided to read Mutation Testing – Learn This Interesting Testing Technique Quickly with a Simple Example by Swati S.

Mutation Testing is something that i was not very familiar with before reading this article. However after reading it i have a much better idea of the ideas behind this form of testing. Mutation Testing is defined as “Mutation testing is a fault based testing technique where variations of a software program are subjected to the test data-set. This is done to determine the effectiveness of the test set in isolating the deviations.(Swati, 1). The interesting thing about the article is that it taught me about mutation testing by using an example. I will attempt to summarize this example in my post in order to reinforce the idea in my own head as well as to help anyone else who is interested in mutation testing.

We are given the following Pseudo Code:

1) Read Age
2) If age>14
3) Doctor= General Physician()
4) End if

Mutation testing uses something known as mutation operators in order to identify problems with the original code. These include arithmetic operator replacement, logical connector replacement, statement removal, relational operator replacement, and absolute value insertion.

Examples of these mutations:

1) Read Age
2) If age = 14 – The greater than was changed with =, it could also be changed to < or <=
3) Doctor= General Physician()
4) End if

For a full mutation test you would create a large number of these mutants and then run those and the original code against your data set. When this is done all the mutants should be “killed”, this means that the test data made them fail.

Of course this example is extremely easy compared to what it is like to actually implement mutation testing. The  operators may also change depending on the type of application and the programming language that is being used. Although i may not be ready to sit down and start writing mutation tests the article and the example provided have given me a much better understanding of the topic as a whole.

Other interesting Articles that i looked at this week:

http://qahiccupps.blogspot.com/2016/09/i-can-manage.html

From the blog CS@Worcester – Computer Science Journal by jtassone93 and used with permission of the author. All other rights reserved by the author.