SQABD - Blog

2007 year roundup of SQABD

noreply@blogger.com (Tahmid Munaz) — Mon, 28 Jan 2008 07:57:00 +0000

Here is the 2007 year roundup of SQABD recently published. Please feel free to add comment with your suggestion or advice - cause it could add value to this community :)

Here are some noteworthy activities of SQABD during 2007:

1. SQABD had its' 11th roundtable on Career in SQA and Testing
2. SQABD's 3 Year Anniversary Celebration - sponsored by Ardites
3. SQABD had its' 12th roundtable meeting with SkypeCast facilities - sponsored by DSi. [Audio will be published soon]

4. SQABD started Testing Consultancy by consulting SECL Testers.
5. 180+ rich profiles of SQABD members with "LinkedIn SQABD".
6. SQABD is now on pageflakes: http://www.pageflakes.com/sqabd

7. Membership has doubled to 400+ by attracting the industry elites.
8. Moderate the mailing list for spam and random job ads to keep it professional and useful for our busy members.
9. SQABD has published the moderation guideline: http://tinyurl.com/262v73

Here is a short report on SQABD moderators activity in year 2007:

Year 2007

Members Banned

87

Members Removed

47

Posts Rejected

176

Posts Approved

344

Last 3 Month (Oct - Dec)

Members Banned

26

Members Removed

13

Posts Rejected

36

Posts Approved

57

SQABD tried to upheld the quality of the discussion in the group
There are more coming...

1. SQABD has recorded the Microsoft Career Event which will be published soon.
2. SQABD will release it's usability Tested website soon.
3. SQABD is planning for Technical Events with JPGroup and PHPExperts
4. SQABD has already recorded a video interview with Sohel Islam (from Microsoft) and will publish it soon

Thank you all for being with us and making it an enjoyable and motivating ride. Stay tuned for a great year ahead. :)

source: SQABD Yahoo Group: post # 1039

Fokhruz Zaman on Meet the Mentors by SQABD

noreply@blogger.com (Tahmid Munaz) — Mon, 26 Nov 2007 11:18:00 +0000

�??Meet the Mentors�?? on Fokhruz Zaman, CTO at Millennium Information Solution Ltd. has been published by SQABD very recently. Check out this link for more details:
http://sqabdmentors.blogspot.com/2007/11/fokhruz-zaman-on-meet-mentors-by-sqabd.html

Please reply to this below URL with the names of the mentors you know, the company they work for, and the areas they thrived, i.e. Project Management, Software Quality Assurance, Software Architecture, Programming etc.
http://tech.groups.yahoo.com/group/sqa_bangladesh/message/535

SQABD plans to interview these exceptional individuals and upload the recordings for everyone to hear.

SkypeCast was held for the SQABD Roundtable Meeting - 12th Session

noreply@blogger.com (Tahmid Munaz) — Sun, 17 Jun 2007 19:21:00 +0000

In last 16th June, 2007 - SQABD (www.sqabd.com) has arranged its' 12th Roundtable Meeting on topic of "State of Software Testing in Bangladesh" at Baton Rouge restaurant. Participants in the meeting was near about 20 persons. And there was an option for joining the meeting through SkypeCast. This Skypecast option for joining in SQABD meeting made people even to join from abroad and even for those person who were not able to join the meeting in person.

For a long time SQABD was thinking to come up with an option where our Bangladeshi Technical Experts from abroad can join the Roundtable Meetings and can add value to make it more productive. At last SQABD came up with the idea of using Skypecast at this 12th session in last Saturday so that anyone can join from anywhere.

Sometimes it becomes even tough for members who are not from Dhaka, and might not be able to attend this short 2/3 hours roundtable meeting coming from a remote area. So from now the SkypeCast will be a good way to join the SQABD Roundtable Meeting for anyone just by using a good broadband connection and Skype for connecting to SQABD Skypecast in time.

This is the 1st time any Technical Community in Bangladesh has arranged such an option for everyone to join through online which is more flexible to join for people who are in abroad or in a different city/remote area.

Please feel free to share your ideas or questions :)

State of Software Test Teams in BD - by SQABD

noreply@blogger.com (Tahmid Munaz) — Fri, 15 Jun 2007 01:56:00 +0000

SQABD (www.sqabd.com) announced it's 12th Roundtable Meeting on "State of Software Test Teams in BD" which is going to be held on next Saturday [16th June, 2007]. Anyone can join through the SkypeCast of SQABD which will be starting after 04:00 pm Bangladesh Time.

Date and Time: Saturday, June 16, 2007 [4:00pm to 6:00pm Bangladesh Time]

Topic: "State of Software Test Teams in BD"

Participants: 15 to 20 (Invited guest) + number of persons through SkypeCast

Agenda of Discussion:
Selected Senior Test Engineers and Test Team Leads will come together to share their experiences in software testing. Discussions will include tester evaluation process, training, hiring, useful testing tools, overcoming issues with the development team etc. We will discuss what works and what does not work, based on our experience.

SkypeCast:
https://skypecasts.skype.com/skypecasts/skypecast/detailed.html?id_talk=3000526&hash=e327899f81a5e8e693f3

Please feel free to join the Skypecast and add value to the event.

See detail at SQABD - SQA Bangladesh Group.

Khandakar Asif Hasan on �??Meet the Mentors�?? by SQABD

noreply@blogger.com (Tahmid Munaz) — Sat, 10 Feb 2007 21:51:00 +0000

