Daca este cineva interesat, aveti job description-ul atasat. In mare nu este nevoie decat de ceva experienta in testare si de lucru cu QTP.

Aveti aici datele de contact pentru a va trimite cv-urile:

Catalina Rascu
HR Consultant
International Recruitment and Development

MGI METRO Group Information Technology Romania
Soseaua Pipera - Tunari nr. 4C, et. 3
RO - 077190 Voluntari / Ilfov

Phone: (004) 031 413-8383
Fax:       (004) 031 413-8218
Mobile:  (004) 0741.888.852
E-mail: catalina.rascu@mgi.ro

The web desktop application is totally different from traditional web pages. Traditional web pages use plain HTML which only supports limited graphic control and takes several pages to finish one complicated task. The page-to-page loading time does really lower down efficiency. Even though using Ajax could improve the efficiency a little, it might not satisfy the increasing demands of customers for high efficiency.

Tomato Cart’s application mimics the user experience of desktop Operating System, offering features and applications similar to a PC environment. As such, it is fairly easy for both beginners and professionals to get acquainted with it, and even master it. Additionally, it supports multi-window operations and that enables users to work with several modules simultaneously.

http://demo.tomatocart.com/
http://demo.tomatocart.com/admin

StarCraft® II: Wings of Liberty™ Beta Test Invitation

Congratulations! You’ve been selected to participate in the beta test of StarCraft® II: Wings of Liberty™.

Both the PC and Mac versions of the beta client are now available. Simply select your preferred version when you go through the installation process outlined below

• Verifying a certain value is set or it exists or not or in simple terms you need to ‘get’ certain properties of the object and compare it against your benchmarks
• Performing actions on an object or ’set’ certain values.

These two issues could easily be handled by Selenium for most of the website objects except for Flash.

In this article we will describe how to automate testing of Flash based components of web applications. The basic steps involved in any automation are:

• Observe and analyse
• Draw a common pattern
• Use this pattern for automation.

These three steps are very important while understanding the automation of Flash based components for web applications . Most of the time Flash is used in the web applications for -

• To play static content in the form of movie. The reason I am saying static content is that the contents of the movie stay the same.
• To render the dynamic contents using Flash such as rendering the contents for a strip of images or a strip of clips using Flash or displaying the title of any page using Flash. The reason I am mentioning these as dynamic content , is that Flash is just picking up this data from some system and displaying it in the Flash format. The contents may vary depending on the context of the page. For example, Flash can be used to display the a strip of pictures uploaded for a particular program for a media website. In this case the behaviour of the Flash is the same for all the programmes, only the content it is displaying is changing.

Both these cases could be automated in a different manner depending upon the information available in the DOM (Document Object Model). We are going to take second case first and explain how we used the DOM information for our automation and addressed one of the two issues (i.e. verifying a certain values). We used the 3 steps mentioned earlier for automating the Flash based component of a media website. If you have a website where dynamic Flash information is read in ‘flashvars‘ then you could also follow the same steps.

So how do you know whether the Flash components of your website are using the ‘flashvars’ information or not? Well its not that difficult to find it out. All you need to do is:

• Install firebug plugin for Firefox, if you do not have it already.
• Search for the ‘flash’ in the firebug you will get some div tag informing about the flash content and containing an object tag for the flashplayer.
• In this object tag search for ‘param’ mostly it is called ‘flashvars’ and the value contains all the information that flash will display.

Alternatively you could search directly for ‘flashvars’ As displayed below

• Looking at this you could easily get its xpath ( just browse you mouse over the element displayed on top of firebug near edit) or use another Firefox plugin, XPath checker.
• After having the xpath you could get the value of this ‘param’ or ‘flashvars’ in a string using getattribute() function of Selenium.
• This string would appear a bit strange on first look but on analyzing this string you would find a common pattern and it would be easy for you to then parse this string to get the required values.

