Kiran Gopisetty

How best to prevent SQL Injection

2012-10-03T04:39:00.002-07:00

There are several ways a hacker can target a database, and SQL Injection is becoming one of the common way. It is used on websites which have been designed very poorly and which did not anticipate the possibility of such risks during the design phase. It involves inserting SQL statements on one of the input boxes of a web form which executes certain commands on the backend.

SQL injection testing is a technique that can check if a site’s input fields/web form has vulnerabilities that could be used to obtain information.

SQL injection is done in many ways. Data could be extracted on the same channel which was used to inject the SQL code. In this case the extracted data will be presented on the application web page itself. Data could also be extracted by a different channel wherein an email with the results of the query is generated and sent to the tester. A tester could also make inferences regarding the server by sending particular requests to it and observing the resulting behavior.

Manual SQL Injection testing tends to be tedious and quite time consuming. It can only detect the simple vulnerabilities.
Other possibility is using an automated web application vulnerability scanner, such as HP's WebInspect, IBM's AppScan or Cenzic's Hailstorm. These tools all offer easy, automated ways to analyze your web applications for potential SQL Injection vulnerabilities.

Blackbox testing:
First you need to know when the application under consideration connects to a DB Server to access data. Typically, an application needs to talk to a DB in the following cases:
1.   Authentication forms: when authentication is done using a web form, most often the user credentials will be checked against a database that contains all usernames and passwords or password hashes
2.   Search engines: when a string is submitted by the user, it could be used in a SQL query that would then extract all relevant records from a database.
3.   E-Commerce sites: the products and their characteristics (price, description and availability) are very likely to be stored in a relational database.

