SSSLUG
Programming, SS SLUG

SS SLUG Kaleidoscope – October 2011 Action


The October SQL Server Sri Lanka User Group meet up consisted of 3 main sessions this time.  Deviating from the conventional SS SLUG meetups, this time the team incorporated a new twist to the agenda to make the evening more interesting. Their first sign of victory was the numbers they brought in for the day.  It was the first time in the history of the SS SLUG a large number of audience gathered.

The agenda for the day was,

The performance graph of the day was similar to a cosine curve.

The first session managed to hit the mark. Dinesh A. spoke of UDFs (User Defined Functions) and also he touched on certain limitations of stored procedures that could be overcome with UDFs as well as instead of writing long lines of queries with stored procedures, how the same thing can be done using few lines of UDFs.

Progressing to the second session, Dinesh P. spoke of the upcoming enhancements made to the BI suite planned by Microsoft and if you’re doing any development for BI, how it would help you to know where you stand compared to the current progress of Microsoft. This session did not raise itself up to as the first session because there was a very small percentage of the crowd who really knew what BI was. Though Dinesh P. managed to give a bird’s eye view into BI before he began his session, as he continued the interest level on the topic dropped a bit low. He spoke of Traditional BI and the emerging trend of Self Service BI. I personally clueless about BI was looking forward for this session, because the topic on the agenda sounded pretty interesting and I assumed that it would give an overview to BI and cover some interesting areas. It was a bit of a disappointment.

Trying to gain momentum, Preethiviraj got into the field with his topic. Another session I was looking forward to. Preethiviraj spoke about what Very Large Databases were, maintaining them and some of the dos and don’ts. Since the first session started behind schedule, Preethiviraj was being hurried to finish his session sooner than the time slot allotted to him. It was a drawback that he had to cut down on his session, because all those who wanted to learn could see that he planned to deliver so much more but couldn’t because they were already behind schedule.

So hoping that next time’s SS SLUG meet up will try to improve on the shortcomings of October’s meetup and try to keep up the enthusiasm and the drive to learn in all the sessions they plan for the day.

Advertisements
Uncategorized

Dev vs QA and QA vs Dev! Competition or Complementation??

The IT World

I began my internship about 11 months back and I initially joined the QA team of the Company. But since I wanted to make a career in the Software Development track, I requested some involvement in certain Development work as well. But consecutively for about six months I solely worked as a Trainee QA Test Analyst. I was allocated to the highest revenue gaining project of the company, which performed updates on particular sites on a daily basis. Unlike the normal projects where the delivery date would be few months later, whereas in this project everyday is a delivery date for us, not less than working in a pizzeria I suppose.

During my QA days, I was the typical QA tester a Developer would encounter 😀 I picked on the silliest mistakes made by the developers, some were genuine while some were illogical bugs…Duh!! And I really could not figure out why the developers always considered the QA sector as their enemies who picked on every single thing they did and reported some illogical bugs which wasted time. Vice versa we QA people also considered the Developers as hard to work with, because it would some times take ages to get their consent on fixing a bug as well as proving that the discovered bug IS in fact a bug! (whew…)

While I was experiencing this tug of war, my request was finally considered and I was given a chance to work as a Developer in the Project that I worked as a QA Test Analyst. This opportunity was an immense eye opener for me as an intern as well as an observer sitting out of the frame.

Following the Cycle, I finished my Development and passed it on for QA. (And YES, if you think I QA’d it myself before sending it for the real QA cycle, you are absolutely CORRECT! I just wanted to make sure that there were no errors when i handed it in 😉 ) And so long for my confidence in zero errors… I got a report back with some errors that I never would have thought existed. But ironically in a developer’s viewpoint I clearly knew that those were not errors caused by the updates that I have made to the site.

For instance if QA reported a design issue, I would play by the cards and the first comment would be “Check if the bug exists in the live site as well”. And next would be, “If it does, let’s inform the leads and if it’s an issue they will let us know if we should fix it or not”. And lastly, “For now, just check the updates I have done, and if you find any issues outside the updates I’ve done, call it for considerations, but not as BUGS! 😉 “. Well these were the very lines I heard every single day when I had to play QA.

No it was not pay back time for me. Though for a second I spoke the same dialogue, I thought from the QA perspective as well. The errors could be certainly illogical, some cannot be solved due to the way it’s coded. But for a QA person, if something looks weird or behaves in an unexpected manner or rather it could be better, that becomes a defect. But when it comes to the hands of the Developer, either the code can’t be changed and it can be ignored or it’s more of a compatibility issue which is not in the hands of the developer.

From what I discovered during my working period was, the reason for the bridge between the understanding of Dev and QA is, that both do not know each others job, in simple terms. If QA got the Dev perspective, I wonder if any bugs would exist for that matter, but still for all, certain bugs that cannot be fixed at all, would be understood in the first place and wouldn’t require time to check those. On the other hand if Dev got a taste of the QA role, again I wonder, if there would be a requirement for a separate group called QA as such. And having said that, it’s better to have a dedicated group of people for that job because at the end of the day, the QA team does report some really good bugs 🙂

Finally for the developers who consider QA as a pain and QA who treat the Developers equally, like it or not, when it comes to the IT arena, both roles complement each other. Else one would be bug prone without the other!