This technique is very useful in at least verifying certain values. you could always search for ‘flash’ in the firebug and see if there is any information in its parameters or other tags that could be exploited for automation. Let us apply this technique on www.youtube.com because we know all the videos on you tube are displayed through Flash. A very interesting case of applying this technique could be testing whether the id of the video played on youtube is the same as the one displayed for embedding or not. Here is the screen grab of a random video on youtube.

As you can see we have followed the same steps mentioned in this article and searched for ‘flashvars’ we found that flashvars contains some words as ‘video_id’ in the string and then after the ‘=’ sign it contains the value of the id. Yes we got it we could parse this string for value of ‘video_id’ and compare it with the value specified in the url !!!

In the technique presented above, there is nothing which is only applicable for only Flash objects. You can follow the three steps mentioned above for any kind of automation and might come up with similar technique for something else as well based on your context. In the next article we will discuss a Flash specific technique for the Selenium using flash-selenium.jar to automate more advanced interactions with Flash using Selenium.

One thing you might want to keep in mind is, there could be only one category for the project. So you can not have categories in the lines of Team A / Live project or Team A / New project. But you can always give categories descriptive names like Team A – Maintenance project, Team A – Live project though.

After defining appropriate project categories, you can start exploring / creating various roles using role browser. For smaller teams this might not be very useful, but for larger teams roles can be used very effectively for triaging defects, creating notification schemes and so on.

Third important configuration setting for Jira could be Events. Events are very powerful and acts like triggers. With events, you can specify interesting things like how Jira screens will look like when specific event is triggered, what workflow operations will be available after specific event and who will get notification for this event. For example, if you want to change notification scheme (For example – Do not send emails for comments) or workflows (For example – It should not be possible to close defects directly, even if it is invalid defect it should be resolved, marked as invalid and some one else should close it) etc can be configured here. In order to make changes here, you need to create / modify notification / workflow schemes and associate them with the events.

That brings us to the Workflows, but what is workflow? Workflow is very important feature and lets you configure what happens in every step, how defects / issues are transitioned from one state to another and what options should be available in every transition. All these transitions work as trigger and you can specify conditions, validators or post transition functions for every transition.

Most of the operations in Jira are configured as schemes. Jira lets you create various schemes for workflows, notification & permissions. You need to create separate schemes, because you might have need for different scheme for different projects. For example, if you have resources from vendor working on a project, you might need separate permission scheme for them.  Schemes are even used to control look-n-feel of Jira, to decide which fields will be visible on every transition and so on. These can be achieved using Screen schemes.

One of the most interesting feature of Jira is configuring dashboard. On Jira, you can have multiple dashboards and on every dashboard you can publish reports, which are useful for you, may be status of defects, defects for components / projects and so on. This will allow you to get up-to-date information on the Jira front page. In order to configure your dashboard, you need to build your query using the Find Issue option and built chart from the result set. These charts can be published on the home page / dashboard and now whenever you visit Jira dashboard, these charts will be updated with latest information.

So in nutshell, you start with categorizing your projects and defining appropriate roles and users. You than configure various issue types (Defects, stories, sub-tasks) and fields (Priority, Severity, blocking issues, releases and so on) and define events and what should happen when those events are triggered. You also create various schemes for notifications, workflows, screens etc and apply them to projects as needed. After project is configured properly, you configure dashboard to display up-to-date information based on the various queries.

Have you used Jira in any other interesting way? Please leave a comment and let us know.

2. W3C Page Validator 3.0.0
This little add-on validates a page using the W3C Markup Validation Service. Depending on your context, if your organization is committed to create W3C compliant web applications, this might be very handy.

3. SQL Injection 1.2
This is an excellent tool to help developers in identifying SQL injection vulnerabilities. This add-on transform checkboxes, radio buttons and select elements to an input text box.

4.QuickRestart 1.1.5
If you need to restart firefox to test your cookies, sessions or because of any other reason, this little button in your toolbar will do it with a mouse click. This is a very simple utility, but can be extremely useful.