As owasp.org states, the tester has to make a list of all input fields whose values could be used in making an SQL query and then test them separately. The very first test usually consists of adding a single quote (') or a semicolon (;) to the field which is being tested. The first is used in SQL as a string terminator and would lead to an incorrect query if it is left unfiltered by the application. The second is used to end a SQL statement and, if it is not filtered, it is too would generate an error. The output of a vulnerable field might look like the following (on a Microsoft SQL Server, in this case):

Microsoft OLE DB Provider for ODBC Drivers error '80040e14'
[Microsoft][ODBC SQL Server Driver][SQL Server]Unclosed quotation mark before the
character string ''.
/target/target.asp, line 113

Other SQL keywords such as 'AND' and 'OR' could be used to try to modify the query. A very simple but sometimes still effective technique is simply to insert a string where a number is expected, as an error like the following could be generated:

Microsoft OLE DB Provider for ODBC Drivers error '80040e07'
[Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the
varchar value 'test' to a column of data type int.
/target/target.asp, line 113

A full error message provides a wealth of information to the tester in order to mount a successful injection. However, applications often may not delve into detail: a simple '500 Server Error' or a custom error page might be issued, meaning that tester should now turn to blind injection techniques. In any case, it is very important to test each field separately: meaning only one variable must vary while all the others remain constant, in order to identify the vulnerable parameters.

7 Mistakes in Software Testing

2012-10-03T04:37:00.002-07:00

Trial and error method is the best way of testing, but repeatedly not fixing of errors would ruin the efforts taken in testing and is a mere waste of time. Software Testing engineers while testing make small mistakes unintentionally which seems to be insignificant but are of high importance.
The following are the mistakes we usually find in software testing:
The First Mistake: Unit Testing is a method by which smallest testable part of an application of source code are tested to determine if they are fit for use. By just calling all utility methods, it's easy to test a utility class, passing some values and examining if the expected result is returned. A first mistake arises here. Majority of the developers don't think out of the box, or not adequate. Developers can test that 1 + 1 =2, that 2 + 1 = 3 and that 3 + 1 = 4. But what is the use of doing nearly 3 times the same test? Testing boundary cases is better. Are the arguments of the sum ( ) method primitive types or Objects? If they are Objects, what happens if you pass null values? If an exception is thrown, is that the expected one? Does it clearly tell what the problem is?
The Second Mistake: Mocks - For example the service layer is unit tested, all other components like the DAO layer should be mocked. Manually in many cases it's been done. That's the second mistake. It's much better to use mocking frameworks because when one mocks stuff manually the mocks are tightly coupled to the implementation as they are made for it. Just believe that they will create the mocks the way they want. Some mocking frameworks are capable of doing more than others; some are easier to use than others. Some of the best mocking framework is Mockito and EasyMock. Mockito is preferred because of its power and simplicity and EasyMock is by far the best known but it's a bit complex too to use. So it's not only a matter of choosing a mocking framework. It's also a matter of choosing the right one.
The Third Mistake: Integration Tests are the tests over different integrated parts of an application while unit tests only tests a LUW (logical unit of work). In integration tests - the best known type of are tests of the DAO layer. In these tests, multiple things are validated: The input parameters, The use of the ORM tool The correctness of the generated query (functional) If the DB can be accessed The fact that the query is working and The fact that the correct ResultSet is returned. The third mistake that is made often is that in the dbUnit XML dataset developers provide test data. Most of the time this data has no representation of live data; the best way to handle this is to make functional-providing people and maintaining this test data. Because one doesn't want to make them struggle with a specific XML format, good practice is to use the XlsDataSet format (Excel Sheet).
The Fourth Mistake: Functional Tests are forgotten too often because the perception is that they are difficult and expensive to maintain. It's true that we'll have to tweak to make them maintainable but executing all the same tests manually over and over again will cost much more. Also when functionality is tested and automated by means of continuous integration, there's no need for stress for screens/ functionality that will be broken in the next release. Selenium is a great framework that is able to record functionality in the browser. The fourth mistake is made here. Most people will just record and replay the tests the way they are. Selenium--HTML components by their HTML id can be tracked. If developers don't specify id's in their HTML code, they can easily change if a page is updated. This will break the tests immediately even when functionality still works.
The Fifth Mistake: This mistake is made in a JUnit test by just pasting the recorded test. Login and logout are common functionalities, the time to wait for a response, should be added to a superior level. For example, a login can be done before each test, afterwards a logout is done. This way, if something changes in login or logout functionality, tests won't break.
The Sixth Mistake: Absence of testing logical flows sixth mistake happens. It's perfectly possible that an insert, a search, an update, and a delete work on their own but that the complete flow from the creation, search, and update until delete of the same entry won't work. The great way to group multiple tests and run them in sequence all together is by the TestSuites.
The Seventh Mistake: BDD (Behavior Driven Design) Instead of functional tests most of the tests are technical tests. To test logical behavior than to test if the things work technically is much more important. That can be done by means of Behavior Driven Design. Given some things, when an event occurs, then what should be the outcome? Mockito has some great stuff to easily write tests in a BDD way.

Thinking Tester

2012-10-03T04:35:00.003-07:00

White box and Black box is all we have heard about testing since its origin. There is no tester who is without the knowledge of these testing boxes. But trying things in different perspective to see whether they really work is an art of creative thinking were people come out with their new ideas apart from the default ones.
Some ideas given below, if implemented will make you think out of the box and optimize your testing modules to much greater extent.
1) Creating Test Cases Preparing a gist of ideas and scenarios you may come across while testing, penning it down and repeating the process till you make a good number of content. When the same is reviewed at the end and you will be surprised to see with new ideas you have come out with.
2) Cross testing ideas Use refreshed ideas while testing a new application. Treat it like an entirely new application before you test, you may come across new scenarios and by doing this you may find shortcuts for testing an application which you have not dealt with.
3) Backward Testing Ideas Requirements>> Unit Cases >> Integration Testing >> System Testing is the default way of testing. Instead for a change, try using the reversed order like System Testing>>Integration Testing>>Unit Cases >>Requirements.
Eg: Requirement says you can upload a file which does not exceed file size of 10 MB. The most testers will follow uploading a 1MB, 2MB, 3 MB and so on till 10 MB is reached or error message is displayed. Why not start with 10MB and then try 11MB and then 9 MB. This example is nothing but a BVA but how many of us have tried using BVA in scenarios other than an input box.
4) Questioning Questioning enhances the domain knowledge of the tester. Having an attitude of questioning will not allow the tester to stay negligent even with a small bug. Also the tester can get to know well about his purpose of testing.
5) Researching Making a detail study about the product you are going to test is necessary, therefore make as much as research possible by comparing and interpreting the results you get with the earlier results.
6) What about a cup of coffee How about a cup of coffee in between your testing process or a stroll in the office just before fixing a bug, sounds relaxing? One of the time consuming process is testing were testers need to stick on to the process till the bug is fixed. So at least, gaze out of your window to slow down, unwind and freshen up before getting your hands dirty in process of fixing the bug.
7) Talented Tester who are highly talented with a go get attitude will have innovative ideas of testing and they will not compensate their work at any cause and this will obviously yield them a good result.
8) Working with Multiple disciplines Manual, Functional, Performance testing skills and soft skills like Leadership skills, Communication skills, are some of the other areas a tester should work on. These extra talents will help testers to have a balanced growth both, professionally and personally.
9) Importance of Clients Testers should always work with client,s perspective. Make sure each and every demand of the client is met before delivering their product. This one deed will take a long way in your relationship with them.
10) Interest for finding new ways Testers must act desperate in finding new ways for testing. Working with passion will help you to find new ways of testing.

