For today’s blog I am writing about agile testing. I found this blog on agile testing called “A Coach Guide to Agile Testing”. The blog talks about the different types of agile testing and the different types of teams/groups/personalities that use agile testing in different ways. The article mentions that people who use traditional ways of testing usually do not like agile testing because they consider it a threat to their job, which is to identify discrepancies between the working system and the specifications. This is different from agile because agile does not have specification documents that are detailed enough to help the tester do their job.  Something I found interesting about this article was when they were talking about the traditional testers and their approach of “follow specifications and report how the system differs from these specifications”. The article says that checking to see how closely the program follows the specifications does not actually say anything about the quality of the program. I think this point really hit home, because you can make a program that follows the specifications to a tee, and it can still be a poorly designed or poorly running program.

For an example, say you are building a program to manage someones bank account. You would need methods to deposit, withdraw, check balance, transfer money, etc. Now let us say the only specification for the program is that it compiles and runs. We could write a program that compiles and runs and in the sense of traditional software testing, we have a passing program. However, what if the method for deposit didn’t actually add money into the account, or the method for withdraw added money instead of taking it out? According to traditional software testing we have a functional program, when in reality we know our program does not do what it is supposed to. This is where agile testing comes in handy. Agile testing will test every method in our program (not just the specifications) to make sure that our methods actually do what they are supposed to. This is why I like agile testing, and try to do it in all my programs. It is a good way to assure you have a quality product that functions as designed and has also been tested and passed. I hope to continue using agile testing in my future programs and reading this article has given me some new tips and tricks to think of when doing agile testing.

Here’s the link: http://www.softwaretestingmagazine.com/knowledge/a-coach-guide-to-agile-testing/

From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.

https://www.imaginarycloud.com/blog/test-driven-development/

          This week I’ve decided to write about a blog post that talked about Test-Driven Development (TDD) and its benefits as well as its drawbacks. The post begins by explaining that TDD is the writing of automated tests before actually writing a feature for the product. It gives an example using social networking software and how a coder would first write an automated test and then write the minimum amount of code to pass that test. It uses the “red/green/refactor mantra” to show if tests have passed or failed. The post goes into the benefits of TDD by explaining that sometimes new code can break previous features. This is similar to regressions in the software development path. Using TDD, you are able to test the code before integrating it into the system to see if it will actually work. The blog explains that even though TDD can double check a new feature integration using automated tests, these tests have their drawbacks. One drawback that the post focused on was the overall cost of these automated tests that increased the cost of development cycles compared to those that continue on without them. It continues to say that automated tests aren’t a requirement for every single feature since there is no formal test plan.

            I chose this article because I had read about Behavior-Driven Development on my last blog post and it was constantly compared to Test-Driven Development. I wanted to gain a better understanding as to what TDD was and why it was compared to BDD. I found that this content answered those questions very well by explaining what TDD was while giving its strengths and weaknesses. I enjoyed how the post used examples from software development tracks in real situations to explain this concept. It allowed me to better understand why it is a safer system from new feature integration. I was able to grasp an understanding of when to use this development tactic while also learning that there are times to be cost-efficient as well. I found the parts that talked about how much is really needed with TDD to ensure cost-efficiency very interesting because it really puts into perspective how important budgeting is. I learned a lot from this blog including what TDD is and when to properly use it. I found that the examples were a great resource to understanding the term within context. This blog is a great source of information about TDD and I found it very interesting.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.

For this weeks blog for the topic Quality Assurance and Testing, I read an article titled “5 Reasons you are wasting your testing time.” That is not to say that testing is a waste of time, but rather as the first sentence says, “Not all our testing time is spent effectively.”

The blog goes on to list the five reasons that a programmer might be using their testing time ineffectively, which are as follows: (1) “You don’t set a clear goal for your testing task;” (2) “You don’t understand the value of the feature for your End User;” (3) “You do not keep track of what you tested, your findings and the other ideas you got while testing;” (4) “You do not consult existing information to get insights into your test;” And (5) “You do not do post-test reviews and feedback sessions with your peers.”

These are all straightforward ideas, but I’m sure most programmers testing their code have fallen into several of these, if not all. This list provides a framework to avoid these pitfalls. In class, we have been going over ways to be more methodical when testing. This list is a little more elementary than what we have covered, but it is good information to use nonetheless.

A key takeaway is to treat testing more like a science than throwing it together willy-nilly. There has to be a method to the madness. You have to know what you want the test to do. You should have a clear understanding what the end product should look like and how it should look to the end user.

