Your Ad Here

Monday, July 26, 2010

How to Prepare Cross Functional Flowchart in MS Visio

This is pretty simple. Follow the steps written below and see the output attached:

1. Open MS Visio 2007 (whichever version you have)

2. Go to File > New > Flowchart > Cross Functional Flowchart

3. Drag and Drop Functional Bands from Cross Functional Flowchart Shape

4. Drag and Drop Separator, if required, in your diagram

5. Decide the flowchart logic on a pen and paper and replicate the same on Visio

6. Color the Fonts, Links, Lines etc to your choice


Visio Cross Functional Flowchart


See the attached document for your reference. You can generated better documents based on the complexity of the flow. I have illustrated with a simple business case - Recruitment Process in an organization.

Wednesday, June 2, 2010

A Generic Workflow Diagram

A generic workflow comprises of following three items:

i. Input
ii. Validation
iii. Process
READ MORE >>




Wednesday, April 28, 2010

3 Attitudes of a Project Manager – Optimist, Pessimist and Realist

Project management is a complex role to play. The project manager does the requirements gathering, feasibility studies, planning, execution and risk mitigation. In the endeavor, the manager has three different takes – optimist, pessimist and realist. Well, how can the same person have three different attitudes? This is both exciting as well as challenging.

Sunday, March 21, 2010

How to Answer Tough Interview Questions?


I posted this on http://www.lifeheed.com/ (http://www.lifeheed.com/article.php?article=35) earlier and thought it would be valuable for community who are following this blog.

If you are looking for a job change, be prepared for the interview process. Well, preparations may not always help. You may get surprise questions in the interview. You need to apply presence of mind, competence and communication capability to approach towards such questions. Let us first understand what sort of the questions are these and then we will take an approach to ace the interview.

Wednesday, March 17, 2010

Tips for a Résumé to Survive Screening

 
As the market has shown the signs of recovery, you must be looking forward to get a good job opportunity in testing. In the sea of résumés before the recruiter, your résumé really needs to stand out. Needless to say, that résumé can make or break your chances to get even first call.

Use these tips to boost your résumé's chance of survival in the initial scrutiny:

What is END and NED?

Simply put,

END = Evidence of no defect
NED = No evidence of defect

Sunday, March 14, 2010

Test Cases for Triangles

We have studied the properties of various triangles in school. Let us apply those properties to test a triangle today.

A triangle is made of three sides (and three angles of course). Let us assume that the vertices are A, B and C, and corresponding sides are a, b, c.



Test cases follow:

1. Enter 0, a, b. No triangle is formed.
2. Enter 1, 2, 4. No triangle is formed because for a valid triangle a+b>c, b+c>a, c+a>b.
3. Enter angles A, B, C. The sum of the angles should be 180 degrees.
4. Enter a, a, a. Valid equilateral triangle.
5. Enter a, a, b. Valid isosceles triangle.
6. Enter angles A, B, C. If any of the angles is 90 degrees and the sum is 180 degrees, it is a right angle triangle.
7. Enter angles A, B, C as 90, 90, 0. The sum of angles is 180 degrees, still the triangle cannot be formed.
8. Enter negative value for a side, e.g. -1, -1, -1. Invalid input.
9. Enter character value for one of the sides, e.g. a, 2, 2. Invalid input.

Please add more to this.

Tuesday, February 16, 2010

Traceability Matrix: How to Map Requirements to Test Cases

Refer to following articles for more:
When you write test cases from a requirement document or use case document, you should remain sensitive towards the coverage of the requirement and converting them to testable items. The test cases are designed keeping in mind about the requirements coverage. If there are areas not covered in the test case, it will go untested. In order to verify whether all the requirements are being tested or not, Traceability Matrix is created. It maps requirements to the test cases.

Friday, February 12, 2010

How to Work in TDD Methodology of Software Development


Test Driven Development methodology of software development is one of the most popular flavor of agile methodology. Other popular flavors of agile are Scrum, Extreme Programing (XP), Function Driven development (FDD) etc. The main principle behing TDD is to write unit test cases first and then code the unit of the module so that the unit passes the test. TDD saves a lot of time and money in finding the sofwtare defects at the later stage of software development. Farther the testing cycle falls, higher would be the cost to fix the issue.

How to Conduct Performance Evaluation of Agile Team


Traditional performance measurements are successful with the traditional methodology of software development, where we stress more on individual contributions towards creating the software and reporting is made hierarchical in nature. In agile, the evaluation must also be adaptive, collaborative and frequent.

The traditional performance evaluations focus more on the individual performance and training needs. Whereas, in cross-functional team of agile evaluation of only individual performance would not be fair. So what stand should you take in such a case?

Wednesday, February 10, 2010