Difference between Functional and Non Functional Testing

2012-10-03T04:31:00.004-07:00

Let us have a look at the major difference between Functional and Non Functional Testing.

Functional Testing:

A type of black box testing, functional testing tests an application against the business requirements. Testers can either use automated tools or manual testing tools to verify the function of the code. Listed below are 5 Steps to remember in Functional testing:

1.   Based on the specifications of functions, it involves preparing test data.
2.   The inputs to functional testing are the business requirements.
3.   The output of the functions has to be verified against the functional specifications.
4.   Executing test cases.
5.   Verify the output against the expected output.

The below listed testing are the sub types of Functional Testing.

1.   Unit Testing: Unit testing is very useful to detect bugs and defects right at the beginning of the software development life cycle.
2.   Smoke Testing: Smoke Testing or Build Verification Testing consist of a set of non-exhaustive tests which ensures that the most vital functions work.
3.   Sanity testing: An unscripted type of test, sanity testing focuses on few functional areas of an application.
4.   Integration testing: Integration testing tests an application as a whole to detect if there are any defects in the interaction between the integrated units of the application.
5.   Usability Testing: An evaluation method, unit testing is used to ensure that the user is satisfied with the application.

The other sub-types of Functional testing are:

1.   Interface Testing
2.   System Testing
3.   Regression Testing
4.   User Acceptance Testing

Non-Functional Testing

Non-Functional Testing, tests an application against the non-functional requirements. These include the quality of the product. A tester can test the non-functionality of an application after he/she has tested the application against the functional requirements. Listed below are they sub-types of Non-Functional Testing:

1.   Compatibility Testing: This type of testing evaluates the compatibility of an application with a computing environment.
2.   Load Testing/Stress Testing: It is important for a tester to check if the application/website can withstand the load and stress when there are many people assessing it at the same time.
3.   Recovery Testing: Testers will need to check the capability of an application to recover after experiencing hardware failure or crashes.
4.   Security Testing: Security is important especially when it comes to applications that require a user to enter critical information such as account or credit card information. Testers have to ensure that such information is being transmitted safely.
5.   Volume Testing: The functions of volume testing are often misunderstood or used interchangeable. It refers to testing an application’s performance with a specific amount of data.

The other sub-types of Non-Functional testing are:

1.   Availability Testing
2.   Baseline Testing
3.   Compliance Testing
4.   Configuration Testing
5.   Documentation Testing
6.   Endurance Testing
7.   Ergonomics Testing
8.   Interoperability Testing
9.   Installation Testing
10.   Localization Testing and Internationalization Testing
11.   Maintainability Testing
12.   Operational Readiness Testing
13.   Performance Testing
14.   Reliability Testing
15.   Resilience Testing
16.   Scalability Testing
17.   Usability Testing

10 Reasons to Fix Software Bugs Right Away

2012-09-24T05:25:00.001-07:00

Unfixed bugs camouflage other bugs
Unfixed bugs suggest quality isn’t important
Discussing unfixed bugs is a waste of time
Unfixed bugs lead to duplicate effort
Unfixed bugs lead to unreliable metrics
Unfixed bugs distract the entire team
Unfixed bugs hinder short-notice releases
Unfixed bugs lead to inaccurate estimates
Fixing familiar code is easier than unfamiliar code
Fixing a bug today costs less than tomorrow

Android History

2012-09-24T04:33:00.003-07:00

Unit Testing Vs Integration Testing

2012-08-08T03:19:00.004-07:00

Normally software application is not developed by a single developer; rather it is divided into modules that are allocated to different development teams. When a single developed module or unit of the application is tested it is known as unit testing. Once all the modules are developed, they are integrated into one application. Testing of the entire application is known as integration testing.

Characteristics of Unit Testing