The final section in the article said testing isn’t “Rocket Science, but it is not a trivial task either.” It should not be seen as something that could be done by almost everyone, which is a common belief in the industry. This is not true. It is an important job that should be done right. It requires being very organized and staying on top of things. There are many things that can be done haphazardly. Testing is not one of them.

From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.

This week’s topic has to do with behavior-driven development, which a strategy of software development that focuses on the communicating narrative between developers so as to ensure that all members understand the specifications and other requirements of a program. I found an insightful article at the following website: https://airbrake.io/blog/software-design/behavior-driven-development. This blog post is one of a few in a series explaining different development techniques that work together as part of the software development life cycle.

As explained in the article, behavior-driven development, or BDD, works hand-in-hand with other strategies, such as test-driven development, which entails the execution of a failing test and then subsequently writing a minimum amount of code in order to pass the test. The BDD of tests becomes different from this technique when it relies more on the desired behavior of the program, rather than simply writing initially failing tests for all parts of the program, as utilized with test-driven development. BDD defines behavior specifications with user stories that outline various scenarios for the program to be executed or tested. These stories take on a narrative tone that states who and what are involved in each scenario, as well as the conditions that must be met in order for the scenarios to be successfully implemented. By using a common language understood and easily communicated by everyone on a development team, members can easily collaborate to define these specifications and perform tests based on the definitions given with the user stories.

This topic stuck out to me because it somewhat combined what I have been learning in both my Software Design and Software Testing courses this semester. This post discusses different methods of designing programs and their tests, and I thought that BDD clearly incorporated both, with the description of designing the behavior specifications to be met, as well as the concept of testing these specifications. We’ve somewhat been starting to take on both of these roles in the classroom by determining the purpose and desired functions of our programs, and then performing tests to ensure that the functions are working successfully. While we haven’t written out user stories to more specifically outline the behaviors, I think that this process is more implicit for us at this point.

From the blog CS@Worcester – Hi, I'm Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.

https://abstracta.us/blog/software-testing/test-automation-patterns-and-good-practices/

This blog post discusses good practices to use with test automation. Automating tests can save time and decrease the amount of work that has to be done. Following these practices will help ensure that you get the most value out of automation.

Test Code Review

• All levels of testing should be reviewed to examine their quality. This will help the tester discover bad practices or mismatches in the tests.

Apply Assertions

• Assertions should be used to identify problems.
• An assertion that’s too generic can create false negatives and false positives, so pay special attention in the definition of assertions.

Behavior-Driven Development (BDD)

• A common language should be created for the business and engineers to be used as a starting point for development and testing.
• User stories are defined and used as input for test cases.
• BDD gives developers clear specifications and brings testability to a system.

Page Object Pattern for UI Testing

• The use of design patterns increases scalability and maintainability
• The page object pattern allows you to reuse knowledge of the structure of an application while having a minimal impact on tests.
• This pattern strengthens tests by decoupling the structure of the user interface from the test code

Data-Driven Testing

• With data-driven testing, automated tests are parameterized so that the same steps can be carried out with diverse amounts of test data
• Adding data to the file creates new test cases

Parallel Execution of Tests

• Using parallel execution options like Selenium will reduce testing time by running several tests at the same time.

I thought this blog was very interesting. While I have learned a little about test automation I haven’t used it enough to learn the best practices for it. It is important to learn these practices because the whole point of automation is to save time, and if you don’t do it correctly you will end up spending more time trying to fix your errors.

I thought the most interesting part of this post was the section on the page object pattern. This is a design pattern that I’ve never heard of. It seems to be very useful because it helps prevent you from breaking your tests when you change your code. This is a topic that I would like to learn more about and will keep in mind when I work with automated testing. Overall I thought this was a useful and well-written blog post.

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

http://news.mit.edu/machine-learning-image-object-recognition-0918

Speech recognition systems usually require hundreds of thousands of transcripts in order to work properly. This new model of machine learning learns through audio visual associations similar to how a child would learn, where they correlate speech with related images. The researchers then modified the model to associate specific words with specific pixels. It works by dividing the image into a grid of cells consisting of patches of pixels while dividing the audio portion into segments of the spectrogram. It then compares each image cell to each audio segment and produces a similarity score for each individual one. The researches call this comparison method a “matchmap”. One good use of this is learning translations between all of the languages on the planet. There are an estimated total of 7,000 languages spoken wordwide and only about 100 have trascription data for speech recognition. With this model, two different language speakers can describe the same image and the machine can learn the speech signals of the two languages and match the words, making them translations of one another. This is interesting because that means the model does not require actual text to learn to translate. In languages where things are not commonly written down, the machine can translate meanings where other methods that are common today cannot.