Some of us were lucky to have them in our professional career. Others only heard of their deeds from the lucky ones. They touched our career, improved our skills, inspired us to excel, motivated us to thrive, and showed us the path to success. They were our mentors.

Who are these extraordinary people in the Software Industry of Bangladesh? How did they shape the people around them? We need to know. We need to learn from them.

SQABD successfully released the 1st Meet the Mentors session with Khandakar Asif Hasan and introducing such resource podcasting in Bangladesh for the 1st time.

Khandakar Asif Hasan is the Director at Spectrum Engineering Consortium ltd. He has more than 13 years of professional experience. The discussion includes:

His working experience.
What it takes to be a Software Architect.
Training the human resources in a software company.
Government policies regarding the software industry.
Comparison with India.
Automation, tools, risk analysis.
Collaboration between software companies.
Internship program.
and more...

URL : http://sqabdmentors.blogspot.com/2007/02/khandakar-asif-hasan-on-meet-mentors-by.html

Please send your feedbacks how was this podcasting and propose your mentors in SQABD community so that SQABD can present them infront of all and know more :)

2006 year roundup of SQABD

noreply@blogger.com (Tahmid Munaz) — Thu, 04 Jan 2007 06:54:00 +0000

It was really a satisfactory restart of this SQA_Bangladesh Community in 2006 after a long break. Everything was possible only for the support of the members and VIP persons of different Software Companies. Thanks to BASIS for having interest in sponsoring SQABD in different stages. Lets start a new year with more new thoughts and views and objectives.

Happy New Year :)

2006 came and went. It was an important milestone for SQABD. We were on a mission. It was a journey, and it has just begun. :)

Here are some noteworthy activities of SQABD during 2006:

The SQABD Management Team was formed.
Outlined the SQABD manifesto, mission and vision.
Held 10 roundtables on varying topics.
Designed the SQABD logo.
Registered www.sqabd.com
SQABD has cooperation agreements with PHPExperts, JPGroup, .Net Community and PHP Resources.
SQABD is now supported and promoted by BASIS.
50+ rich profiles of SQABD members with "LinkedIn SQABD".
Acquired the audio recording gear for the upcoming podcasts on the mentors of the Bangladesh software industry.
Moderate the mailing list for spam and job ads to keep it professional and useful for our busy members.
Membership has doubled to 200+ by attracting the industry elites.

Like I said, this is the beginning of a journey. So here is a list of what is coming in 2007:

Will recruit more volunteers for SQABD Management Team.
Design and develop the SQABD website (partially done).
More roundtables starting this January, on varying topics.
Podcasts on the mentors of the Bangladesh software industry, starting this January.
Build connections with more user groups.
And more still in planning stage. Will mention these as soon as the plans mature.

Thank you all for being with us and making it an enjoyable and motivating ride. Stay tuned for a great year ahead. :)

Eid Mubarak and a Happy New Year to all of you!!

- Sajjadul Hakim

source: SQABD Yahoo Group

Updates on Scott Ambler's activities

noreply@blogger.com (Tahmid Munaz) — Fri, 15 Dec 2006 17:25:00 +0000

I was little busy at work these few days, so couldn't post any new post in my SQABD Blog. In last few weeks i got few emails from Scott Amblers Yahoo Group and i would like to mention few of those below which could help others too :)

ANN: MS VSTS for Database Professionals
Posted by: "Scott Ambler"
Thu Dec 14, 2006 5:17 am (PST)

Deb Hartmann has posted an article at http://www.infoq.com/news/2006/12/vsts-for-database-launch where I was interviewed regarding the release of VSTS for Database Professionals. This product implements some of the ideas which I wrote about in Agile Database Techniques (www.ambysoft.com/books/agileDatabaseTechniques.html), and perhaps more importantly some of the refactorings that Pramod Sadalage and I describe in Refactoring Databases
(www.ambysoft.com/books/refactoringDatabases.html) .

It's great to see improving tool support for agile database development techniques. After almost two
decades of stagnation within the data community, we're finally starting to see new concepts, in particular agile ones, being adopted. The fact that we're starting to see improved database tools, and arguably even an entire new category in the form of database refactoring tools, is a sure sign that we're approaching the tipping point. The next two years should prove interesting.

- Scott

Objective View #10: Databases and Automated Training
Posted by: "Scott Ambler"
Wed Dec 13, 2006 10:40 am (PST)

I have an article on database refactoring in the issue which is posted at http://www.objectiveviewmagazine. com/

The issue is action packed as you can see from thelist of contents:

Features:
Kent Beck Interview
C# 2.0 & 3.0 Overview
Refactoring Databases
OODBMS Revisited
How to Work with Legacy Code

Opinion:
Grady Booch on SOA
Kevlin Henney - Why the Waterfall Fails
Matt Stephens - Ruby - I Love You (Not)

Plus:
Ed Yourdon - Structured Analysis - A Retrospective
TDD - Treating Tests as Code
EA's Model/Code Sync Features

- Scott

Agile Testing Strategies
Posted by: "Scott Ambler"
Tue Dec 12, 2006 3:18 pm (PST)

My January column is now available online at http://www.ddj.com/dept/debug/196603549?cid=Ambysoft . It describes strategies for testing on agile projects, showing how confirmatory and investigative testing techniques are applied effectively. I hope you find it interesting.

- Scott

Scott W. Ambler
Practice Leader Agile Development, IBM Methods Group
http://www-306. ibm.com/software /rational/ bios/ambler. html