5. Firebug
If you are working in web application domain, I am sure you are already familiar with this add-on. Firebug, along with the development toolbar are absolute minimum your firefox should have if you are working in web application testing domain.

6. Regular Expression Tester
This small add-on allows you to test your regular expression. The tool includes options like case sensitive, global and multiline search, color highlighting of found expressions and of special characters, a replacement function incl. backreferences, auto-closing of brackets, testing while writing and saving and managing of expressions.

7. HttpFox
This add-on is an amazing tool if you want to dig deeper into http request / response and analyze all the traffic. Using this add-on, you can get information about request / response header, sent and received cookies, Querystring parameters, POST parameters and Response body.

8. HackBar 1.3.2
I haven’t explored this myself, but from description it looks like it should be useful for SQL injections, XSS holes and site security.

9. Web Developer Toolbar
As mentioned earlier, this one along with the firebug are must have extensions if you are working in web application domain. These extensions are complete toolset and probably require separate articles to explain their capabilities.

10. Accessibar 0.7.8
Its an amazing add-on to test accessibility of any site. Using this add-on, you can change font size, line spacing, hide all the images / flash and so on. It also integrates text to speech reader and reads string on mouse hover / focus elements.

11. Add N Edit Cookies
There are very few applications which does not use cookies these days. This little add-on allows you to add / edit cookies and test how your application will respond to changes in the cookies setting.

12. LinkChecker 0.6.3
This is a very simple tool to check if there are any broken links on the web page. It highlights all the links in various colors to show if they are broken or not.

13. MeasureIt 0.3.8
If you have a design team which is very particular about the size of every element, than this little add-on can be used to test hight and width of all the elements. It draws a ruler around any element and shows hight / width of the element.

14. YSlow 2.0.0b3
YSlow analyzes web pages and gives you information on why they are slow based on the Yahoo’s rule for high performance websites.

15. User Agent Switcher
If your application behaves differently based on the user agent or if it records this information than this add-on can be very handy. It simply switch the user agent of the browser. Please note, changing user agent will not make it render like IE.

16. FireShot 0.69
FireShot can be handy in situations where you want to take screen shot of your web application. It even allows you to write comments, highlight specific element of your application and so on.

17. URLParams 2.2.0
This little add-on make it convenient to analyze GET and POST parameters of the current website in the sidebar. You can ever change their values, add new parameters etc.

18. Tamper Data 10.1.0
Tamper Data allows you to view and modify HTTP/HTTPS headers and post parameters. You can use it to test security of your web applications by modifying POST data and analyzing how your application will respond to those changes.

19. View Dependencies 0.3.3.0
This is an extremely useful add-on if you want to figure out what are all the files / images etc. are getting downloaded for every page, how much time they are taking and many such details.

20. Flash Switcher 2.0.2
If you are involved in testing Flash Applications, than this little add-on is extremely useful to test your flash application on various versions of flash players.

I have purposefully not included add-ons like Selenium and TestGen4Web , because they are separate test automation tools in themselves. Hope you found this list useful. Please add other interesting add-ons  you have used in the comment, which are not listed above.

A QA lead, on a project, has to see the big picture; needs to understand the goals of both the project and of the business. It’s easy enough to hire several QA people to come in and test the application before releasing it. They will go through test cases, and find some bugs. However, if the analyst just goes through assigned test cases without ever questioning why the test case was written in the first place, why certain business logic acts certain ways; the analyst will never be truly effective.

Majority of critical bugs that I’ve found over the years, have been found far off the beaten path. And the only reason I ventured into the wilderness of the application was because I knew the application and the business by heart. Furthermore, small accidental changes in the business flow of the app were sometimes missed by the developers, customers, and QAs, but were brought up to attention due to the understanding of the business rules. It is critical for the QA lead to know all the rules of the game because he becomes the point of reference for the rest of the team.

