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).

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.

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.

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.

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)

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.

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.

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.

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.