source: http://tech.groups.yahoo.com/group/ambysoft/

SQA Engineers in Bangladesh

noreply@blogger.com (Tahmid Munaz) — Thu, 02 Nov 2006 16:01:00 +0000

I can see that in our Bangladesh perspective as the SQA Career path is very new in our IT scope, most of the SQA Engineers are not guided properly or misguided with wrong information. Even most of the Software Engineers think about SQA Engineering as just only a career of a simple Bug Reporter. A person who will be bugging the Development Team with number of valid and invalid Bugs and argu with them when needed.

This is a very usual scenario for where most of the companies don't even bother about Quality Development or even Standardized process. But now a days few of smart companies are comming up with the thought to standardized their own process and quality of service / development for further competion. Competition with different outsourcing neighbour companies or the local outsourcing companies.

Confusion on SQA Career is most of a common scenario in different developing countries. And the career path guidance is even dependent upon the enviroment where most of we SQA Engineers are working. The limitations, scopes everything depends on the environment or the place where we are working.

Here i am posting a reply that Mr. Sajjadul Hakim replied to a SQA Engineer in SQA Bangladesh Yahoo Group. As i see the Reply is very informative for all SQA Engineers (Newbie, Intermediate, Advanced, and Experts) so sharing it to all my Blog Readers.

This is the basic question that was asked ...

On 10/27/06, ****** ****** <***********@yahoo.com> wrote:

Hello Dear,
Actually I'm new in this group. Few months ago I
joined in a software company as a Jr. SQA Engr.
Actually I didn't know what is SQA. It was totally new
to me. And lot of my colleagues discouraged me. They
told there is no future of SQA in Bangladesh. I'm
confused. So can you tell me please about the prosect
of SQA in Bangladesh?

Regards
******
SQA Engineer

Replied by Sajjadul Hakim [ Tue Oct 31, 2006 12:35 pm ] as below

There is no easy answer to your question regarding the prospect of SQA career in Bangladesh. I would advice you to go through the following links and make your own judgment. I also want to encourage testers, who already have a career, to comment on their experiences.

The career prospect in Bangladesh was addressed in this group a long time ago, here:
http://tech.groups.yahoo.com/group/sqa_bangladesh/message/44

Recently we tried to address an interesting new role of Testers in Bangladesh, here:
http://tech.groups.yahoo.com/group/JPGroup/message/1679

Agile testing is becoming quite popular these days, and we addressed that here:
http://tech.groups.yahoo.com/group/sqa_bangladesh/message/376

The issue of choosing the right company for your career was addressed here:
http://tech.groups.yahoo.com/group/sqa_bangladesh/message/360

If you are concerned about training, then a good place to start was mentioned here:
http://tech.groups.yahoo.com/group/sqa_bangladesh/message/311

Always keep yourself updated about testing and SQA by participating in mailing lists. There is no alternative to this. Here is a list of useful mailing lists depending on your skill level:

Beginner: http://groups.yahoo.com/group/SQAtester/
Intermediate: http://groups.yahoo.com/group/Software_QA/
Advanced: http://groups.yahoo.com/group/software-testing/
Expert: http://groups.yahoo.com/group/agile-testing/

Regularly read the articles posted at www.stickyminds.com. This is a reliable source. Also, if you can subscribe to "Better Software" magazine, please do so immediately. You may also be eligible for a free subscription.

Always keep on the lookout for books and articles by these veterans, because the things they write are pretty profound:
Cem Kaner
James Bach
Bret Pettichord
Brian Marick

Always keep in touch with testers in Bangladeshi software companies that are recognized to have a good testing team. Networking is an important part of career growth. A few companies to mention are:
Metatude
Relisource
SoftwarePeople
Uniqa

Have a thorough knowledge of how testing fits in the SDLC. Have a good understanding of the SDLC.

Always brush up your programming skills. It can only make you better.

Work closely with the developers. Understand the development environment in your project and get acquainted to it, i.e. the IDE, OS, DB, dev process, deployment process etc. It can only make you better.

Software companies are always looking for skilled testers. Don't always rely on Bdjobs for your next job. Networking is a far better tool.

Your salary will depend on your skills, period. You will need to prove yourself.

So much to do...but whats the hurry. Just start the process. Feel free to comment. Thanks.

Regards,
Sajjad

Hope everyone gets help from this post :)

Agile Software Development and Business Analysis

noreply@blogger.com (Tahmid Munaz) — Thu, 26 Oct 2006 12:47:00 +0000

Recently Scott W. Ambler (practice leader Agile Development in the IBM methods group) wrote an article on "Agile Software Development and Business Analysis" in "Requrments Networking Group (RQNG)". You should need a membership to read the article from the group. RQNG offering Free membership, so you don't have to worry about the membership. You can collect the article in PDF file from the RQNG group or from the SQA Bangladesh - SQABD file section.

Download the PDF from RQNG

Source: ambysoft, rqng

Fixed Price Contracts

noreply@blogger.com (Tahmid Munaz) — Thu, 31 Aug 2006 14:06:00 +0000

Few days back Sajjadul Hakim posted a topics in SQA Bangladesh Group about "Fixed Price Contracts". I thought it will be nice to post in this Blog to focus the topics he discussed already. Here a pasted the whole topics with detail URL. Please feel free to discuss on this issue in the SQABD group if you are interested.
____________________________________________________________

Fixed Price Contracts

When does your project start failing? The day you accepted the project.

Most projects worked in Bangladesh are fixed price contracts.