With responsibility comes power, and with power comes even more responsibility. A marking of a good QA is the dedication to the quality of the product; this is especially true for the lead. She has to answer to the quality of the product first, customers and bosses next. This position is tough to defend at first, especially when there is so much pressure just to “ship it.” But you have to be especially firm here, if the application is not fully tested, you have to push back the release. If the deadlines cannot be moved, you have to negotiate the scope down to a manageable size. It is unethical to release code that has not been tested!

But the customer is always right, and shouldn’t the customer be always first? Yes, that is true, but in QA universe putting the quality of the product above everything else is putting the customer first. In this hierarchy, the customer always wins, never having to deal with frustration of buggy software and data corruption. This in turn generates more revenue for the company, and makes your managers happy. A strong QA lead should have enough freedom and courage to pushback when things get out of hand, and raise issues when things are unreasonable; just like the project managers do when they see a problem.

Creativity plays a major role in the QA lead’s daily life. Anyone can be hired to follow rules and procedures without giving anything a second thought. But it’s the lead’s job to give direction to people around, on how to approach different tasks and problems. An individual who is not capable of thinking on his feet, and quickly adjusting to the new situation will not lead a successful team. This is mostly due to the fact that procedures and plans are good on paper, but nothing ever goes according to plan. In true spirit of agile development, the lead needs to be steady but easily adjustable depending on the situation.

There should never be walls between leads and analysts. Just because you have a higher title on the project, does not mean you are no longer required to be a QA. A lead is not a manager who gives directions and directives, but someone who has more experience, and in turn shares the experience with the team, leading by example. One should never act as if some assignments are below his status, but has to be equal to everyone.

The skills I’ve mentioned above are not only unique to the QA lead role. I firmly believe that everyone on the team should posses these skills. It is not as necessary for the analyst to have all these abilities from day one, but they are critical for someone in the leading role. However, the final skill that a lead needs to have, is the ability propagate these values to everyone on the team. The lead needs to treat all the members of the team as future leaders, teaching them all the skills they will need for their own teams.

In conclusion, I was asked to show some differences between QA leads, and regular QA analyst. But to be honest I don’t think there should be many. Just because the lead has the most responsibility for the project, does not mean that everyone should not feel responsible for it. And just because the lead is expected to be a teacher and a leader to his team, does not mean that other teammates cannot teach.

As we covered in various articles in the Testing series there are various levels of testing:

Unit Testing, Integration Testing, System Testing

Each level of testing builds on the previous level.

“Unit testing” focuses on testing a unit of the code.
“Integration testing” is the next level of testing. This ‘level of testing’ focuses on testing the integration of “units of code” or components.

How does Integration Testing fit into the Software Development Life Cycle?

Even if a software component is successfully unit tested, in an enterprise n-tier distributed application it is of little or no value if the component cannot be successfully integrated with the rest of the application.

Once unit tested components are delivered we then integrate them together.
These “integrated” components are tested to weed out errors and bugs caused due to the integration. This is a very important step in the Software Development Life Cycle.

It is possible that different programmers developed different components.

A lot of bugs emerge during the integration step.

In most cases a dedicated testing team focuses on Integration Testing.

Prerequisites for Integration Testing:

Before we begin Integration Testing it is important that all the components have been successfully unit tested.

Integration Testing Steps:

Integration Testing typically involves the following Steps:
Step 1: Create a Test Plan
Step 2: Create Test Cases and Test Data
Step 3: If applicable create scripts to run test cases
Step 4: Once the components have been integrated execute the test cases
Step 5: Fix the bugs if any and re test the code
Step 6: Repeat the test cycle until the components have been successfully integrated

What is an ‘Integration Test Plan’?

As you may have read in the other articles in the series, this document typically describes one or more of the following:
- How the tests will be carried out
- The list of things to be Tested
- Roles and Responsibilities
- Prerequisites to begin Testing
- Test Environment
- Assumptions
- What to do after a test is successfully carried out
- What to do if test fails
- Glossary

How to write an Integration Test Case?

Simply put, a Test Case describes exactly how the test should be carried out.
The Integration test cases specifically focus on the flow of data/information/control from one component to the other.