Repetition: Unit testing can be performed again and again as many times as you want.
Consistent: Unit test results are very reliable as you can reproduce the results
Quick: Unit tests usually take less than1/2 a second.
Single Issue: Unit tests concentrate on just one issue at a time.
No external implementation dependencies: Database, network, file system, etc that are not in the memory are not required.

Characteristics of Integration Testing

Slow, Difficult and Not Reproducible: Unlike unit tests, integration tests are time consuming. Re-running the test is not only difficult but it may also not give consistent results. Sometimes getting the test results is also not easy.
External Source Requirements: Integration tests need access to external systems as well as local machine.
Multiple Issues: Integration tests target multiple aspects in the same test. Database integrity, protocols, configurations and system logic are some examples of issues checked by a single integration test.
System Dependent values: Unlike unit tests, integration tests take up values like date, time, machine name, etc from the system.
Uncontrollable elements: Integration tests develop features like threads and random number generators that are not under their control.

Some Major Differences

Both Unit testing and Integration testing are used to check the internal quality of the application, whereas acceptance testing verifies the external quality or business quality. Unit testing checks a single component of an application, whereas integration testing checks if different units can work together as a single application. Therefore while writing a unit test shorter codes are used that target just a single class. On the other hand writing integration tests is a lengthy process. Unit tests help the developer to put individual tasks of an application into different classes. Each class executes just one aspect of functionality which helps in developing the design. Integration tests are not useful for design.

Since unit tests cover only a small part of functionality, their test results confirm the exact part of the application that needs to be fixed. Unit tests only target the proper functioning of individual units and are not helpful to verify the smooth functioning of the entire application. Therefore integration tests are required to check the entire application. When an application does not pass the integration test, the unit test results for that specific part of functionality will help in fixing the issue. Thus both unit testing and integration testing are required; as unit tests target the implementation of individual components and integration tests target the working of an application as a whole.

Testing In Production

2012-08-06T04:33:00.003-07:00

Mobile Testing

2012-08-06T04:32:00.002-07:00

Security Testing - Penetration Checklist

2012-07-31T00:42:00.004-07:00

1) Check if web application is able to identify spam attacks on contact forms used in the website.

2) Proxy server – Check if network traffic is monitored by proxy appliances. Proxy server make it difficult for hackers to get internal details of the network thus protecting the system from external attacks.

3) Spam email filters – Verify if incoming and outgoing email traffic is filtered and unsolicited emails are blocked. Many email clients come with in-build spam filters which needs to be configured as per your needs. These configuration rules can be applied on email headers, subject or body.

4) Firewall – Make sure entire network or computers are protected with Firewall. Firewall can be a software or hardware to block unauthorized access to system. Firewall can prevent sending data outside the network without your permission.

5) Try to exploit all servers, desktop systems, printers and network devices.

6) Verify that all usernames and passwords are encrypted and transferred over secured connection like https.

7) Verify information stored in website cookies. It should not be in readable format.

8 ) Verify previously found vulnerabilities to check if the fix is working.

9) Verify if there is no open port in network.

11) Verify all telephone devices.

12) Verify WIFI network security.

13) Verify all HTTP methods. PUT and Delete methods should not be enabled on web server .

14) Password should be at least 8 character long containing at least one number and one special character.

15) Username should not be like “admin” or “administrator”.

16) Application login page should be locked upon few unsuccessful login attempts.

17) Error messages should be generic and should not mention specific error details like “Invalid username” or “Invalid password”.

19) Verify if special characters, html tags and scripts are handled properly as an input value.

20) Internal system details should not be revealed in any of the error or alert messages.

21) Custom error messages should be displayed to end user in case of web page crash.

22) Verify use of registry entries. Sensitive information should not be kept in registry.

23) All files must be scanned before uploading to server.

24) Sensitive data should not be passed in urls while communicating with different internal modules of the web application.

25) There should not be any hard coded username or password in the system.

26) Verify all input fields with long input string with and without spaces.

27) Verify if reset password functionality is secure.

28) Verify application for SQL Injection.

29) Verify application for Cross Site Scripting.

31) Important input validations should be done at server side instead of JavaScript checks at client side.

32) Critical resources in the system should be available to authorized persons and services only.

33) All access logs should be maintained with proper access permissions.

34) Verify user session ends upon log off.

35) Verify that directory browsing is disabled on server.

36) Verify that all applications and database versions are up to date.

37) Verify url manipulation to check if web application is not showing any unwanted information.