A fixed-price (FP) contract between a provider and a customer defines
the scope, features, planning, timing and price of a software project.
Pretty much everything is fixed, not only the price.

How do you make sure you are not walking into the lion's den? There is
a good article on projects that are based on fixed price contracts,
called "Agile Fixed Price Projects part 1: The Price Is Right". You
can read it here (PDF attached):
http://groups.yahoo.com/group/sqa_bangladesh/files/fixedpriceprojects.pdf

In the following I tried to write a summary with some comments to
influence you to read the entire article. Here goes�?�

# There is a project in the horizon�?�Do you qualify�?�
----------------------------

Question 1: Do I know the domain?
You can't really estimate and develop the software within deadline if
you are new to the domain. The software is all about providing a
solution to the customer. It is very difficult to do that if you have
no experience in the domain.

Question 2: Do I know the technology?
It is not practical to experiment with new technology and tools when
you have a deadline to meet.

Question 3: Can I work with my usual team?
Get the project signed off. Now hire engineers to form the team. This
is a recipe for disaster. You can't really estimate efficiency and
performance of engineers if you haven't worked with them.

Question 4: Can I handle the estimated project size?
If you and your team have worked on short projects, you will be taking
a huge risk undertaking a long project. If you have worked with small
teams, you will be taking a huge risk managing a big team.

# Hooray, you qualify�?�Should you accept the project�?�
--------------------------------

Sales tip 1: Don't just respond to "Request For Proposal" (RFP)
Let's talk about our government. Government floats tenders with RFP
document for software projects. Software companies (vendors) submit
their bids based on the instructions in the RFP document. The proposal
contains specification, timing, planning and price. The government
chooses the best proposal (yeah right). Always get more info from the
customer personally before creating the proposal, since the RFPs are
incomplete. You must do this to estimate better.

Sales tip 2: It works both ways
You will have a deadline to meet. That means you will need certain
info and feedback from the customer within certain timeframes or else
you may miss the deadline. So add these conditions in your contract,
i.e. the customer should deliver some information by a certain date;
provide testing feedback within a certain date etc.

Sales tip 3: Don't underbid
If you know how much the project will cost, then don't underbid just
to throw off your competition. How will you compensate for the loss if
you win the project? By giving the customer less than they asked for?
Good luck with that.

Sales tip 4: Add some slack to cover the risks
Your estimates are always flawed. Accept it. Keep buffer time. Don't
cut your buffer to underbid your competitor.

Sales tip 5: Real business requirements
Write the specification with the customer. If the customer is
reluctant to give you enough info, then chances are he will do the
same after you get the project. In any case, you don't have enough
info to estimate. If you go through with it you will probably fail the
deadline.

# Got the job�?�Rough ride ahead�?�
--------------------------------

Implementation tip 1: Don't allow change requests
I don't want to comment on this. Better read the entire section in the
document. Here is a quote from the doc: "Don't use Change Requests
because their drawbacks heavily outweigh any initial advantages they
bring"

Implementation tip 2: Spend your slack wisely
Things will go wrong. Prepare for it. Use your buffer time wisely.
Leave some buffer for the end. Usually that's when the heat is on.

Implementation tip 3: Simple, honest and correct tracking
Remember the Green Shift Anti-pattern in one of my previous post? Look
it up here:
http://groups.yahoo.com/group/sqa_bangladesh/message/431

Implementation tip 4: Manage your project
Be proactive. Let the team solve problems with you. Let the team
interact with customers. Stay alert for creeping issues.

Now I am done�?�for now at least. Deadline oriented projects are always
high risk. The above steps should minimize the risks involved.

This may work for you if you are getting projects abroad. But let's
face facts�?�you won't really get too many projects that fit all the
criteria in Bangladesh. The author has created another article that
brings a little agility to fixed price contracts. Will post that
later. Thanks.

Regards,
Sajjad

_______________________________________________
source: SQA Bangladesh (www.sqabd.com)

The Green Shift Anti-Pattern

noreply@blogger.com (Tahmid Munaz) — Thu, 31 Aug 2006 13:12:00 +0000

In Dr. Dobb's Agile Newsletter of july 2006, Scott W. Ambler wrote an article about "Green Shift"

The problem is that the project status "green shifted" as it rose through the various levels of management. The people on the ground were very clearly reporting a red project status, our project manager wanted to play it safe so reported yellow status, and his manager was more political yet and reported green status.

In astronomy there is the concept of red-shifting and blue-shifting: red shifting occurs when a body is moving away from you (the wavelength of the light increases) and blue-shifting occurs when a body is moving towards you (the wavelength of the light decreases). This is useful input for determining the speed and direction of something. In software development we have green shifting which occurs when people rework the information contained in status reports to make them more politically palatable to their manager.

A few years ago I was involved with a seriously challenged project. In my weekly status report to the project manager I would very bluntly list all of the problems we were experiencing. Strangely, even though myself and several others were clearly documenting the problems, all of which were out of our control, nothing ever seemed to happen. After a few weeks of this I ran into the CIO and she congratulated me on how well the project was going. I was surprised, and told her that the project was in serious trouble and summarized the critical issues for her. It was news to her.

After a bit of investigation we discovered that although myself and team members had been reporting the serious political challenges that the project team faced, when our project manager summarized our reports he decided to put a better spin on it and reported that the team found the project challenging. His manager in turn reworked it in his report that the team enjoyed the challenges it faced. This was the report which the CIO received.