So the Integration Test cases should typically focus on scenarios where one component is being called from another. Also the overall application functionality should be tested to make sure the app works when the different components are brought together.

The various Integration Test Cases clubbed together form an Integration Test Suite
Each suite may have a particular focus. In other words different Test Suites may be created to focus on different areas of the application.

As mentioned before a dedicated Testing Team may be created to execute the Integration test cases. Therefore the Integration Test Cases should be as detailed as possible.

Sample Test Case Table:

Additionally the following information may also be captured:
a) Test Suite Name
b) Tested By
c) Date
d) Test Iteration (One or more iterations of Integration testing may be performed)

Working towards Effective Integration Testing:

There are various factors that affect Software Integration and hence Integration Testing:

1) Software Configuration Management: Since Integration Testing focuses on Integration of components and components can be built by different developers and even different development teams, it is important the right version of components are tested. This may sound very basic, but the biggest problem faced in n-tier development is integrating the right version of components. Integration testing may run through several iterations and to fix bugs components may undergo changes. Hence it is important that a good Software Configuration Management (SCM) policy is in place. We should be able to track the components and their versions. So each time we integrate the application components we know exactly what versions go into the build process.

2) Automate Build Process where Necessary: A Lot of errors occur because the wrong version of components were sent for the build or there are missing components. If possible write a script to integrate and deploy the components this helps reduce manual errors.

3) Document: Document the Integration process/build process to help eliminate the errors of omission or oversight. It is possible that the person responsible for integrating the components forgets to run a required script and the Integration Testing will not yield correct results.

4) Defect Tracking: Integration Testing will lose its edge if the defects are not tracked correctly. Each defect should be documented and tracked. Information should be captured as to how the defect was fixed. This is valuable information. It can help in future integration and deployment processes.

Summary:

Integration testing is the most crucial steps in Software Development Life Cycle. Different components are integrated together and tested. This can be a daunting task in enterprise applications where diverse teams build different modules and components. In this article you learned the steps needed to perform Integration Testing.

The definition of the ISO 8204 for quality:

“Totality of characteristics of an entity that bears on its ability to satisfy stated and implied needs.”

This means that the Software product delivered should be as per the requirements defined. We now examine a few more terms used in association with Software Quality.

Quality Planning:
In the Planning Process we determine the standards that are relevant for the Software Product, the Organization and the means to achieve them.

Quality Assurance:
Once the standards are defined and we start building the product. It is very important to have processes that evaluate the project performance and aim to assure that the Quality standards are being followed and the final product will be in compliance.

Quality Control:
Once the software components are built the results are monitored to determine if they comply with the standards. The data collected helps in measuring the performance trends and as needed help in identifying defective pieces of code.

What is Software Quality Management?

Software Quality Management simply stated comprises of processes that ensure that the Software Project would reach its goals. In other words the Software Project would meet the clients expectations.

The key processes of Software Quality Management fall into the following three categories:

1) Quality Planning
2) Quality Assurance
3) Quality Control

What does it take to Manage Software Quality?

The Software Quality Management comprises of Quality Planning, Quality Assurance and Quality Control Processes. We shall now take a closer look at each of them.

1) Quality Planning

Quality Planning is the most important step in Software Quality Management. Proper planning ensures that the remaining Quality processes make sense and achieve the desired results. The starting point for the Planning process is the standards followed by the Organization. This is expressed in the Quality Policy and Documentation defining the Organization-wide standards. Sometimes additional industry standards relevant to the Software Project may be referred to as needed. Using these as inputs the Standards for the specific project are decided. The Scope of the effort is also clearly defined. The inputs for the Planning are as summarized as follows:

a. Company’s Quality Policy
b. Organization Standards
c. Relevant Industry Standards
d. Regulations
e. Scope of Work
f. Project Requirements

Using these as Inputs the Quality Planning process creates a plan to ensure that standards agreed upon are met. Hence the outputs of the Quality Planning process are:

