DevOps Testing Panel

Notes from DevOps meetup panel on testing.

Last night I had an honor of being on the panel hosted by Boston DevOps meetup dedicated to Testing. Thanks to CloudHealth for hosting!

4 companies - 4 tshirts in the same color

I loved every question and the answers given by other panelists. Unfortunately, there was no recording of the event, but at least here are some of my answers as I remember them now.

Q: Types of testing

There is a testing pyramid; its shape is determined by the tools we have. It is so simple to write unit tests - so a lot of them are written. It is harder to write end to end tests, so there are a few of them at the very top of the pyramid. It should really be a testing trapezoid.

Q: What is the difference between quality and testing?

Quality is a property, and testing is an action. There are many ways to achieve quality, testing is one of the ways. My favorite two ways of building high quality software:

  1. Having well-rested engineers. No one can avoid making costly mistakes while putting in 70 hour work weeks for months.
  2. Taking pride in your work. There is a difference in mass produced widgets vs artisan work. A "crafty" person loves what he or she is doing, and will ensure that the built product is well done.

Q: Language-specific testing

Some languages require more testing, for example JavaScript (love it or hate it) dominates the world, but requires additional unit tests just because it is a dynamic scripting language. As a second consideration, I think writing tests in the same language as the main code is strongly preferred.

Q: How do you ensure that your testing data accurately reflects real world production data?

Use whatever data fits the expected use case, according to your professional judgment. Then use crash reporting software in production. As soon as the real world case appears that you have not considered, and it crashes the system, add it as another test data case.

Q: What advice can you give a QA tester to improve personal career?

QA is not just about finding what is broken. It is about building what is right for the customer; and thus QA is a very creative role. Do not be afraid to take on more responsibility and insert yourself early in the process, bringing value to the product, rather than delaying it due to testing. It is a human-centric profession, which has a lot of leeway how to collect requirements, stated and unstated, and how to communicate these requirements and track them through the process. Some time investment will be necessary, but local meetup scene is very valuable in this regard.