The problem is that the project status "green shifted" as it rose through the various levels of management. The people on the ground were very clearly reporting a red project status, our project manager wanted to play it safe so reported yellow status, and his manager was more political yet and reported green status.

Other continued pages : 2, 3, 4

Source: http://www.ddj.com , http://fscorner.blogspot.com

Software Quality Assurance

noreply@blogger.com (Tahmid Munaz) — Tue, 22 Aug 2006 14:47:00 +0000

              SOFTWARE QUALITY ASSURANCE


A.   Concepts and Definitions

Software Quality Assurance (SQA) is defined as a planned and
systematic approach to the evaluation of the quality of and
adherence to software product standards, processes, and
procedures.  SQA includes the process of assuring that
standards and procedures are established and are followed
throughout the software acquisition life cycle. Compliance
with agreed-upon standards and procedures is evaluated
through process monitoring, product evaluation, and audits.
Software development and control processes should include
quality assurance approval points, where an SQA evaluation
of the product may be done in relation to the applicable
standards.

B.   Standards and Procedures

Establishing standards and procedures for software
development is critical, since these provide the framework
from which the software evolves.  Standards are the
established criteria to which the software products are
compared.  Procedures are the established criteria to which
the development and control processes are compared.
Standards and procedures establish the prescribed methods
for developing software; the SQA role is to ensure their
existence and adequacy.  Proper documentation of standards
and procedures is necessary since the SQA activities of
process monitoring, product evaluation, and auditing rely
upon unequivocal definitions to measure project compliance.

Types of standards include:

  Documentation Standards specify form and content for
planning, control, and product documentation and provide
consistency throughout a project. The NASA Data Item
Descriptions (DIDs) are documentation standards (see
Appendix B).

  Design Standards specify the form and content of the
design product.  They provide rules and methods for
translating the software requirements into the software
design and for representing it in the design
documentation.

  Code Standards specify the language in which the code
is to be written and define any restrictions on use of
language features.  They define legal language
structures, style conventions, rules for data structures
and interfaces, and internal code documentation.

Procedures are explicit steps to be followed in carrying out
a process.  All processes should have documented procedures.
Examples of processes for which procedures are needed are
configuration management, nonconformance reporting and
corrective action, testing, and formal inspections.

If developed according to the NASA DID, the Management Plan
describes the software development control processes, such
as configuration management, for which there have to be
procedures, and contains a list of the product standards.
Standards are to be documented according to the Standards
and Guidelines DID in the Product Specification.  The
planning activities required to assure that both products
and processes comply with designated standards and
procedures are described in the QA portion of the Management
Plan.

C.   Software Quality Assurance Activities

Product evaluation and process monitoring are the SQA
activities that assure the software development and control
processes described in the project's Management Plan are
correctly carried out and that the project's procedures and
standards are followed. Products are monitored for
conformance to standards and processes are monitored for
conformance to procedures.  Audits are a key technique used
to perform product evaluation and process monitoring.
Review of the Management Plan should ensure that appropriate
SQA approval points are built into these processes.

Product evaluation is an SQA activity that assures standards
are being followed.  Ideally, the first products monitored
by SQA should be the project's standards and procedures. SQA
assures that clear and achievable standards exist and then
evaluates compliance of the software product to the
established standards.  Product evaluation assures that the
software product reflects the requirements of the applicable
standard(s) as identified in the Management Plan.

Process monitoring is an SQA activity that ensures that
appropriate steps to carry out the process are being
followed.  SQA monitors processes by comparing the actual
steps carried out with those in the documented procedures.
The Assurance section of the Management Plan specifies the
methods to be used by the SQA process monitoring activity.

A fundamental SQA technique is the audit, which looks at a
process and/or a product in depth, comparing them to
established procedures and standards.  Audits are used to
review management, technical, and assurance processes to
provide an indication of the quality and status of the
software product.

The purpose of an SQA audit is to assure that proper control
procedures are being followed, that required documentation
is maintained, and that the developer's status reports
accurately reflect the status of the activity.  The SQA
product is an audit report to management consisting of
findings and recommendations to bring the development into
conformance with standards and/or procedures.


D.   SQA Relationships to Other Assurance Activities

Some of the more important relationships of SQA to other
management and assurance activities are described below.

1.   Configuration Management Monitoring

SQA assures that software Configuration Management (CM)
activities are performed in accordance with the CM plans,
standards, and procedures. SQA reviews the CM plans for
compliance with software CM policies and requirements and
provides follow-up for nonconformances.  SQA audits the CM
functions for adherence to standards and procedures and
prepares reports of its findings.

The CM activities monitored and audited by SQA include
baseline control, configuration identification,
configuration control, configuration status accounting, and
configuration authentication.  SQA also monitors and audits
the software library.  SQA assures that:

  Baselines are established and consistently maintained
for use in subsequent baseline development and control.

  Software configuration identification is consistent and
accurate with respect to the numbering or naming of
computer programs, software modules, software units, and
associated software documents.

  Configuration control is maintained such that the
software configuration used in critical phases of
testing, acceptance, and delivery is compatible with the
associated documentation.

  Configuration status accounting is performed accurately
including the recording and reporting of data reflecting
the software's configuration identification, proposed
changes to the configuration identification, and the
implementation status of approved changes.

  Software configuration authentication is established by
a series of configuration reviews and audits that exhibit
the performance required by the software requirements
specification and the configuration of the software is
accurately reflected in the software design documents.

  Software development libraries provide for proper