a. Standards defined for the Project
b. Quality Plan

To create these outputs namely the Quality Plan various tools and techniques are used. These tools and techniques are huge topics and Quality Experts dedicate years of research on these topics. We would briefly introduce these tools and techniques in this article.

a. Benchmarking: The proposed product standards can be decided using the existing performance benchmarks of similar products that already exist in the market.

b. Design of Experiments: Using statistics we determine what factors influence the Quality or features of the end product

c. Cost of Quality: This includes all the costs needed to achieve the required Quality levels. It includes prevention costs, appraisal costs and failure costs.

d. Other tools: There are various other tools used in the Planning process such as Cause and Effect Diagrams, System Flow Charts, Cost Benefit Analysis, etc.

All these help us to create a Quality Management Plan for the project.

2) Quality Assurance

The Input to the Quality Assurance Processes is the Quality Plan created during Planning.
Quality Audits and various other techniques are used to evaluate the performance of the project. This helps us to ensure that the Project is following the Quality Management Plan.

The tools and techniques used in the Planning Process such as Design of Experiments, Cause and Effect Diagrams may also be used here, as required.

3) Quality Control

Following are the inputs to the Quality Control Process:

- Quality Management Plan.
- Quality Standards defined for the Project
- Actual Observations and Measurements of the Work done or in Progress

The Quality Control Processes use various tools to study the Work done. If the Work done is found unsatisfactory it may be sent back to the development team for fixes. Changes to the Development process may be done if necessary.

If the work done meets the standards defined then the work done is accepted and released to the clients.

Importance of Documentation:

In all the Quality Management Processes special emphasis is put on documentation. Many software shops fail to document the project at various levels. Consider a scenario where the Requirements of the Software Project are not sufficiently documented. In this case it is quiet possible that the client has a set of expectations and the tester may not know about them. Hence the testing team would not be able test the software developed for these expectations or requirements. This may lead to poor “Software Quality” as the product does not meet the expectations.

Similarly consider a scenario where the development team does not document the installation instructions. If a different person or a team is responsible for future installations they may end up making mistakes during installation, thereby failing to deliver as promised.

Once again consider a scenario where a tester fails to document the test results after executing the test cases. This may lead to confusion later. If there were an error, we would not be sure at what stage the error was introduced in the software at a component level or when integrating it with another component or due to environment on a particular server etc. Hence documentation is the key for future analysis and all Quality Management efforts.

Steps:
In a typical Software Development Life Cycle the following steps are necessary for Quality Management:

1) Document the Requirements
2) Define and Document Quality Standards
3) Define and Document the Scope of Work
4) Document the Software Created and dependencies
5) Define and Document the Quality Management Plan
6) Define and Document the Test Strategy
7) Create and Document the Test Cases
Execute Test Cases and (log) Document the Results
9) Fix Defects and document the fixes
10) Quality Assurance audits the Documents and Test Logs

Various Software Tools have been development for Quality Management. These Tools can help us track Requirements and map Test Cases to the Requirements. They also help in Defect Tracking.

What is Defect Tracking?

This is very important to ensure the Quality of the end Product. As test cases are executed at various levels defects if any are found in the Software being tested. The Defects are logged and data is collected. The Software Development fixes these defects and documents how they were fixed The testing team verifies whether the defect was really fixed and closes the defects. This information is very useful. Proper tracking ensures that all Defects were fixed. The information also helps us for future projects.

The Capability Maturity Model defines various levels of Organization based on the processes that they follow.

Level 0
The following is true for “Level 0” Organizations -
There are no Processes, tracking mechanisms, no plans. It is left to the developer or any person responsible for Quality to ensure that the product meets expectations.

Level 1 – Performed Informally
The following is true for “Level 1” Organizations -
In Such Organizations, Typically the teams work extra hard to achieve the results. There are no tracking mechanisms, standards defined. The work is done but is informal and not well documented.

