Hello again everyone and welcome to my fourth entry for the semester on this blog. today we are going to talk about some software testing trends. As the title of this post suggests, we will be talking about ten of them today. The article was written by Ulf Eriksson (Really cool name) and i started this article by skimming and it seems to be very short and concise, which means it’ll be easier for me to write about. I will only be writing about the five i found the most interesting.

So obviously, this article is going to be about trends that everyone should be seeing in 2019. Ulf leads off with mentioning the “evolution of new testing approaches” (Eriksson) due to new developments with Agile and DevOps. He then begins his list with discussing Agile. He says that Agile is being used in more and more comapanies. He then talks about what Agile is and how it works, but if you’re reading this you probably know what agile is so I won’t bore you with that. The next part caught my eye because it has to do with machine testing. I don’t know much about machine testing, but it still has my interest. Ulf describes how it is used as follows: Test suite optimization (redundancy), predictive analytics(key parameters), log analytics(automatic executing), traceability (test coverage), and defect analytics(identifying high risk areas). The next trend is the adoption of DevOps. This part was very short and it talks about continuous integration and continuous delivery. Another trend was shortening the delivery cycle. This section talks about how new technologies are being used in order to speed up the deliveries. This is interesting because this will always be a trend. New technologies are coming out everyday, so it is impossible for this trend to die down. Ulf also discusses big data testing as a trend, and I chose to write about this because it isn’t my concentration so it is interesting to read about this considering I am not studying it. Basically this kind of testing makes sure the large amounts of data are being verified correctly. In other words, this tests the quantity and quality of data.

I would have loved to write about every trend on this list, but this blog would be way too long and I would lose all my reader(s) about halfway through. However, Ulf Eriksson did a great job with this article. He didn’t go into much detail about every trend because some of them should have already been known. However, the lesser know trends were explained very well. This article was a very interesting read because I’m in quality assurance testing now, and it is nice seeing topics I learned in class in articles. I would recommend this to any testers out there.

https://dzone.com/articles/10-software-testing-trends-to-watch-out-for-in-201

From the blog CS@Worcester – My Life in Comp Sci by Tyler Rego and used with permission of the author. All other rights reserved by the author.

Once again, Martin Fowler has some comments on this week’s topic, but this post will mainly reference Dan Terhorst-North’s post, which better describes the reason and motivation for creating Behavior-Driven Development. BDD arose from TDD and it is better to think of it as an extension of TDD.

BDD tests follow the pattern “Given-When-Then” (notice the similarity to Arrange-Act-Assert). Mockito can define this pattern, but the BDDMockito aims to follow the same human-readable principles. The idea is simple: given a precondition, if some other condition occurs, then something else should have happened. Fowler’s example includes checking the state of an object, so clearly BDD is not simply testing the behavior of an object. However, it is a very important part.

Terhorst-North mentions that BDD picks up where TDD left off. I have seen some evidence that BDD has influenced TDD, such as describing tests as a sentence like “testFailsForDuplicateCustomers()”, which can be seen in many TDD test examples. Imitation is the highest form of flattery, so clearly this is a good approach. Or maybe, BDD is just more consistent in this naming because they put it in the specification.

Regardless, BDD developed out of Agile processes. It aimed to make writing tests part of the entire process and help future developers work well together in doing so. This is where many of Terhorst-North’s ideas stemmed from, and his main point, and the motivation behind the name BDD, is that “‘Behaviour’ is a more useful word than ‘Test’”. If you describe each test as a behavior, you know how to define the test, and you know when the specification has changed enough to warrant deletion of a test.

“What to call your test is easy – it’s a sentence describing the next behaviour in which you are interested. How much to test becomes moot – you can only describe so much behaviour in a single sentence. When a test fails. . . either you introduced a bug, the behaviour moved, or the test is no longer relevant.”

Daniel Terhorst-North, “Introducing BDD”

Real mastery of a subject is when it becomes simple. BDD is the next step to understanding testing on an intuitive, subconscious level. It wasn’t immediately obvious that tests don’t need to be difficult to write, but Terhorst-North managed to figure out a way to make it so. It is another part of the iterative process that is technology. Next time I encounter a difficult concept, I think asking three questions, in order, might help: Am I misunderstanding the concept? Do I just need more practice? Or is this method flawed?

Someone saw a flaw in TDD and developed BDD to improve it. This came only through thorough understanding, practicing, and identifying problems. This is applicable to any career, to provide real value.

From the blog CS@Worcester – Inquiries and Queries by ausausdauer and used with permission of the author. All other rights reserved by the author.

Hello again everyone. For my second blog of the semester (Technically third because of intro post) I am using another article by Lanier Norville. Last week, I wrote about her article on testers becoming agents of change. This week, however, I am going to be writing about some Tricentis qTest Case Studies. I picked this article because it talks about Agile Transformation, and I am personally fond of agile frameworks.

Once again Norville leads off with a nice and small yet appropriate introduction on what she is discussing. In this case, she is talking about how companies are transforming agile and DevOps. She uses her case studies to show the “critical role” (Norville) of testers.

The first case study involves a payment processing technology provider. The VP of Test Engineering, Nick Jones attended an event on DevOps and he decided that his organization needed to transform as well. Norville then discusses how payment options have an effect on whether customers end up buying something or not. Jones developed a DevOps roadmap with his team and according to Norville they have reduced the time of delivery from “14 hours to 4 minute” (Norville) This is interesting because it is a huge drop in time which is huge for a company that is constantly making deliveries.

The next study isn’t as much of a success story as the last study, however it still seems like it is helpful. The University of the West of England switched to Tricentis qTest before using an agile framework. The head of testing, Heather Daniels that she “needed to implement a test management tool” (Norville) She needed to do this in order to maintain everything that the school used. (Library systems, eLearning systems, etc.) As of now, according to Norville, two of the organizations have switched to agile. It is a big change according to Daniels, and the University still isn’t used to making small functional deliveries, but it seems like they are getting the hang of it. I like that they switched because now they are “prioritizing the things that are most important to users first.” (Norville)

This article, in my opinion, was a little bit more difficult for me to follow, but it was still a very well written article overall. I did like how well she described each of the scenarios and what was done with qTest to transform into an agile framework. It is obvious that the article is supporting the websites own product, but that is what companies are supposed to do. Overall, this was a good read, but for my next blog, I will probably be visiting another website.

New Tricentis qTest Case Studies Highlight Testing’s Critical Role in Agile Transformation

From the blog CS@Worcester – My Life in Comp Sci by Tyler Rego and used with permission of the author. All other rights reserved by the author.