handling of software code, documentation, media, and
related data in their various forms and versions from the
time of their initial approval or acceptance until they
have been incorporated into the final media.

  Approved changes to baselined software are made
properly and consistently in all products, and no
unauthorized changes are made.

2.   Verification and Validation Monitoring

SQA assures Verification and Validation (V&V) activities by
monitoring technical reviews, inspections, and walkthroughs.
The SQA role in formal testing is described in the next
section.  The SQA role in reviews, inspections, and
walkthroughs is to observe, participate as needed, and
verify that they were properly conducted and documented.
SQA also ensures that any actions required are assigned,
documented, scheduled, and updated.

Formal software reviews should be conducted at the end of
each phase of the life cycle to identify problems and
determine whether the interim product meets all applicable
requirements.  Examples of formal reviews are the
Preliminary Design Review (PDR), Critical Design Review
(CDR), and Test Readiness Review (TRR).  A review looks at
the overall picture of the product being developed to see if
it satisfies its requirements. Reviews are part of the
development process, designed to provide a ready/not-ready
decision to begin the next phase.  In formal reviews, actual
work done is compared with established standards.  SQA's
main objective in reviews is to assure that the Management
and Development Plans have been followed, and that the
product is ready to proceed with the next phase of
development.  Although the decision to proceed is a
management decision, SQA is responsible for advising
management and participating in the decision.

An inspection or walkthrough is a detailed examination of a
product on a step-by-step or line-of-code by line-of-code
basis to find errors.  For inspections and walkthroughs, SQA
assures, at a minimum, that the process is properly
completed and that needed follow-up is done.  The inspection
process may be used to measure compliance to standards.

3.   Formal Test Monitoring

SQA assures that formal software testing, such as acceptance
testing, is done in accordance with plans and procedures.
SQA reviews testing documentation for completeness and
adherence to standards.  The documentation review includes
test plans, test specifications, test procedures, and test
reports.  SQA monitors testing and provides follow-up on
nonconformances.  By test monitoring, SQA assures software
completeness and readiness for delivery.

The objectives of SQA in monitoring formal software testing
are to assure that:

  The test procedures are testing the software
requirements in accordance with test plans.

  The test procedures are verifiable.

  The correct or "advertised" version of the software is
being tested (by SQA monitoring of the CM activity).

  The test procedures are followed.

  Nonconformances occurring during testing (that is, any
incident not expected in the test procedures) are noted
and recorded.

  Test reports are accurate and complete.

  Regression testing is conducted to assure
nonconformances have been corrected.

  Resolution of all nonconformances takes place prior to
delivery.

Software testing verifies that the software meets its
requirements.  The quality of testing is assured by
verifying that project requirements are satisfied and that
the testing process is in accordance with the test plans and
procedures.

E.   Software Quality Assurance During the Software Acquisition Life Cycle

In addition to the general activities described in
subsections C and D, there are phase-specific SQA activities
that should be conducted during the Software Acquisition
Life Cycle.  At the conclusion of each phase, SQA
concurrence is a key element in the management decision to
initiate the following life cycle phase.  Suggested
activities for each phase are described below.

1.   Software Concept and Initiation Phase

SQA should be involved in both writing and reviewing the
Management Plan in order to assure that the processes,
procedures, and standards identified in the plan are
appropriate, clear, specific, and auditable. During this
phase, SQA also provides the QA section of the Management
Plan.

2.   Software Requirements Phase

During the software requirements phase, SQA assures that
software requirements are complete, testable, and properly
expressed as functional, performance, and interface
requirements.

3.   Software Architectural (Preliminary) Design Phase

SQA activities during the architectural (preliminary) design
phase include:

  Assuring adherence to approved design standards as
designated in the Management Plan.

  Assuring all software requirements are allocated to
software components.

  Assuring that a testing verification matrix exists and
is kept up to date.

  Assuring the Interface Control Documents are in
agreement with the standard in form and content.

  Reviewing PDR documentation and assuring that all
action items are resolved.

  Assuring the approved design is placed under
configuration management.

4.   Software Detailed Design Phase

SQA activities during the detailed design phase include:

  Assuring that approved design standards are followed.

  Assuring that allocated modules are included in the
detailed design.

  Assuring that results of design inspections are
included in the design.

  Reviewing CDR documentation and assuring that all
action items are resolved.

5.   Software Implementation Phase

SQA activities during the implementation phase include the
audit of:

  Results of coding and design activities including the
schedule contained in the Software Development Plan.

  Status of all deliverable items.

  Configuration management activities and the software
development library.

  Nonconformance reporting and corrective action system.

6.   Software Integration and Test Phase

SQA activities during the integration and test phase
include:

  Assuring readiness for testing of all deliverable
items.

  Assuring that all tests are run according to test plans
and procedures and that any nonconformances are reported
and resolved.

  Assuring that test reports are complete and correct.

  Certifying that testing is complete and software and
documentation are ready for delivery.

  Participating in the Test Readiness Review and assuring
all action items are completed.

7.   Software Acceptance and Delivery Phase

As a minimum, SQA activities during the software acceptance
and delivery phase include assuring the performance of a
final configuration audit to demonstrate that all
deliverable items are ready for delivery.

8.   Software Sustaining Engineering and Operations Phase

During this phase, there will be mini-development cycles to
enhance or correct the software.  During these development
cycles, SQA conducts the appropriate phase-specific
activities described above.


F.   Techniques and Tools