Level 2 – Planned and Tracked
The following is true for “Level 2” Organizations -
There are processes within a team and the team can repeat them or follow the processes for all projects that it handles.

However the process is not standardized throughout the Organization. All the teams within the organization do not follow the same standard.

Level 3 – Well-Defined
In “Level 3” Organizations the processes are well defined and followed throughout the organization.

Level 4 – Quantitatively Controlled
In “Level 4” Organizations -

- The processes are well defined and followed throughout the organization
- The Goals are defined and the actual output is measured
- Metrics are collected and future performance can predicted

Level 5 – Continuously Improving
“Level 5” Organizations have well defined processes, which are measured and the organization has a good understanding of IT projects affect the Organizational goals.
The Organization is able to continuously improve its processes based on this understanding.

Summary:

In this article we studied the Software Quality Management process.

• Software requirements phase.
• Software Design
• Implementation
• Testing
• Maintenance

In the whole development process, testing consumes highest amount of time. But most of the developers oversee that and testing phase is generally neglected. As a consequence, erroneous software is released. The testing team should be involved right from the requirements stage itself.

The various phases involved in testing, with regard to the software development life cycle are:

1. Requirements stage
2. Test Plan
3. Test Design.
4. Design Reviews
5. Code Reviews
6. Test Cases preparation.
7. Test Execution
8. Test Reports.
9. Bugs Reporting
10. Reworking on patches.
11. Release to production.

Requirements Stage

Normally in many companies, developers itself take part in the requirements stage. Especially for product-based companies, a tester should also be involved in this stage. Since a tester thinks from the user side whereas a developer can’t. A separate panel should be formed for each module comprising a developer, a tester and a user. Panel meetings should be scheduled in order to gather everyone’s view. All the requirements should be documented properly for further use and this document is called “Software Requirements Specifications”.

Test Plan

Without a good plan, no work is a success. A successful work always contains a good plan. The testing process of software should also require good plan. Test plan document is the most important document that brings in a process – oriented approach. A test plan document should be prepared after the requirements of the project are confirmed. The test plan document must consist of the following information:

• Total number of features to be tested.
• Testing approaches to be followed.
• The testing methodologies
• Number of man-hours required.
• Resources required for the whole testing process.
• The testing tools that are to be used.
• The test cases, etc

Test Design

Test Design is done based on the requirements of the project. Test has to be designed based on whether manual or automated testing is done. For automation testing, the different paths for testing are to be identified first. An end to end checklist has to be prepared covering all the features of the project.

The test design is represented pictographically. The test design involves various stages. These stages can be summarized as follows:

• The different modules of the software are identified first.
• Next, the paths connecting all the modules are identified.

Then the design is drawn. The test design is the most critical one, which decides the test case preparation. So the test design assesses the quality of testing process.

Test Cases Preparation

Test cases should be prepared based on the following scenarios:

• Positive scenarios
• Negative scenarios
• Boundary conditions and
• Real World scenarios

Design Reviews

The software design is done in systematical manner or using the UML language. The tester can do the reviews over the design and can suggest the ideas and the modifications needed.

Code Reviews

Code reviews are similar to unit testing. Once the code is ready for release, the tester should be ready to do unit testing for the code. He must be ready with his own unit test cases. Though a developer does the unit testing, a tester must also do it. The developers may oversee some of the minute mistakes in the code, which a tester may find out.

Test Execution and Bugs Reporting

Once the unit testing is completed and the code is released to QA, the functional testing is done. A top-level testing is done at the beginning of the testing to find out the top-level failures. If any top-level failures occur, the bugs should be reported to the developer immediately to get the required workaround.

The test reports should be documented properly and the bugs have to be reported to the developer after the testing is completed.

Release to Production

Once the bugs are fixed, another release is given to the QA with the modified changes. Regression testing is executed. Once the QA assures the software, the software is released to production. Before releasing to production, another round of top-level testing is done.

The testing process is an iterative process. Once the bugs are fixed, the testing has to be done repeatedly. Thus the testing process is an unending process.