QA mind-set
In the agile world of software development, quality assurance function is embedded into the main stream development process and it is not considered as an activity managed by a separate QA team.
Even with following many agile testing principles, why do some teams still fail to deliver products/projects with acceptable quality?
According to my experience, I believe the issues with adopting the QA mindset can be considered as the primary reason for many software quality concerns.
So, what is QA mindset and why is it a critical factor in software testing?
If you are a software developer, your primary objective is to complete the implementation of the feature/module which you have been assigned to do without schedule slippages. But, you are obliged to deliver it with best quality. So, you follow good agile testing principles, may be follow TDD (Test driven development), code reviews, write automation tests, do manual tests for the scenarios which you cannot automate, run performance tests etc..
However, when your "well-tested" feature is in UAT at your client's environment or verified by another person, the bug tracking system is filled up with many bugs.
What went wrong in your testing? Why did you miss all these bugs?
Software development has become more and more complex with all kinds of heterogeneous platform integrations which we use in today's applications. You are no longer expected to have the luxury of testing the traditional 3-tier applications. Instead, you need to think about large array of integration scenarios. The complexity multiplies by many factors when you are developing middleware. For example, what are the implications when your app runs on a cloud provider? what can be the behavior when the application is integrated into various DBMSs? what kind of changes can be expected in feature X of your app when it integrates with a third party enterprise application?
How will the application behave when different message types are processed? Will the feature X provide the same functionality with each message type under various platforms?
There can be endless questions!
You should not even think about a process without comprehensive test automation methodology to address such a complex matrix of test combinations. However, you can never replace human brain by a test automation tool. The test scenarios, which are the inputs for your test automation tool, have to be derived by you. Thus, it is really important to adopt QA mindset in any testing activity regardless of its nature (automated or manual).
QA mindset is all about the approach of looking at the problem at hand. When you develop a feature, you are mostly optimistic about its functionality since your mind forces you to believe that your creation is correct. You are biased towards your own work.
If you seriously want to avoid a third eye complaining about your creation, always use QA mindset in testing. There is a tester inside all of us. Get him out when you start testing!
Even with following many agile testing principles, why do some teams still fail to deliver products/projects with acceptable quality?
According to my experience, I believe the issues with adopting the QA mindset can be considered as the primary reason for many software quality concerns.
So, what is QA mindset and why is it a critical factor in software testing?
If you are a software developer, your primary objective is to complete the implementation of the feature/module which you have been assigned to do without schedule slippages. But, you are obliged to deliver it with best quality. So, you follow good agile testing principles, may be follow TDD (Test driven development), code reviews, write automation tests, do manual tests for the scenarios which you cannot automate, run performance tests etc..
However, when your "well-tested" feature is in UAT at your client's environment or verified by another person, the bug tracking system is filled up with many bugs.
What went wrong in your testing? Why did you miss all these bugs?
Software development has become more and more complex with all kinds of heterogeneous platform integrations which we use in today's applications. You are no longer expected to have the luxury of testing the traditional 3-tier applications. Instead, you need to think about large array of integration scenarios. The complexity multiplies by many factors when you are developing middleware. For example, what are the implications when your app runs on a cloud provider? what can be the behavior when the application is integrated into various DBMSs? what kind of changes can be expected in feature X of your app when it integrates with a third party enterprise application?
How will the application behave when different message types are processed? Will the feature X provide the same functionality with each message type under various platforms?
There can be endless questions!
You should not even think about a process without comprehensive test automation methodology to address such a complex matrix of test combinations. However, you can never replace human brain by a test automation tool. The test scenarios, which are the inputs for your test automation tool, have to be derived by you. Thus, it is really important to adopt QA mindset in any testing activity regardless of its nature (automated or manual).
QA mindset is all about the approach of looking at the problem at hand. When you develop a feature, you are mostly optimistic about its functionality since your mind forces you to believe that your creation is correct. You are biased towards your own work.
If you seriously want to avoid a third eye complaining about your creation, always use QA mindset in testing. There is a tester inside all of us. Get him out when you start testing!
- Avoid pre-mature feature completion announcements. Do not judge the functionality by just observing the positive work flow.
- Think about all possible integration scenarios. Write them down and execute each very carefully
- If your component consists of feature X, Y and Z, test every attribute of each feature. Do not leave out anything obvious for a third eye to try and complain
- Conduct more and more exploratory tests. Research on similar features implemented by others and look for missing use-cases.
- If you are enhancing an existing feature, collect the issues reported by your customers on the old implementation and assess each of them against the new implementation.
- Maintain a record of what you have tested so that a separate tester will not be repeating the same test scenarios which you have already tried out
- Do not be fooled by code coverage figures. Try to break your implementation.
Comments
Nice thoughts, and nice discussions. My understanding is that the QA mind set is important not only to developers, but also for the testers and all the stakeholders as well. I’ve seen many QA engineers lacking the right attitude. Attitude to explore. Attitude to learn.
What I believe is, that the product quality is the responsibility of all the stakeholders involved in the project. However the QA engineer has a higher portion as I feel. I think all the QA engineers should be damn good explorers. They should be able to go beyond the boundaries of the requirement. The QA engineer has the best option of doing so compared to a developer who is narrowly focused on the requirement itself. QA engineer is with a broader vision on the product.
I’ve my own theory. Ok It’s not mine 100%. It has been discussed in various forums. I think that the QA engineer should do the Unit testing and the integration testing before the product/module released to system testing. Or it could be pair programming, a developer and the tester. In that way, QA mind set is built in to the Unit testing. Defect will be identified in very early in the DLC.
On the other hand, I feel that we spend too much of our time on tasks which do not directly impact on the quality of the final product. Tasks like creating the test plan, creating the test cases, creating all other artefacts eats up the time we have on test execution. Simply, I believe that more executions finds more bugs. Primary objectives of those tasks are to provide evidence to someone that the team has done testing. I think that the product itself should be the evidence of testing. Even the tasks like daily stand ups, reporting defects might not need to be done in a matured team. Of course fields like pharmaceutical, aviation required the evidence due to regulations. I’m not talking about such projects.
I think that’s why all the stakeholders should have the proper mind set, to deliver a better product, rather than delivering individual’s assigned tasks.
I came across your blog quite accidentally, and I’m really impressed with your contribution to the QA community (and I’m blushing that I haven’t done anything). Keep it up.
Cheers,
~Roshan