SQA should evaluate its needs for assurance tools versus
those available off-the-shelf for applicability to the
specific project, and must develop the others it requires.
Useful tools might include audit and inspection checklists
and automatic code standards analyzers.


source: http://jira.atlassian.com

Thanks!

noreply@blogger.com (Tahmid Munaz) — Mon, 17 Jul 2006 14:51:00 +0000

We are thankfull to the following persons for helping and designing our SQABD community logo with their valuable professional touch:

Ahsan Parvez Liton, Evoknow
Tarique Mahmud Tomal, Uniqa

Bridging Agile and Traditional Dev. Methods

noreply@blogger.com (Tahmid Munaz) — Mon, 03 Jul 2006 16:10:00 +0000

Bridging Agile and Traditional Development Methods: A Project Management Perspective
Paul E. McMahon, PEM Systems

Today, companies are reporting success in meeting rapidly changing customer needs through agile development methods. Many of these same companies are finding they must collaborate with organizations employing more traditional development processes, especially on large Department of Defense projects. While it has been argued that agile methods are compatible with traditional disciplined processes, actual project experience indicates conflicts can arise. This article identifies specific project management conflicts that companies face based on actual project experience, along with strategies employed to resolve these conflicts and reduce related risks. Rationale, insights, and related published references are provided along with lessons learned and recommendations. If you work for a company that is using or considering using agile development, or your company is collaborating with a company using an agile method, this article will help you understand the risks, issues, and strategies that can help your project and organization succeed.

This article was motivated by a case study where a small company using a well-known agile method - eXtreme Programming (XP) - requested help addressing specific conflicts that arose on the project where they were a subcontractor to a larger organization employing a traditional development method. The purpose of this article is not to compare agile and traditional methods, but to raise awareness of potential project management conflicts that can arise when a company employing an agile method collaborates with a company employing a traditional development methodology. It also identifies practical steps that can be taken to reduce related risks.

It is worth noting that the case study presented is not unique. Published references documenting similar conflicts are provided. Also notable is that the motivation for examining this project extends beyond the case study itself. Today there exist increasing opportunities for small companies to gain new work through software outsourcing from traditional development organizations.

Where Are We Going?

In this article, I first identify key case study facts along with relevant information and common misperceptions related to traditional and agile methods. Next, I identify four conflicts observed along with five recommendations and one lesson learned. The company named SubComp refers to the subcontractor employing an agile methodology. The company named PrimeComp refers to the prime contractor employing a traditional development methodology.

(see more from Source : Cross Talk)

The Agile System Development Lifecycle (SDLC)

noreply@blogger.com (Tahmid Munaz) — Mon, 03 Jul 2006 15:39:00 +0000

The Agile System Development Lifecycle (SDLC)
by Scott W. Ambler

I'm often asked by clients to facilitate workshops overviewing the ideas presented in the Agile Manifesto and agile techniques such as Test-Driven Design (TDD) , database refactoring , and agile change management . One issue that many people seem to struggle with is how all of these ideas fit together, and invariably I found myself sketching a picture which overviews a generic lifecycle for agile software development projects. This lifecycle is captured in Figure 1, which is comprised of four phases: Iteration 0, Development, Release/End Game, and Production. Although many agile developers may balk at the idea of phases, perhaps Gary Evan's analogy of development seasons may be a bit more palatable, the fact is that it's been recognized that processes such as Extreme Programming (XP) and Agile Unified Process (AUP) do in fact have phases (for diagrams, see XP lifecycle and AUP lifecycle respectively). Furthermore, the Agile MSF calls its phases/seasons "tracks".

See more from Source : Agile SDLC

"Source Control HOWTO" - by Eric Sink

noreply@blogger.com (Tahmid Munaz) — Mon, 03 Jul 2006 15:04:00 +0000

Source Control HOWTO

by Eric Sink

I have started writing a series of articles explaining how to do source control and the best practices thereof. See below for links to the individual chapters in this series. The Introduction explains my motivations and goals for writing this series.

Please note: This is a work in progress. I plan to be adding new chapters over time, and I may also be revising the existing chapters as I go along.

Printer-friendly version: Sorry folks, but I currently do not have this material available in a form which is more suitable for paper. Someday I probably will, and when that happens, a link will appear here.

Chapter 0: Introduction

Our universities don't teach people how to do source control. Our employers don't teach people how to do source control. SCM tool vendors don't teach people how to do source control. We need some materials that explain how source control is done. My goal for this series of articles is to create a comprehensive guide to help meet this need.

Chapter 1: Basics

Our discussion of source control must begin by defining the basic terms and describing the basic operations.

Chapter 2: Checkins

In this chapter, I will explore the various situations wherein a repository is modified, starting with the simplest case of a single developer making a change to a single file.

(read more)

_______________________________________
Thanks to Eric Sink for his valuable article

SQA as a Career !

noreply@blogger.com (Tahmid Munaz) — Tue, 27 Jun 2006 11:08:00 +0000

Most of the Computer Science graduates in Bangladesh and even in different countries, don't know that SQA can be a career path for their career development. Lets know little about SQA here:

What is Software Quality Assurance?
SQA is the short form of "Software Quality Assurance". Quality Assurance consists of the the processes and methods used to ensure quality. This may include processes such as reviewing requirements documents, source code control, change management, configuration management and of course, software testing.

What is Software Testing?
The principal aim of testing is to detect faults so that they can be removed before the product is made available to customers. It is often referred to as Quality Control.

