In a perfect world (or a near to perfect one too), QA team has all the perfectly drafted requirements available for them to test the application against. And if they are even luckier, these requirements will be continually updated too! But for not the so-lucky ones, the requirements can be missing altogether. In this situation, QA is expected to keep checking with the Project Management and Development Team for the updated requirements. Many a times, this is not so much appreciated by the BA, PM or Dev Team. As a result, the QA folks are left out, neglected as the unwanted ones, who dont know what requirements to test the application against.

For the QA folks having perseverence, sending Queries to PM, BA and/or Dev Team is a frequently used option.All the queries are documented in a single list and sent across for resolutions. Many times, the QA Team even mentions their assumption in the query, so that the responder just has to conform the assumption, if the same is correct. In case of discrepancy, the correct answer is then provided and sent back to QA. QA Team keeps on sending these queries until all (or atleast most) of them are resolved.

However, there is yet another proactive way to handle such situation. The QA Team, after interacting with all the teams, prepare what is called a Requirement Understanding Document and get them reviewed/approved with the BA/PM/Dev Team. In case of discrepancies, the QA Team take the lead in modifying the content to make sure the Requirements are clearly documented. This document then becomes useful for the entire team, as the Dev Team develops the application based on this document.

This proactive approach can prove to be effective in getting acceptance from the PM & Dev Team, as they now are looked upon as a part of the team, who are willing and can help the other team members. Not only that, since the QA Team has prepared the document themselves, they know the application and its intricacies (many, if not all) much better.

This is a tried and tested approach which has worked wonders in more than 1 case.

There are other such small things which can be taken up by the QA to help the other Team Members. Some of them are:

  • Taking up maintenance of QA Environment and coordinating with IT support team to remove the bottlenecks
  • Setting up and maintaining a CI Tool so that some of the automated tests get automatically executed when a new build is deployed
  • In case of TDD, QA can monitor the code coverage and wherever required, suggest more Test Cases to increase the code coverage
  • If possible, QA can also help by writing unit test cases and help the Dev Team augment the code coverage

This is not an exhaustive list but only some tasks which can be taken by QA. However these tasks can be taken up depending on the requirements of the client. For e.g. many clients do not allow 3rd party vendors to take control or interfere in the IT infrastructure matters. However in smaller companies, if the team has won the confidence of the client, then this could be achieved.

Would love to hear if there are other small tasks taken up by QA, which have proved useful to the BA/PM/Dev Team and added to the success of the team and project.

Data in its raw form is not useful to anyone, unless it is processed and analyzed correctly. Only then, it becomes information and thus gets meaningful. On the same line, collecting quality metrics in itself is not sufficient. It needs to be interpreted properly, for it to become useful and help the stakeholders in taking the right decision. Analyzing metrics in isolation can be dangerous and single dimensional metrics cannot be useful in decision making.

Consider this:

The testing team reports in the weekly meeting that they reported 100 defects in just 2 days. This statement is single dimensional information, which requires an action to be taken, as the development process has some gaps because of which 100 defects got pushed into the QA environment in a span of just 1 week.

But what if we added a second dimension to this information?

Out of the 100 defects reported, 80 are invalid (duplicates, not a defect or working as expected defects). Now what? Suddenly, the testing team looks to be the weaker link here, which needs some questioning to be done, as to why so many invalid defects got reported in just a short span. Don’t you think that this 2nd bit of information was required before taking a decision? Without it, you could be taking action against the wrong team in the above example.

Another case:

The Production Support team reports 20 defects logged by Client in just 2 days after go live of a critical release. This statement shows that the testing team did not do a good enough job of testing the critical release, because of which so many defects slipped through and made it to production.

If we add some information to this and find out during Root Cause Analysis, that of those 20 defects, 3 were critical, 8 were major and 9 were trivial. Amongst the defects reported, 3 critical and 6 Major defects were already logged by testing team prior to the release, but their priority was downgraded by BA team just before the release, as they thought those defects were not so important and hence were not included in scope of the release. Also, 2 Major defects logged by Client were Production Configuration issues and hence not valid ones.