How to Measure Agile Team Members' Performance


The key elements of agile (say Scrum) methodology of software development is the team is cross-functional, collaborative and self-organized. Means, in Scrum, the entire team is responsible to execute the Sprint tasks; not the individual member of the team. So, the success or failure of the Sprints is based on the cumulative performance of the team. There is, however, a problem in judging an individual's performance; because each team member is not highlighted much during the product development.

How to Conduct Daily Scrum Meeting


Daily stand-up meeting is one of the most critical meetings in agile methodology of software development. It is a quick review of each team member's last days work, planning for the next day's work and impediments the member is facing. ScrumMaster looks into the impediment and can resolve it upfront or in a sidebar meeting.

Monday, February 8, 2010

Role of the Product Owner in Scrum (Agile)


In Scrum, one of the flavors of agile methodology of software development, there are three fundamental roles: the Product Owner, The ScrumMaster and the team. In current post let us talk about the Product Owner's role in detail.

The Product Owner represents the customer's interest and prioritizes the backlog of tasks according to the business needs. She/ he participates in the Sprint Planning meeting and evaluates the entire product backlog, prioritizes them and include in or exclude from the next Sprint. She/ he has the final say whether the task should be reprioritized or dropped. The team working on the product development can negotiate with the Product Owner on the priority of the task, but the final discretion lies with the Product Owner only. The Product Owner also decides the acceptance criteria for the potentially shippable product after the Sprint is completed.

Defining Impediments in Scrum (Agile)


Impediments are the roadblocks or hindrances faced by the team in agile methodology of software development. To make the definition look more clear and practical, impediments are any causes which will delay team's deliverables or stop from progressing in a task and eventually costing the team's productivity.
 

Role of ScrumMaster in Scrum (Agile)

 
In Scrum, one of the flavors of agile methodology of software development, there are three fundamental roles: the Product Owner, The ScrumMaster and the team. In current post let us talk about ScrumMaster's role in detail.

ScrumMaster acts as a facilitator for the team and is co-ordinator between the Product Owner and the team. He also co-ordinates with the management and the company's support functions to remove any roadblocks or impediments faced by the te team. Typical "command and control" style of management does not produce results for the ScrumMasters. In fact, there is no place for such a manager in agile.

Sunday, January 31, 2010

Introduction to Agile Method of Software Development


Agile methodology enables product development incrementally and in a lightweight manner. The process adapts to the changing business scenarios and equips team to collaborate in every task. Agile can be interpreted differently by the different pool of practitioners. For team, it provides opportunity to be flexible, cross-functional and self-organized. For managers, it is a set of best engineering practices that allow rapid delivery of high quality software. For stakeholders, it is business approach that aligns development with customer needs and company goals.

Agile is implemented with flavours such as Scrum, Extreme Programming (XP) and Agile Unified Process (AUP).

Monday, January 25, 2010

Let’s Talk about Performance Engineering

 
As I say repeatedly, performance engineering is a complex process. Thousands of dollars spent in fixing poorly performing applications. The performance bottleneck and pitfalls of the software product can not be combated at one go, but incrementally.

Broadly and for the simplicity sake, performance engineering can be divided in following stages:

Performance Test Strategy

Here we define the scope, environment, methodology, metrics and reporting of the performance testing. The tool required to generate the load and analyze the application behaviour is also identified under this head.

Agile Performance Engineering

 
Performance engineering is complex process. Thousands of dollars spent in fixing poorly performing applications. The performance bottleneck and pitfalls of the software product can not be combated at one go, but incrementally.

With growing complications and need for time to market the software products, traditional models did not deliver the desired result to address performance issues of the product. Agile methodology emerged to address the rapidly changing business requirements and deliver shippable application incrementally. Flexibility and shortest possible time to take products to market are the main targets.

Thursday, January 21, 2010

Five Frogs Sitting on a Log


One of my favourite questions when I evaluate testers for my organization goes like this:

There are five frogs sitting on a log. Four of them decide to jump off the log. How many would be remaining on the log.

Wednesday, January 20, 2010

Agile Usability Testing


Usability is the ease with which a product can be used by people. For a software product: smooth navigation through User Interfaces (UI), ease of workflow and design of the product gives the best satisfaction to the target audience.

Usability testing is evaluating product from the users' perspective. The task is to identify the problems in the User Interface and workflow (of the product), which makes users' job difficult while working on the product. If a user faces difficulty while performing a task, it means the usability has some issues that need to be fixed. These issues occur because the developers and designers of the product have limited understanding of the end user's perspective. In product companies, there is a separate usability team that takes care of the ease of usage of the product for the desired end user.

How to Incorporate Manual Testing in Agile