The British Standards Institution, in their standard BS7925-1, define testing as:
"The process of exercising software to verify that it satisfies specified requirements and to detect faults; the measurement of software quality."

Faults in software are made for a variety of reasons, from misinterpreting the requirements through to simple typing mistakes. It is the role of software testing to reduce those faults by identifying the failures.

What is the difference between QA and Testing?
Quality Assurance can be thought of as a means of preventing software faults, whereas testing is a means of detecting them.

Quality Assurance (QA) encompasses the entire software development process including processes such as code reviews and release management. It is the processes followed by people within the project (Project Managers, Analysts, Developers, Testers etc.) to prevent problems and assure quality.

Software testing is a subset of Quality Assurance; it is one of the processes for ensuring software quality. Software testing is also often called Quality Control(QC) where QC is the measurement of the quality of a product.

Quality Assurance is a monitoring and accountability function that encompasses an entire project to ensure processes, activities, tasks used produce deliverables that result in a quality end product. Its doctrines can be applied to all types of projects. Software Testing is a phase of software development.

About Quality Management:
There are main 3 points of Quality management which we all need to know

QUALITY ASSURANCE sets the environment (standards and practices) for ensuring quality products
QUALITY CONTROL measures the quality of work products, and makes corrections for quality failures
QUALITY IMPROVEMENT analyses and corrects the systemic reasons for quality failures

Without measurement, there can be no control of quality, only the illusion that quality is "under control". TESTING is the set of activities (static and dynamic) by which a QC organisation does the measurement. The "work products" tested need not be restricted to executable program code ("dynamic testing"); requirements documents, specifications, designs, and other project artefacts may all be quality controlled by "static testing".

80% of quality failures (defects) derive from failures in process ("common causes"). Essentially, these are failures in QA (which establishes the environment for quality) and QC (which regulates the quality environment). QI analyses the deviation (defect) information provided by QC, and identifies improvements in:

QA activities to prevent recurrence of the defects; and
QC activities to ensure their earlier detection or avoidance.

Feedbacks about SQA and it's Career paths:
http://groups.yahoo.com/group/SQAtester/message/13803?threaded=1&var=1

Sources: sqatesters.com , softwaretestingwiki.com , Wikimedia , sqabd.com

Introduction

noreply@blogger.com (Tahmid Munaz) — Tue, 27 Jun 2006 10:40:00 +0000

I started this page for focusing different Article discussed on SQA Bangladesh community which might help peoples to know more and share knowledge from one end to another.

Total plan will be written later on..

SQABD - Blog

2007 year roundup of SQABD

Fokhruz Zaman on Meet the Mentors by SQABD

SkypeCast was held for the SQABD Roundtable Meeting - 12th Session

State of Software Test Teams in BD - by SQABD

Khandakar Asif Hasan on �??Meet the Mentors�?? by SQABD

2006 year roundup of SQABD

Updates on Scott Ambler's activities

ANN: MS VSTS for Database Professionals
Posted by: "Scott Ambler"
Thu Dec 14, 2006 5:17 am (PST)

Objective View #10: Databases and Automated Training
Posted by: "Scott Ambler"
Wed Dec 13, 2006 10:40 am (PST)

Agile Testing Strategies
Posted by: "Scott Ambler"
Tue Dec 12, 2006 3:18 pm (PST)

SQA Engineers in Bangladesh

Agile Software Development and Business Analysis

Fixed Price Contracts

The Green Shift Anti-Pattern

Software Quality Assurance

Thanks!

Bridging Agile and Traditional Dev. Methods

The Agile System Development Lifecycle (SDLC)

"Source Control HOWTO" - by Eric Sink

SQA as a Career !

Introduction

Year 2007
Members Banned	87
Members Removed	47
Posts Rejected	176
Posts Approved	344

Last 3 Month (Oct - Dec)
Members Banned	26
Members Removed	13
Posts Rejected	36
Posts Approved	57

SQABD - Blog

2007 year roundup of SQABD

Fokhruz Zaman on Meet the Mentors by SQABD

SkypeCast was held for the SQABD Roundtable Meeting - 12th Session

State of Software Test Teams in BD - by SQABD

Khandakar Asif Hasan on �??Meet the Mentors�?? by SQABD

2006 year roundup of SQABD

Updates on Scott Ambler's activities

ANN: MS VSTS for Database ProfessionalsPosted by: "Scott Ambler" Thu Dec 14, 2006 5:17 am (PST)

Objective View #10: Databases and Automated TrainingPosted by: "Scott Ambler" Wed Dec 13, 2006 10:40 am (PST)

Agile Testing StrategiesPosted by: "Scott Ambler" Tue Dec 12, 2006 3:18 pm (PST)

SQA Engineers in Bangladesh

Agile Software Development and Business Analysis

Fixed Price Contracts

The Green Shift Anti-Pattern

Software Quality Assurance

Thanks!

Bridging Agile and Traditional Dev. Methods

The Agile System Development Lifecycle (SDLC)

"Source Control HOWTO" - by Eric Sink

SQA as a Career !

Introduction

ANN: MS VSTS for Database Professionals
Posted by: "Scott Ambler"
Thu Dec 14, 2006 5:17 am (PST)

Objective View #10: Databases and Automated Training
Posted by: "Scott Ambler"
Wed Dec 13, 2006 10:40 am (PST)

Agile Testing Strategies
Posted by: "Scott Ambler"
Tue Dec 12, 2006 3:18 pm (PST)