Quality Assurance SIG/20171020

Attendees: JR, Greg, Zeljko, Erik

Agenda:

JR: Been working on Code Health and Tech Debt. Most of the status has already been shared with those attending today's meeting.
- Code Health Blog post went out last week
- Code Stewardship definitions
- Code ownhership gaps/orphans

Zeljko:
- continuing work in the migration of Selenium tests from Ruby to NodeJS. Will be sending out final reminder that the Ruby based framework will be depricated soon.
- Ran into some blacklisting issues on Beta Cluster. Keeping tests from running anonymously. It's not clear what the source is as there have been many changes. Greg is very keen on making sire we understand what happened so that we can avoid it moving forward.
Erik:
- Mostly working on daily engineering tasks. Not much to share.

Spent time talking about computing resources and the impact of automated testing (Selenium, Unit) on that. If we get people doing more automated testing, will we be able to handle the load?
- Our nodepool resources are limited and won't really be expanding. The SSD project and creation of Docker/Container based computing will help address this problem over time.

Also spoke about TDD as a development approach
- Both good and bad sides to it. The good: more tests, code that was written to be testable, positive influence in the design. The Bad: so many tests that when a change is made more time is spent fixing tests than actually writing the code. This reduces agility. This problem is probably more a reflection of poorly implemented tests than TDD.
- Can we approach TDD as a personal process vs a team process? It could make it difficult for a team that is responsbile for a shared segment of code to work together if only part of the team is doing TDD because not all the code will have the tests in place and may lack testability while in developemt. So where multiple people are responsible for a the same area of code, they may want to be following the same development process. The end goals are what's key: tests, testible code, etc... How it's accomplished (TDD vs other approaches) may not be as important.

in conjunction to the TDD topic, we also spoke about coverage numbers. Should we set targets like 90%, 80%, etc... Or should we just say everything (100%)?
- We all know that there are exceptions, however, some may be things that can be overcome. Saying you can have less than 100% coverage may invite people to not address testability issues. Perhaps we should identify the exceptions instead. Compared to today's numbers, 80% would be great, so maybe we get to that first and then go to 90 then 100.