Adobe ColdFusion 8 has officially been released.
Check it out here
Here is the official press release.
Enjoy CF 8.
Tuesday, July 31, 2007
Thursday, July 26, 2007
Adobe Unveils ColdFusion 8 Public Beta...
The ColdFusion 8 Public Beta is now available for download!
Adobe Press Release:
http://www.adobe.com/aboutadobe/pressroom/pressreleases/200705/053007ColdFusion.html
ColdFusion 8 Public Beta:
http://labs.adobe.com/technologies/coldfusion8
ColdFusion 8 Public Beta Hosting:
http://www.hostmysite.com/cf8
Adobe® ColdFusion® 8 is the highly-anticipated upcoming major release of ColdFusion. The public beta release provides developers with the opportunity to begin building applications with new ColdFusion 8 features as well as test their existing applications on the new version.
ColdFusion 8 allows developers to quickly and easily create compelling Internet applications that fit in today’s complex enterprise environments. Faster than any previous version of the software, ColdFusion 8 lets developers write more applications in less time with fewer lines of code—and then tune these applications for optimum performance. Here are just a few of the key features that you’ll discover in the public beta:
New Features
- Server monitoring to help identify server bottlenecks, allowing for tuning and improved performance.
- Step through code debugging in a new Eclipse plug-in debugger.
- Adobe Flex™ and Ajax features that let ColdFusion power personalized, multimedia-rich applications to enhance users’ experiences on the web.
- High-quality, dynamically created on-demand multimedia presentations.
- PDF document and form integration for a printable, portable way to intelligently capture and share information.
- Image creation and manipulation with more than 50 new CFML tags and functions.
- Native support for .NET objects to easily integrate ColdFusion applications with enterprise data and infrastructure services.
- Significant application runtime and server performance improvements.
Tuesday, July 24, 2007
Software Testing/QA courses from Universities across the World.
Mallikarjun Reddy of http://codeinspections.blogspot.com/ has a good compilation of testing courses.
Testing Courses in Universities:
The University of Western Ontario.
University of Maryland.
George Mason University
Winthorp
University of St.Thomas
University of Texas Dallas
University of Maryland.
George Mason University
Winthorp
University of St.Thomas
University of Texas Dallas
Testing Certification Exams:
Certified Software Quality Analyst (CSQA)
Certified Software Test Engineer (CSTE)
Quality Improvement Associate Certification (CQIA)
Six Sigma Black Belt Certification (SSBB).
Certified Test Manager (CTM)
Certified Software Test Professional (CSTP)
Certified Software Test Engineer (CSTE)
Quality Improvement Associate Certification (CQIA)
Six Sigma Black Belt Certification (SSBB).
Certified Test Manager (CTM)
Certified Software Test Professional (CSTP)
Tuesday, July 03, 2007
Tuesday, June 26, 2007
Testing strategies for Flash movies
During the development of your Flash movies, you might occasionally run into difficulties. This is usually because creating interesting movies and trying out new ideas always involves some experimentation on the part of the author. By testing your movies according to these simple guidelines, you can prevent problems from becoming obstacles.
Test early in development
When you begin a Flash project, plan to start testing the functionality of your movie early in the development process. This will help ensure that you discover any problems while they are still minor. Waiting to test can allow small problems to become larger ones, as you add subsequent features to your movie that depend on problematic functionality implemented earlier. By incorporating testing into your authoring process early, you'll find these problems and have the opportunity to fix them before adding additional features to your movie.
Test often during development
Testing should be an integral part of your Flash development process. Test the functionality of each small part of your movie as you add it rather than waiting until the movie's whole feature set is implemented.
Avoid building features that are interdependent without testing each one before adding the next. If you test this way, when problems arise you'll know that the most recently implemented feature is the most likely source of the problem. If you wait to test one feature until after the next feature is implemented, and one of those features exhibits a problem, you'll have a more complex set of possibilities to evaluate.
Save multiple versions of your movie as you progress. When difficulties arise, compare the current version to the last saved version to help locate the source of the problem.
Test on all target platforms
When you develop a Flash movie, you should spend some time defining who the audience for the movie will be. Part of this process is deciding what the minimum system requirements should be for the computers used by that audience.
Determine the slowest processor speed you want your movie to be able to play on and verify that the performance of your movie is acceptable on a processor of that speed. You should also determine if there is a range of configurations you will have to support (such as Windows NT and 2000, Macintosh) and test on enough of them so that you can infer success on all of them. Be sure to include parameters such as browser software, screen resolution, and memory in your testing.
This approach will help you find problems that are specific to an operating system or configuration, a class of problems entirely distinct from authoring errors.
Testing strategies
Use the following strategies to test your movies effectively:
Be sure to use the Control > Test Movie command. Testing in the Flash application is different from testing a SWF file. The Test Movie command simulates the true behavior of the SWF file.
If you run into a problem, try to isolate the problem in a new Flash file that incorporates only the problem feature or item. Make a list of the minimum steps required to reproduce the problem in a new file. This will usually shed light on the source of the problem in your actual movie. It will also reveal whether the problem is limited to one feature or caused by the interaction of two or more features in your movie.
Try to re-create the problem with different library media. Sometimes the source of a problem is within a specific media item used in your movie.
Try to re-create the problem on a different computer. This will help isolate problems with hardware configuration or with the Flash installation on a specific computer. If the problem exists only when the movie is posted to a server, determine whether the problem exists on only one server or all servers. Occasionally the server's MIME types may need to be edited to include the MIME types for Flash.
When using ActionScript, look for typos, missing punctuation, or inconsistent naming.
Thursday, June 07, 2007
Best Practices…
While developing a product one comes across many situations in which a person needs to take decisions which might present all alternatives which seem wrong or all alternatives which seem
correct. In case of such tough decisions, one has to be guided by some best practices which can
help him to solve this problem if not present a readymade solution to the problem.
The best practices can categorized into broad categories:
1) 10 must haves for a Quality Engineer.
2) Four things which any professional or entrepreneur cannot afford to forget.
The best practices of a Quality Engineer ensure that quality of the final product is ensured.
1. Know the technology
In the area of software development, technology is changing rapidly. What is new trend today
may become obsolete tomorrow. In this fast changing world a tester should keep abreast with
the latest in the technology world. A Tester should know what technology is being used for
developing applications. He should know the supporting technology associated with OS. This
will make sure that the tester will find bugs at the early stage, thus reducing the price for the fixing of bugs. Also, studying the technology helps study the competitor better and thus helping your product to have a good standing in the market. Studying the technology would also help the Quality Engineer to understand the workflow and the product better.
2. Learn from past experiences
Before writing the test plan and the test cases, QE should try to scan data from past projects,
which are similar in nature. This may give them some better test cases, issues that were
identified in the end of the cycle, some areas that could be automated. If the application is extension of earlier project, high priority and severity bugs should be regressed for current version of application.
3. Ensure sufficient coverage of feature workflow
The key to success of the testing effort is that when a customer uses the product, he/she
should be able to seamlessly use it. This kind of seamless experience can only be ensured if the
common user workflows have been tested thoroughly. The challenge here is that different users
use different features and in fact might even use the same feature in a different way. Here is
where the role of sufficient coverage comes in.
Coverage can broadly be classified into two categories:
a) Coverage of different functionalities present in the software
The software performs a series of tasks. However the usage of these tasks may vary depending
on the requirement of the customer. Once the possible workflows have been identified, one needs to prioritize the workflows depending upon the number of users who would use the particular feature.
b) Coverage of the different routes while going through the workflow of the software
Common functionalities can be accomplished in many different ways in most software. E.g. in
order to copy a text in Microsoft Word application, one can use the keyboard shortcut Ctrl+C, or
right click on the selected text and select copy. One can also use the edit menu to do the same.
Each of these three routes is important because a user can copy text using any of these. As a
Tester, one needs to find all possible routes of accomplishing a task. After the routes have been
Identified, Quality Engineer needs to see how much probable are these in a real world scenario.
Also study of usage of this feature in comparison to other features needs to be done. As for our
example, we need to know how much common it is for the user to use the ‘copy’ feature in
comparison to other features like ‘find’, ‘replace’, ‘cut’ etc.
4. Make a matrix for hardware to be supported by application (and prioritize the hardware)
Many applications support different configurations of hardware. A proper matrix ensures that application is working on important configuration of hardware.
5. Assign two QEs (primary and secondary)
An application has multiple features. There should be two QE assigned to a feature. The
QE can be assigned as primary QE and secondary QE. Primary QE is responsible for creating
test plan, test cases, setting test environment, executing testing, reporting bug and regression of
bugs. Secondary QE can work as a back up. He can be involved for reviewing test plan and
script, helping primary QE in setting up testing environment, executing some part of test cases at different interval and in regression of bugs. This will help in getting control of bug myopia (blindness to a bug if working for a long time in testing a feature).
....... to be continued
Thursday, May 17, 2007
Software Development Life-cycle
Definition: A systematic and orderly approach to solving problems related to software systems.
General problem-solving steps:
• Planning - identify the scope and boundary of the problem, and plan the development strategy and goals.
As software is always of a large system (or business), work begins by establishing the requirements for all system elements and then allocating some subset of these requirements to software. This system view is essential when the software must interface with other elements such as hardware, people and other resources. System is the basic and very critical requirement for the existence of software in any entity. So if the system is not in place, the system should be engineered and put in place. In some cases, to extract the maximum output, the system should be re-engineered and spruced up. Once the ideal system is engineered or tuned, the development team studies the software requirement for the system.
• Analysis - study and analyze the problems, causes, and effects. Then, identify and analyze the requirements that must be fulfilled by any successful solution.
This process is also known as feasibility study. In this phase, the development team visits the customer and studies their system. They investigate the need for possible software automation in the given system. By the end of the feasibility study, the team furnishes a document that holds the different specific recommendations for the candidate system. It also includes the personnel assignments, costs, project schedule, target dates etc.... The requirement gathering process is intensified and focussed specially on software. To understand the nature of the program(s) to be built, the system engineer or "Analyst" must understand the information domain for the software, as well as required function, behavior, performance and interfacing. The essential purpose of this phase is to find the need and to define the problem that needs to be solved .
• Design - if necessary, design the solution - not all solutions require design.
In this phase, the software development process, the software's overall structure and its nuances are defined. In terms of the client/server technology, the number of tiers needed for the package architecture, the database design, the data structure design etc... are all defined in this phase. A software development model is thus created. Analysis and Design are very crucial in the whole development cycle. Any glitch in the design phase could be very expensive to solve in the later stage of the software development. Much care is taken during this phase. The logical system of the product is developed in this phase.
• Implementation - implement the solution.
The design must be translated into a machine-readable form. The code generation step performs this task. If the design is performed in a detailed manner, code generation can be accomplished without much complication. Programming tools like compilers, interpreters, debuggers etc... are used to generate the code. Different high level programming languages like C, C++, Pascal, Java are used for coding. With respect to the type of application, the right programming language is chosen.
• Testing - verify the solution works.
Once the code is generated, the software program testing begins. Different testing methodologies are available to unravel the bugs that were committed during the previous phases. Different testing tools and methodologies are already available. Some companies build their own testing tools that are tailor made for their own development operations.
• Support - analyze the implemented solution, refine the design, and implement improvements to the solution. Different support situations can thread back into the previous steps.
The software will definitely undergo change once it is delivered to the customer. There can be many reasons for this change to occur. Change could happen because of some unexpected input values into the system. In addition, the changes in the system could directly affect the software operations. The software should be developed to accommodate changes that could happen during the post implementation period.
Methodology
Definition: An organized, documented set of procedures and guidelines for one or more phases of the software life cycle.
The physical implementation of the logical life cycle that incorporates
- step-by-step activities for each phase
- individual and group roles to be played in each activity
- deliverables and quality standards for each activity
- tools and techniques to be used for each activity.
A methodology is “how” the software development life-cycle is executed. There are many ways in which this can be achieved.
The Waterfall Model
The Spiral Model
Subscribe to:
Posts (Atom)
