software engineering

Oct 8 2008   10:35AM GMT

Bug Management - Major Concerns being felt across the Globe

Posted by: Jaideep
software quality assurance, software testing, Project Management, software, software quality, Quality Assurance, software engineering, Software testers, SDLC, software qa, Bug, Project Lifecycle, software testing cycle, software testing projects, softwaretesting, STLC, tester, project manager, testing environment, Bug Management

Senior Management including CIOs, QA Heads, CEOs, Development Heads, Project Heads, Customers, Vendors and/or sub-contractors related to software Organizations across the globe has repeatedly displayed their concern over the Bugs Management Process from time to time.

These concerns could be grouped as below:

1. The results of the Testing process are regularly inconsistent: This means that if same code is being tested by different group of testers under different leads, the results will vary always. Also the same team performing testing on different products will result in different performances.

2. The test results do not lead to more effective coding: The coding is always prone to create bugs (programmers are always as overconfident as ever).

3. The identification and quantification of a Bug is highly dubious: All the efforts by testing team in identifying and categorizing a bug is not always able to meet the seriousness it is meant for. Moreover sometimes a bug becomes an issue of debate over its category (critical/ severe/ desirable etc.).

4. Quality managers and testers often appear to have a limited knowledge of the code and business concepts and related issues.

5. Excessive focus and reliance on quantitative bug analysis is dangerous.

6. Bugs with a low probability occur more often than would be expected.

7. Bug management leads directly to bug avoidance.

8. Bug prioritization by Test managers is usually a simple ranking showing little or no understanding of the business process or customer requirements.

Most of the time the goal of testing is to diagnose the cause of bugs and produce better solutions. Instead the focus should be more on avoidance of bug generation at the code level so that least changes happen in the code once generated.

Sep 24 2008   10:39AM GMT

Is your defect (or bugs) report serving its purpose?

Posted by: Jaideep
software quality assurance, software testing, Project Management, software, software quality, Quality Assurance, software engineering, Software testers, SDLC, software qa, developer, Project Lifecycle, software testing cycle, software testing tips, softwaretesting, STLC, tester

Let us understand what is the purpose of bugs report or defects report? Is it serving its purpose? How much?

The purpose of a bugs report or defects report is to make the intended recipients of this report to understand each and every bug reported in its perspective view. A bugs report has to be quite elaborative in explaining the developers if any business or customer requirement has been failed to meet or has been built wrongly.

Logically defects or bugs report is a report card of testing process. This is the only way to find out how extensively and perfectly testing has been performed. How well have the business rules and customer requirements been understood by testers is reflected by the test cases performed. It also reflects how well Business requirements or customer requirements been documented.

The bugs or defects report not only reflects the total health of the system built but also shows how perfectly has been the testing performed, how well the requirements have been documented and how well the documented requirements been built into the system.

The quality of the product fails its purpose if the testing is not performed well. On the other hand a good testing of a bad system will not be of much use in ensuring a perfect system meeting customer’s requirements.

The bugs should be written so elaborative that they are quite clear to the development team to understand and act on it. These bug reports can be referred to any time in the future too. The more is the clarity or simulation required by the development team from testing team, the less is the purpose of bugs report being served. All it indicates is that the report needs improvement.

Sep 12 2008   10:35AM GMT

What is a Testing environment for software testing?

Posted by: Jaideep
software quality assurance, software testing, software, software quality, Quality Assurance, software engineering, Software testers, software qa, software testing tips, softwaretesting, tester, testing environment, software testing environment

A testing environment is a setup of software and hardware on which the testing team is going to perform the testing of the newly built software product. This setup consists of the physical setup which includes hardware, and logical setup that includes Server Operating system, client operating system, database server, front end running environment, browser (if web application), IIS (version on server side) or any other software components required to run this software product. This testing setup is to be built on both the ends – i.e. the server and client.

I remember a case where an application was built strictly as per customer requirements by a software vendor without understanding or taking it seriously that what database version the client is intends to use for this software. The vendor developed the application on Microsoft SQL Server x version and the client purchased the new server with the next version of MS SQL. When the product was completed at vendor side, he did a fantastic testing and made the software functionally very strong meeting customer’s all business needs. And when the product was launched at the customer location on the next version of OS and database, the product misbehaved (or did not perform) in few of the instances for which the technical team had to be sent to the customer site to fix the gaps and make it run hassle free. Now this not only affected the product cost but delayed the project deadlines in a major way. This small ignorance at both client and vendor end made a recursive effect at the vendors profits and next few projects.

The production or development team when completes a product development at their end, have to produce this test environment for testing team prior to loading their newly developed product on that environment for testing.

Sep 1 2008   10:20AM GMT

Ingredients of a successful Project

Posted by: Jaideep
Project Management, Quality Assurance, software engineering, SDLC, Project Lifecycle