38) Verify memory leak and buffer overflow.

39) Verify if incoming network traffic is scanned to find Trojan attacks.

40) Verify if system is safe from Brute Force Attacks – a trial and error method to find sensitive information like passwords.

10 Reasons to Fix Bugs

2012-07-31T00:42:00.000-07:00

Testing and Checking

2012-07-30T03:19:00.001-07:00

Testing and Checking

Checking

Doesn’t mean the product works
Help us know that the product works within expectations
Can ‘pass’ but still have serious problems
Automated tests are checks
Need specifications
Helps answer – does the system do what it is supposed to do?
Great programmers do alot of checking

Confirmation
Verification
Validation
Making sure the program doesn’t fail
Verifying beliefs we expect to be true

Checks
Are machine decidable:

Yes
No
True
False
Pass
Fail

Testing

Exploration
Learning
Finding new information
Discovery
Investigation
Evaluating
Finding problems
Searching for extents and limitations
Driven by questions
Finding problems not covered in checks

Tests

Have open ended results
Asks if there is a problem here?
Can be about finding out if checks have been good enough
Problems found from testing can be used to create checks to stop them appearing in the future
Do not require specifications
Involves some checking

The Debate

Why do we need to define the difference?
Does more terminology just cause more confusion?
What problem is this distinction solving?
Should it not be ‘versus’ it should be Testing AND Checking

Session Based Test Management

2012-07-26T02:32:00.001-07:00

Accessibility Testing

2012-07-26T02:31:00.003-07:00

Getting Started with Mobile Testing

2012-07-26T02:30:00.004-07:00

Mobile Testing

2012-07-26T02:26:00.001-07:00

Agile Testing

2012-07-26T02:25:00.000-07:00

The Future Of Software Testing

2012-07-16T02:36:00.003-07:00

Test Plan Mindmap

2012-07-13T01:41:00.005-07:00

Testing Terminology Redefined | Just For Reading

2012-07-13T01:40:00.003-07:00

Aggression Testing: If this doesn’t work, I’m gonna kill somebody.

Compression Testing: []

Confession Testing: Okay, Okay, I did program that bug.

Congressional Testing: Are you now, or have you ever been a bug?

Depression Testing: If this doesn’t work, I’m gonna kill myself.

Egression Testing: Uh-oh, a bug… I’m outta here.

Digression Testing: Well, it works, but can I tell you about my truck…

Expression Testing: #@%^&*!!!, a bug.

Obsession Testing: I’ll find this bug if it’s the last thing I do.

Oppression Testing: Test this now!

Poission Testing: Alors! Regardez le poission!

Repression Testing: It’s not a bug, it’s a feature.

Secession Testing: The bug is dead! Long lives the bug!

Suggestion Testing: Well, it works but wouldn’t it be better if…

Agile Iteration Planning

2012-06-18T22:34:00.001-07:00

Agile iteration:

Agile iteration is a consistent time-box in which a delivery team plans, delivers and receives feedback on a product increment.

Iterative Development adds agility to the development process. Divide your development schedule into about a dozen iterations of 1 to 3 weeks in length. One week is the best choice even though it seems very short. Keep the iteration length constant throughout the project. This is the heart beat of your project.

Take your iteration deadlines seriously! Track your progress during an iteration. If it looks like you will not finish all of your tasks then call another iteration planning meeting, re-estimate, and remove some of the tasks.

Key characteristics of an iteration:

Have one goal
Focus on completing the tasks derived from user stories
Accept the activities based on the capacity of the team

Iteration Plan:

At the start of each iteration - or sprint to use the Scrum term - the team set out what they will do in the next iteration. Since iterations typically last weeks - with two weeks being most common - these plans only peek a little into the future. They are however the most detailed plans, setting out exactly

what the team will do.

The scheduling of work into an iteration plan is a discussion between the team members who will undertake the work and those who are charged with managing the requirements side of the project. Whoever this is, be they Product Owner, Customer, Product Manager, Business Analyst or Project

Manager, proposes some work. Then using a velocity measure or a goal commitment protocol the team agree how much the team can accomplish.

Once agreed the iteration plan is done and the team move to execution. While the Product Owner nominates work to the plan it is agreed with the team through negotiation. Having the whole team involved in the planning removes the need to communicate the plan to the team, explain details and

enthuse the team about someone else's plan.

