by Greg Sypolt

The objective of automated testing is to simplify as much of the testing effort as possible with a minimum set of scripts. Automated testing tools are capable of executing repeatable tests, reporting outcomes, and comparing results with faster feedback to the team. Automated tests perform precisely the same operation each time they are executed, thereby eliminating human errors – and can be run repeatedly, at any time of day. Below I’ve outlined five steps how to get up and running (the right way) with automation...

Read more at;  https://www.sumologic.com/devops/post/automated-testing

by Greg Sypolt

Why does a daily standup or scrum team have a definition of done (DoD)? It’s simple – everyone involved in a project needs to know and understand what “done” means.

What is DoD? It is a clear and concise list of requirements a software increment must adhere to in order to be considered a completed user story, sprint, or be considered ready for release...

Read more at; ​http://sauceio.com/index.php/2015/09/what-is-your-definition-of-done/

by Ashley Hunsberger

As I dive into a new round of planning and discussions for our next project with the product management team and designers, I keep hearing, “This is MVP.” No, they are not referring to Most Valuable Player, but rather Minimum Viable Product — the product that has just those core features that will still provide value to the customer. Unfortunately, this can sometimes lead to over-promising or large user stories. In the beginning, sometimes it feels like everything is MVP (until you start understanding the actual scope of a feature). Let’s talk about a term my colleague, Trevor Akiyama, came up with: the MFP — Minimum Functional Product (the minimal set of things that actually works, as opposed to the MVP that stakeholders want).

Why do you need them?

Over the years, I have often seen one single user story that was more like an epic, simply because everything within the story was part of the MVP. What resulted was a user story that stayed open forever, with no way to test until all the pieces that were dependent on each other were integrated. Now, what if we had broken down the user story into smaller pieces and found the MFP? We would have had clear, short, testable user stories.

For teams trying to transition into the world of Continuous Delivery, testable stories are a MUST. By identifying your MFPs, you help your team keep stories small, and prioritize how to build (and therefore test) your product.

Read more at: http://sauceio.com/index.php/2015/09/another-acronym-mvp-vs-mfp-2/ 

by Greg Sypolt


In an attempt to do more with less, organizations want to test their software adequately, as quickly as possible. Businesses are demanding quick turnaround, pushing new features and bug fixes to production within days, along with quality. Everyone knows manual testing is labor-intensive and error-prone, and does not support the same kind of quality checks that are possible through the use of an automated test. Nobody likes change, but it’s time to educate your team on the importance of onboard automated testing....


Read more at: http://bit.ly/onboard-auto-scripts

by Ashley Hunsberger

During nearly every project I have worked on, the question Can I test everything?always comes up.  The answer is (usually) a resounding NO. Sometimes it’s because of time, sometimes it’s lack of people. How can we still ensure a quality product, even if we can’t cover it all? Sometimes, we have to test smarter.

Read more at: http://sauceio.com/index.php/2015/09/can-you-test-it-all-test-coverage-vs-resources/