It is not only the coding or development that accounts for a successful project. The journey starts right from the release of order from customer after which the customer requirements need to be studied accurately and extensively. This is going to be the foundation of the project. One small slippage or one wrong business requirement in customer requirement document may lead to a big cause of failure of a project. Now there are two ways of going about it. Either the organization has a product in place which is to be delivered with minor or major customization depending on how much customer requirements are meeting with the product already in place. In that case, the next step of mapping it with the existing product and simultaneously finding out the gaps is very crucial. As the clarity of customer requirements and business rules is important to build a right product, equally important is the clarity of gaps. Once gaps are clear, the role of developers comes into picture. Project Leader has to prepare a plan to finish off the job through his developers and under his guidance. The plan should be aesthetically adhered to, to complete the development in time.
Next comes the role of quality control department that has to ensure that the product finalized and finished is meeting customer requirements in all respects. Testing starts at various times in various projects and various organizations depending on the seriousness, methodology and awareness of the organization. Many organizations now involve testing team right from the beginning of a project at the time of its inception stage when not a single document has been prepared. Belief and fact is that involving testing team at this level always enhances the development and helps in meeting the deadlines better.
Documentation is a very important factor – be it user requirements, gap analysis, technical architecture of the product, database design document, ERD, users manual or any other relevant document.
Last but not the least comes the implementation team’s role. Each member plays a vital role especially when it is an overseas project and the success is very crucial. Going to a new environment, adjusting to a different culture, away from family, daily tight targets, late hours working are all the factors that have to be taken care of.

Aug 20 2008   10:21AM GMT

Project Management – I

Posted by: Jaideep
Project Management, software engineering, SDLC, Project Lifecycle

Project Management is nothing but adoption of a set of processes to ensure the smooth running of a project development passing through various stages and its successful and timely completion. It is the crux of any project as I too believe that it is not the people who make the projects successful, it is the processes and procedures adopted by the management responsible for the project. Project Management depends on how matured a company’s processes and procedures are. Broadly in terms of Project Management, organizations can be divided into three categories: First category will be of organizations having no or a very little system in place for Project Management. The organizations falling in second category would be those who have processes and procedures in place but not adequate for 100% successful Project Management and hence those organizations keep on striving for improvements by continuously analyzing, trying, good practices for enhancements, optimization, and successful project management. The third category of organization would be those who are matured, balanced, and a showcase for other organizations. When I say balanced, I mean they are neither too rigid nor too flexible in their practices. These organizations have a set of best practices in their sleeves being used for years, time and tested again and again. They would decide upon the best suitable practices depending on a specific project. When I say matured, I mean their success rate is higher than their peer organizations, they are the best in Project Management. Their employee turnover ratio is quite less, their employee satisfaction level, energy level and passion level is higher. They have not only adopted the best practices in their system, but in their organization culture, and in the blood of each employee.

For first and second category of organizations, the journey is long to reach to the final level, but equally higher is the scope to achieve it. Provided they have an urge, zeal and fire to achieve it, they stay on their levels for years. It is the management that has to drive it and for management it is sooner the better looking at the competition at global level and the expectations level of the customer. That does not mean that for the third category of organizations it is the end of the journey, rather it is difficult to maintain, sustain and keep improvising as everyone knows it is easier to reach at the top once than reaching every time, and maintaining it.

Aug 18 2008   10:18AM GMT

Project Management – A Sad Story – II

Posted by: Jaideep
software testing, Project Management, Development, software quality, Quality Assurance, software engineering, SDLC, software qa, Project Lifecycle, software testing cycle

This is in continuation to my earlier blog “Project Management – A Sad Story”  http://itknowledgeexchange.techtarget.co…). Keeping all the character names same as described there, I will update my readers on what happened to this particular project headed by Roberts. Although Roberts is new to these projects but is trying his best to get into each issue and address it appropriately keeping ‘common sense’ part intact while making a decision. Roberts knows and often tells others that project management is not only about the management of a project, it is about managing people working under you, it is also about customer. The story takes a couple of twists and turns and moves altogether differently.

Julia, the project leader, accepts her defeat, and resigns from the organization. Linda, Lisa, Paula, Edger and Alex are doubtful about the success or completion of this project. The issues that arose at customer site were majorly two as stated by the customer – one is that Julia is not competitive enough to understand business requirements and embed them into the software, and second is that Team has no purpose in staying at customer site till the product is complete. So they sent the team back to their country. Julia’s resignation is accepted as management also feels she is one of the reasons of this failure. Sandy, the QA head, is given an additional charge as project leader of this project. Sandy has a good record or project management and has been 100% successful in all the project he handled so fat prior to becoming the QA Head. One would wonder when he was so successful in Projects, why he became QA Head. Probably he knew that this Quality of ‘quality; of a product in him is one of the key factor for all his project management success. Sandy accepts this challenge but with an apprehension that before Julia stops coming to the organization, she atleast explains him the complete picture at customer site about project, requirements, and customer. Sandy has to not only take care of all customer needs to be built in the product, but also to ensure the quality aspect of it. The project is delayed by 20 odd days. Development team is working in the customer requirements. Sandy is overall now is the linking part between offshore customer and his development team (and also for his testing team).

