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!

  • 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.
A lot of work.. huh? yes.. but at the end of the day, your work has to be part of a production system. So, quality is not something to compromise. Start to love software testing. That is the only way to deliver quality! 

Comments

~Roshan said…
Hi Charitha,

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
September 22, 2013 at 4:05 PM
Post a Comment

Popular posts from this blog

WSO2 Stratos - Introducing WSO2 middleware Platform as a Service (PaaS)

Image
Yesterday we released our newest integrated cloud middleware platform, WSO2 Stratos . It is now online and ready for use! For the past few years, WSO2 has been doing many releases based on revolutionary Carbon platform , which helped to consistently improve the platform with introducing latest state-of-art technologies. The initial releases of Carbon product platform intended to improve the features of the individual products. For example, a lot of core features were introduced to WSO2 ESB, WSAS, Governance Registry etc.. Then we focused on ease of integration and more component based model. We introduced Equinox based provisioning model to build your SOA platform by picking and choosing the components as and when you need. Then, the core product platform has been enhanced to support multi-tenancy. With the multi-tenant supported architecture at hand, our brilliant development team was able to introduce the first ever comprehensive middleware PaaS. Why is this so important? Now, WSO2 C...
Read more

Common mistakes to avoid in WSO2 ESB - 1 - "org.apache.axis2.AxisFault: The system cannot infer the transport information from the URL"

In the next few weeks, you could expect a series of blog posts from me which explain the remedies to avoid some common mistakes which we do when working with WSO2 ESB . This is the first of many. During the initial rounds of testing your integration solution or even in production systems, you may have come across the following error. org.apache.axis2.AxisFault: The system cannot infer the transport information from the URL .... Some of you may have struggled hours figuring out a solution to address this issue. Let me explain this error in detail and possible causes of this. So, next time when you see this error in your WSO2 ESB setup, you will not have to spend time unnecessarily googling everywhere. There can be many different causes of this error. I have observed  four main reasons. Cause 1 This is the simplest cause. Suppose, you have a proxy service similar to the following. <proxy xmlns="http://ws.apache.org/ns/synapse" name="MistakesTest...
Read more

Working with HTTP multipart requests in soapUI

Image
You can use HTTP request test step in soapUI to submit messages with various Content-Types.  In this post, we will have a quick look into the multipart/form-data requests in soapUI. multipart/form-data requests usually come into action when you do HTML form submissions with file attachments. For example, have a look at the following HTML form post. <form action="http://localhost:8090/CKFileUploadApp/UploadServlet" method="post" enctype="multipart/form-data"> <input type="file" name="file"> <input type="text" name="paramName"> <input type="submit" name="Submit" value="Upload File"> </form> In the forms like above, we have file upload option as a form input where we can upload a file along with the form submission. In that case, the request's HTTP content type will be multipart/form-data. How can we simulate such a request using soapUI...
Read more