Fellowship Technologies, of course!
Let's establish a baseline and start with what we know. According to Merriam-Webster, the definition of quality assurance is, "…a program for the systematic monitoring and evaluation of the various aspects of a project, service, or facility to ensure that standards of quality are being met." Fellowship Technologies, "...believes that work is a form of worship." according to just one of our many core values. Finally, and ultimately, according to scripture, Col 3:23-24 states "23Whatever you do, work at it with all your heart, as working for the Lord, not for men, 24since you know that you will receive an inheritance from the Lord as a reward. It is the Lord Christ you are serving." NIV
So, how does this all tie together? In the realm of software development, QA should be fairly simple, right? After all, it either works or it doesn't, right? And if, as a company, we are all practicing scripture and, "…working for the Lord…", then do we really need checks and balances? Yes. Allow me to explain…
A little perspective…I don't see my role, or the role of QA at FT, as checking others' work, pointing out someone's mistakes, or finding fault. QA is part of a team. The team works together to accomplish the common goal of producing a quality product allowing those utilizing it more time to manage, minister, and serve within the local church. This is what makes product development at FT team unique. We work as a team within the process of customer demand through user forums and working closely with Product Management, IT, Support and others. Not to mention the immediate attention required for unforeseen technical events, and…drum roll please…bugs.
Bugs certainly take their portion of the total pie of development challenges. This is normal. Some are found during development. Some are found during QA. And some are kindly brought to our attention through our clients. Adopting an agile work environment allows QA to be part of the product developmental process.
"On an agile , story driven project, testing is not the antagonistic activity that it becomes for many teams. There is no "I gotcha" mentality when a bug is found. There is no room for passing the blame when a bug makes it all the way to production. The highly-collaborative, we're all-in-this-together mentality of the team prevents this.
"On an agile project, we test to find and eliminate bugs; we don't necessarily pursue goals of 100% code coverage or testing of all boundary conditions. We use our intuition, our knowledge, and our past experience to guide our test effort."
Mike Cohn, (2004). User Stories Applied For Agile Software Development. p. 72
We are a team. Leaning on each other's expertise, knowledge and being accountable, we can commit to giving our best every day. We can commit to FT's core values. And finally, we can commit to living the word as closely as humanly possible to help further the kingdom. I'm proud to be a part of this effort. In the mean time, we thank God for grace and look forward to the future He has in store for us!
- Jason