Only apprehension Sandy has now is that if the fresh requirements brought by Julia were complete and exact or still if he has to face the similar situation again!

Let us wait and watch!

By the way – what is your opinion on this – what would happen to this project – SUCCESS or FAILURE!

Aug 14 2008   10:35AM GMT

Twelve essential Steps of Software Testing Life Cycle (STLC)

Posted by: Jaideep
software quality assurance, software testing, Project Management, software quality, Quality Assurance, software engineering, Software testers, SDLC, software qa, Project Lifecycle, software testing cycle, Software testing methodologies, software testing procedure, software testing process, software testing projects, software testing strategy, software testing tips, softwaretesting, STLC

STLC (Software Testing Life Cycle) is an integral component of SDLC (Software Development Life Cycle). Gone are the times when any software was made on the basis of its requirements and the moment it used to get completed by the development team, it got released to the customer. But now, Testing has become a distinct phenomenon during and after the development of software. No software is released to the customer without a comprehensive testing by QC or Testing team in the organization. The Scope and Methodology may vary from product to product, customer to customer, and organization to organization. There are certain aspects of Software Testing Life Cycle. To name top few among them, I would like to list twelve essential steps of Software Testing Life Cycle.

The Steps are to be followed from the start of Testing of software to the end of the testing as follows:
1- Before the dynamic testing, there is a static testing. Static testing includes review of documents required for the software development. This includes following activities:

(a) All the documents related to customer requirements and business rules that are required
for software design and development should be handed over to QA. These documents
should be complete and dually signed by client and representative of the company
(usually Project Manager).

(b) QA reviews these documents. The reviewing of documents includes comprehensive and
thorough study of the documents. If any discrepancy is found then it should be noted
and raised in the review meeting with the Development team.

(c) After this there should be a formal meeting between the QA and development team
regarding these documents, the agenda of this meeting mainly includes what is missing in
the document, QA queries to be answered by Development/Project Team and/or
clarification required for any confusions.

2- After the Software development or build of a module, QA starts dynamic testing. If during the development the requirement has been changed on customer demand or due to any other reason, then that should be documented and a copy of this revised document is given to the QA and also discussed as explained in point 1 above.

3- Development and Testing environment should be made clear to the QA by the Development team. It include the following activities:
(a)- Server to hit for Testing
(b)- Installation of latest build on the test server.
(c)- Modules/Screens to test.
(d)- Test duration as decided by test manager and project manager mutually based on scope
of work and team strength.
(e)– Demo of the software on test server by development team to the QC members.

4- After this Test cases and test scenarios are prepared and then the Test execution by QC.

5- A comprehensive Report of Bugs is prepared by the Testers and a review/verification by QC/QA/Testing Head takes place. Before handing over this report to Development Team there is a thorough review of Bugs List by Test Manager and in case of any clarification required on a bug submitted, the Testing Head discusses the bugs with the assigned tester.

6- Release of bug report by QC Team to Development Team.

7- Discussion/simulation of bugs by QC with development team if development team requires and time required for fixing the bugs should be made clear by Dev team at this stage.

8- Feedback from Development team on reported bugs with the stipulated time frame required to fix all bugs.

9- Any changes in the software being made in respect to fix these bugs should be made clear to the QA team by the Development team.

10- Testing team then Retests or verifies the bugs fixed by the development team.

11- Submitting the retesting bug report to the Test manager and after this the step 5 to step 10 are followed until the product has reached a stage where it can be released to customer.

12- Criteria for ending the testing should be defined by management or Test Manager Like when all major bugs are reported and fixed. Major bugs mean the bugs that affect the Business of the Client.

Aug 12 2008   11:00AM GMT

Eight Checkpoints for Testers during Software Testing

Posted by: Jaideep
software quality assurance, software testing, Project Management, Development, software quality, Quality Assurance, software engineering, Software testers, SDLC, software qa, software testing cycle, Software testing methodologies, software testing procedure, software testing process, software testing projects, software testing strategy, software testing tips, softwaretesting

Testing is a process of facilitating development team/ project team in improving the quality of software before it is released to the customer for use. Some key essential steps are always there that need to be followed by the Testers during Software Testing to streamline the process. The most important checkpoints for testers during software testing, in my opinion, would be:

(1)- Complete document of customer and business requirements specifying all the requirements for the development of the product.

(2)- Latest completed build and URL of the application to hit for Testing.

(3)- Software requirements for installing the application on PCs for testing or for database connectivity.

(4)-Training/Demo of the project by development team to Testing Team so as to understand the flow/functionality of the software.

(5)- Scope of testing should be made clear by the development team/Head.

(6)- If the build comes for retesting, then it should be accompanied by the revised document which includes the updated changes incorporated in the software.

(7)- Clarity regarding which member of development team should be contacted in case of any clarification required during the testing phase regarding the functionality of the module or if testers encounter a showstopper in the Software.

(8)- After release of the bugs list to development team, how much time they will require for fixing the bugs.