This method is important to note because machine learning is a growing topic in the world of computer science and this could open up all kinds of possibilities. It is a new and innovative way to try to solve a problem and might become something needed for future jobs or projects in life. With this matchmap system, speech recognition no longer needs to be manually taught hundreds of thousands of transcriptions and examples of those transcriptions in order to function properly. This is increasingly important since new words enter our dictionary and become common for people over time. Currently, the machine can only recognize a few hundred words but in the future it could help advance the machine learning field while also improving the speech recognition software that exists such as siri.

From the blog CS-443 – Timothy Montague Blog by Timothy Montague and used with permission of the author. All other rights reserved by the author.

“The Deep End” resonated with me, not because I’ve applied the pattern before, but rather because I’ve been thrown into the deep end. When I took Data Structures at a different college over the summer, I found out the course was being taught using C, which I hadn’t yet learned. My dad accurately described the task ahead of me as, “Here’s a new [human] language. Write a novel.”

Worse, the professor was often unhelpful. The pattern, which encourages taking challenges and high-profile roles, warns that you could end up in over your head and drown in trying to apply it. I actually compared my emotional state those first couple of weeks to drowning in the middle of the ocean, because I was so out of my depth, no one could help me, and the consequences of failure were drastic. And I was failing for a while. Assignments were graded using an automated system that tended to give out 100s or 0s with no in-between, and 10 points got taken off for every day late. I fell behind and was submitting assignments late, which in turn gave me less time to work on the next one.

The Deep End identifies Find Mentors and Kindred Spirits as patterns that can be used to mitigate its risks. What eventually made me feel less like I was drowning was identifying the one tutor available for the class who seemed to know what he was doing and reaching out to him for help. He was accommodating and even offered to look at my code outside of his tutoring hours. It was, in fact, finding a mentor/kindred spirit that enabled me to salvage the situation.

Good things came of surviving the deep end. I was able to take Robotics the next semester because my knowledge of C made me feel more prepared than I would have otherwise. My Unix Systems Programming course this semester is also turning out to be much easier than it could’ve been.

The idea for action given at the end is also interesting. The writers suggest rating every project you’ve ever worked on using your own ways of measuring complexity or difficulty, and then plotting new projects that come along in a chart with the others. This seems like a good idea for making sure your career trajectory is going up and consistently challenging you instead of stagnating.

As a final note, the idea of applying this pattern by taking high-profile roles also reminded me of a principle one of my role models has: that if you’re given something you feel you don’t deserve, the answer isn’t to refuse, it’s to take it and work hard to deserve it.

From the blog CS@Worcester – Fun in Function by funinfunction and used with permission of the author. All other rights reserved by the author.

From the blog CS@Worcester – BenLag's Blog by benlagblog and used with permission of the author. All other rights reserved by the author.

In this section of the Apprenticeship Patterns, the term “concrete skills” was introduced. It gives us an overview of why having certain concrete skills are necessary to have, especially when you, as an apprentice, will start developing your craft in the software development team. For example, a concrete skill can be your “First Language”, where you have prior knowledge and skills on understanding the programming language and knowing how to implement it in an IDE.

“Having knowledge is not the same as having the skill and practical ability to apply that knowledge to create software applications.”

I found this idea very useful and I completely agree with it because a developer who has adequate or substantial knowledge in software development has no value in their team if they do not know how to implement their knowledge in their craft. Therefore, the develop has no value in their team, and is nothing more than a dud in the team.

“The point is that you will often require hiring managers to take a leap of faith in choosing you. Concrete skills (which are ideally discrete enough that you can bring toy implementations to an interview) allow you to meet them halfway. The concrete skills you possess are your answer to the question: “If we hire you today, what can you do on Monday morning that will benefit us?” A deep understanding of ‘Your First Language’ will help establish your credibility and should prove to be extremely useful to your team.”

This idea supports that programming languages can be an effective concrete skill to have. Programming Languages, however, are not the only concrete skills that developers may need to have. Team management, communication, and organization skills are also necessary to have in order to have an efficient and cohesive team.

Reading this Apprenticeship Pattern made me think about the development capstone class because it made me evaluate myself and my team members on where we stand in acquiring our concrete skills. Within the past couple weeks, I’ve been trying to get use to Angular by doing more of the Angular tutorials so I can be well equipped on that knowledge on how use Angular. I think that would be a great task for me to do so in case if my teammates need help on Angular, I can show them, which is how I can be become a valuable asset to the team and our success.

From the blog CS@Worcester – Ricky Phan by Ricky Phan CS Worcester and used with permission of the author. All other rights reserved by the author.