This Root Cause Analysis clearly shows that the testing team had done their job well of identifying the defects early in the testing cycle and that too, with the appropriate severity. But the BA team did not do a good job of understanding Client requirements and they wrongly downgraded the priority of the defects just before the release. As a result, the defects were not fixed in time and got slipped to Production and ultimately, the Client noticed them late in the Production and logged them.

As seen in the above examples, it is very important to consider all the dimensions before taking a decision. Relying only on single dimensional information can be dangerous and can lead to wrong decision-making.

Reading an article on Testing User Experience here, few thoughts came across my mind, which I wanted to share here.

I’ll start with the last para I read, which I totally agree -

As Steve Jobs said, design is “not just what it looks like and feels like. Design is how it works.” . Testers can use a variety of heuristics to tell the UX team what does and doesn’t work for users so that the entire project team knows exactly what gives their customers the greatest experience possible.

Testers know about the functional aspects of the application and combining that knowledge with an insight in to the applications’ look, feel and experience, can be a great feedback to the development and design team.

However, one aspect to consider in UX Testing, is what one tester or one team of testers will feel about the UX and that will be used as a feedback by the Design and Development team. So the tester(s) rather be convincing about their feedback. Just giving random pointers about what looks good and does not look good, will not work. I feel, there should be logical reasons for them to say whatever they are saying. Otherwise, no one will be able to believe and trust their feedback.

Another aspect liked was the First Impression Test. I myself took a few tests on the suggested fivesecondtest.com and quickly realized that indeed the first five seconds were good enough to know whether the site or application was user friendly or not.

From the tests I took, the simplest question which I could hardly answer in my very first test was “what was the name of the company whose website you just viewed?”. I, frankly, was unable to remember because my attention was totally on the colorful background and gaudy images on the homepage. The company name was hardly noticeable. This experience convinced me that on the homepage, at least the company name should be the center of attraction, and not the background or the images used. This should be followed by what the company sells/provides?

The third aspect I was to led to think was about understanding user pain points when using the website or application. Dis-satisfied customers can provide a lot of information about User Experience but provided they give an honest feedback about what they liked or disliked.

But I think tools like fivesecondtest.com are a great source of information. Another approach to get honest feedback is to ask the testers record their thoughts when navigating the website/application. Use a combination of all the recordings and analyzing them can give a valuable feedback about what looks, feels and works good.

Social Networking Sites are increasing day by day and they are turning out to be a boon for companies, as it acts a marketing platform for them.

I personally feel that using the social network for creative and effective use is a smarter way of working. Document sharing is one such way and I think players like SlideShare are doing a great job. Thats why I chose to signup on SlideShare and upload some of the documents on SlideShare. This will allow our clients and friends to view and read documents about Titian-tech Solutions and its services.

You can find Titian-tech Solutions on SlideShare here: http://www.slideshare.net/titiantechsol/

Happy Reading!

We are very excited to have our website up now, after having being offline for almost 3 weeks. I sincerely regret the inconvenience this may have caused to the clients and also to all those who had visited our site but gone back seeing the under construction page. During these 3 weeks, we were building this neat and cleanly designed website, so you could have a pleasant experience during your visit, while you learn about how Titian-tech Solutions can help you with your product or services testing & QA.

As mentioned, one of the primary goals with the website was to have something which was cleaner in its layout, easy in navigation for users, and of course, convenient for us to manage/update. At the same time, we wanted to help our clients get to know us better. So we have added lot of information about us, why we chose ‘Titian’ in our name, what are our values and what is our Vision and Mission. Have a look at the About Us page and find out more.

We have also integrated the Website with WordPress, which is one of the best content management systems available around. This integration will help us stay in touch with our clients and customers in a very convenient way. Very soon, we’ll start our newsletter section as well, where in we will send out monthly newsletters to our esteemed clients, informing them about what happened in the previous month and we’ll also share our plans for the upcoming month.

We also plan to start our affiliates program very soon, which will allow are well-wishers to not only earn handsome returns for their referral orders but also get lots of goodies for their help. Stay tuned for more information on that.

We would love to hear from you about the website design or contents or about us and our services. Write an email to info@titian-tech.com or leave some comments below.