Agile Methodology is applied when a product development requirements change frequently and, the shippable product needs to go to the market regularly and rapidly. Inherently, testing in Agile should be automated with the help of unit testing, regression test suit, performance test scripts and smoke tests with the continuous integration at check-in of the releasable code. It does not necessarily mean that a team with only manual testers won’t make the product development a big success. Let me share some thoughts on how manual testers can actually make the methodology a big success.

Tuesday, January 19, 2010

Testing an Elevator Made Easy

This is one of my favorite questions for the testing interviews. Those who give me most of the scenarios are most likely to get through. Well, after posting this in my blog I may change my question. But I felt very compelling to share this question with the community.

So, here is the question: Give me some scenarios that you will be testing for an elevator.

(I recommend you read this post till the end)

Monday, January 18, 2010

How to Approach Test Estimation

Test estimation is not an easy task. Various schools of thoughts suggest varied strategies of estimation. A number of techniques are available for task estimation. Before we talk about any of the estimation technique, which is out of the scope of current post, we should talk about the activities that need to be kept in mind while estimating testing effort.

Majorly, the activities can be categorized under Test Planning, Requirement Analysis, Test Case writing and/ or scripting, Test Case/ Script execution, Training, Defect Reporting and Tracking, Regression and Retesting and, Reporting. Then we should incorporate following possibilities in the real life scenarios: possibility or parallelization of tasks, dependencies and roadblocks and, risks. Let us dig further into each of them.


Sunday, January 17, 2010

Critical Bugs in a Web-based Banking Product

Banking products are highly secured. The money transaction, precise calculations, updation at the backend (i.e. database), clear instructions about the steps to be performed for a certain action, security, 24X7 availability of servers, performance and usability are highest priority when it comes to design and develop a banking product.

Saturday, January 16, 2010

Bug Reporting: Why Do Developers Reject a Bug

Testers often come across this frustration of bugs not getting accepted by the development team. It takes huge effort and rounds of negotiation before both of them come to a same page. What causes this debate? How can we minimize it? How can this overhead be avoided? Let us explore.

Thursday, January 14, 2010

Testing Interviews

Testing interviews are very tricky. It comprises of evaluating your communication skills, behavioral aspects, attitude, aptitude, customer focus, sensitiveness towards end user's perspective, capability to understand complex and varied nature of documents, capability to produce clear and concise reports, knowledge of processes and standards; apart from the other technical skills.

Technical skills really depend on the job requirement. In general, software companies expect you to be aware of Operating Systems, Databases, Web Servers, App Servers etc. I'm reiterating that the job requirement can vary from project to project, company to company. If you are in niche domains such as mobile testing, network protocol testing or mobile chipset testing you need the domain knowledge well. With certain products domain knowledge also helps a lot. For example, for a product in banking and financial domain, you need some understanding of the domain. It helps in understanding the workflow and the terminologies used in the product.

Testing Frequently Asked Questions

 
What is Traceability Matrix?

When you write test cases from a requirement document or use case document, you should remain sensitive towards the coverage of the requirement and converting them to testable items. The test cases are designed keeping in mind about the requirements coverage. If there are areas not covered in the test case, it will go untested. In order to verify whether all the requirements are being tested or not, Traceability Matrix is created. It maps requirements to the test cases.

http://testheed.blogspot.com/2010/02/traceability-matrix-how-to-map.html

What is TDD?

Test Driven Development methodology of software development is one of the most popular flavor of agile methodology. Other popular flavors of agile are Scrum, Extreme Programing (XP), Function Driven development (FDD) etc. The main principle behing TDD is to write unit test cases first and then code the unit of the module so that the unit passes the test. TDD saves a lot of time and money in finding the sofwtare defects at the later stage of software development. Farther the testing cycle falls, higher would be the cost to fix the issue.

http://testheed.blogspot.com/2010/02/how-to-work-in-tdd-methodology-of.html

- More to come. Please be patient.

Incorporate Requirement Changes without Loosing the Testing Focus

Case: In a project the client says that there will be frequent changes in the requirement for the next 3 months. The development in X build can be changed in X+1. So there is no point of testing the product for next 3 months, till the product is stable. So I would like to scrap the testing team till that point of time.

Now, how would you convince your client that the testing team should be retained?

Software Testing Resources

Here's the one stop platform for all the Software Testing Resources available in the for of books, white papers, tools, articles, websites, community and networking websites:

- More to come soon. Please be patient.

About TestHeed

TestHeed is a free to access weblog for software testing community. You will find regular write-ups on software testing, test methodologies, test processes, test methodologies, and testing trends in IT industry. In resources section you can find the references of the testing tools, books and forums available to ease out your knowledge capturing in testing. Blogs are thoughts shared by me on various professional and personal aspects.