Once agreed the iteration plan is owned by the team and it is their collective responsibility to carry it out. Since the plan only looks at the next few weeks it is unlikely to change much. Indeed, when it does change drastically it is usually a sign of problems. When this happens regularly it is a sign that action needs to be taken.

Iteration planning steps/life cycle:

Select Iteration goal
Determine delivery team capacity
Select the highest priority backlog item
Estimate tasks
Repeat until no more can be committed

Product Owner Responsibilities

Review the release plan to make sure the vision and goals are still appropriate.
Review the items in the backlog and reprioritize if necessary
Understand how the reprioritization may affect other teams who are dependent on a deliverable committed to during release
planning. Coordinate with other product managers as needed to resolve dependency issues.
Understand the customer needs and the business value that each story is to deliver.
Be prepared to further elaborate on the details of each story.

Development Team Responsibilities

Review the top priority items in the backlog and prepare any questions
Consider technical issues, constraints, and dependencies, and be prepared to share these concerns.
Think about the work involved in delivering the functionality in the stories, in order to be prepared to make estimates in the meeting.
Understand what your iteration velocity should be for the upcoming iteration, based on team discussions at the last review.

Release Plan:

The release plan is then used to create iteration plans for each individual iteration.

It is important for technical people to make the technical decisions and business people to make the business decisions. Release planning has a set of rules that allows everyone involved with the project to make their own decisions. The rules define a method to negotiate a schedule everyone can commit to.

The essence of the release planning meeting is for the development team to estimate each user story in terms of ideal programming weeks. An ideal week is how long you imagine it would take to implement that story if you had absolutely nothing else to do. No dependencies, no extra work, but do include tests. The customer then decides what story is the most important or has the highest priority to be completed.

User stories are printed or written on cards. Together developers and customers move the cards around on a large table to create a set of stories to be implemented as the first (or next) release. A useable, testable system that makes good business sense delivered early is desired.

The base philosophy of release planning is that a project may be quantified by four variables; scope, resources, time, and quality. Scope is how much is to be done. Resources are how many people are available. Time is when the project or release will be done. And quality is how good the software will be and how well tested it will be.

Tips for successful iteration planning:

Prior to planning, review the prioritized list of stories, estimate at the gross level and select stories for the iteration.
Time-box your iteration planning session.
Determine delivery team capacity.
Agree upon statement of what the iteration is intended to accomplish.
Break stories into tasks, estimate efforts at the hours level for tasks and sign-up owners.
Get commitment from team.
Track the plan in a visible place or a tool.
Review and update the definition of the DONE.

Iteration Execution

Having committed to the iteration plan, the team starts development. Each developer (or pair of developers in organizations doing pair programming) will follow the same basic process repeatedly

throughout the iteration until there is no more work in the backlog:

1. Take responsibility for an assigned backlog item (e.g., story, use case, defect fix, other).

2. Develop (design, code, integrate, and test) the backlog item.

3. Deliver the backlog item by integrating it into a system build.

4. Declare the backlog item as developed, signaling that it is ready for acceptance testing.

This cycle repeats within an iteration as each developer ultimately takes responsibility for all the backlog items in his or her queue. In most organizations, developers also support the management of the process by estimating actual and remaining effort for the backlog items that they are responsible for.

Mobile Testing World

2012-05-29T22:38:00.001-07:00

Agile Methodology Vs Housekeeping Methodology

2012-05-29T02:17:00.002-07:00

Testing Slang

2012-03-09T02:50:00.002-08:00

Heavy lifting: Difficult and challenging work

SoLoMo: Social, location and mobile – testing components of many mobile apps

Burndown: a chart that is a graphical representation of work left to do versus time

PEBKAC: Problem exists between keyboard and chair

Fast-track: To speed up a process

Brown-bagger: A very embarrassing bug found soon after release

Whack-a-mole: The practice of repeatedly getting rid of a bug, only to have it continually reappear

Drink the Kool-Aid: Lacking objectivity

Low hanging fruit: Easy tasks that can be completed in short order

Staging: A development environment; one level before production

Automagically: Describes something that occurs in software that is either too complicated to explain, or the person describing the process really has no clue how it works

Quick and Dirty: A quick and simple solution to an otherwise complicated problem

Dogfooding: When a company tests its own software internally before releasing to beta

Showstopper: A bug that makes software unusable

The Perception | Developer Vs Tester

2012-03-01T06:33:00.003-08:00