Pages

Thursday, 27 February 2014

Smoke, A Testing Strategy


Vast number of products have been deployed into market every day by the organizations. All that they need is customers Satisfaction means a product with no single bug. Is it possible? Of course, It needs an endless exhaust testing, but very impractical. Defects of a product should be identified at the early stages of the process else fixing of that costs too much. 

What is a smoke test? 
 Starting with the definition, smoke test is a act performed after developing and before testing. It is a set of test cases for minimal functionality that needs to be work fine before starting to the actual testing. This test can be performed by the developers on their site or by testers before they go to finer detailed testing. The innovative strategy of the smoke test is to save the valuable time of the tester. 

How to perform it?
Smoke test can be done not only with manual but also by automation script. A set of scripts will be developed by the team and those scripts are make run when every new build was deployed to the testing environment. Once smoke test is implemented in software development life cycle, the overall product quality is improved and sensitivity to producing high quality software increased.

A smoke test will just follow a straight forward approach in testing their functional area. It needs to satisfy its objectives while doing it. Few of the objectives like "Does the application ready to go to test?", "Does the application is performing as intended","Does the application respond as expected for positive actions?" At least one positive test case must be designed for every feature in the application. All these tests are executed by either manual team or automation team.

Advantages of Smoke Test:
  • Saves time and cost of product, identifies defects in the early stage which saves the time and reduces huge costs in fixing the defects
  • Identifies major problems, a good design smoke test helps to identify the major problems during test. Also uncovers the defects arise because of wrong setup configuration during design.
  • Minimize risk in product quality, prevent problematic integration towards the application and  taking control over project.


Happy Testing...




  A Journey towards testing.

Tuesday, 31 December 2013

Agile!!! An Effective Testing Process

AGILE!!! AGILE!!! AGILE!!! one of the common word we are listening in testing society  now a days. What does agile means, Why agile came into picture, What makes agile differs from the regular testing practice.

The word "agile" in dictionary means, quicker, smart. The same in the software testing is make the testing process in quicker and smarter way. Main agenda of the agile process is to ensure delivering the business value desired by the customer at frequent intervals, working at a sustainable pace.

Agile principles 

The Agile Manifesto(Wikipedia) is based on the below twelve principles:

  1. Customer satisfaction by rapid delivery of useful software
  2. Welcome changing requirements, even late in development
  3. Working software is delivered frequently (weeks rather than months)
  4. Working software is the principal measure of progress
  5. Sustainable development, able to maintain a constant pace
  6. Close, daily cooperation between business people and developers
  7. Face-to-face conversation is the best form of communication (co-location)
  8. Projects are built around motivated individuals, who should be trusted
  9. Continuous attention to technical excellence and good design
  10. Simplicity—the art of maximizing the amount of work not done—is essential
  11. Self-organizing teams
  12. Regular adaptation to changing circumstances
 There are several models used by the organizations during software life cycle. For all these models WaterFall, a traditional testing approach is the basic I believe. Basically water-fall model has the linear activity.Once a phase has finished its part, these outputs are taken as inputs to the next phase. However, due to its sequential nature, this model is not capable of dealing with iterations and evolutions. We cannot alter the requirements in middle of the phases. Testing cannot be started until development phase completed. If any bug identified during one phase, it should be solved in same phase itself. Bugs identified in later phases of this model will consume more money as well as time. The main disadvantage of this model is, no iterative evolution for any phase once a phase done cannot go back.From a tester point of view a traditional testing approach looks like,
Image Courtesy: Google Images
To over come the pitfalls of the traditional testing approach, several advanced models have been developed. Among them V-Model is the most popular and many organization started following this model. Typically V-Model looks like,

                             
Image Courtesy: Google Images

In short V model is a Verification and Validation model. The left pane which is top to bottom is the Verification phase and the right pane which is bottom to top. The reason for calling it V is because most of the phases on the left have a corresponding phase of activity on the right. Coding part will started after all the design and document part has been completed, and corresponding test deign needs to be prepared.
  • BRS is prepared and verified during requirement analysis as well as the user acceptance test deign will be prepared.
  • SRS will be prepared and verified during system design and Test cases and scenarios prepared for all the functional specifications.
  • High Level Design(HLD) will be prepared during architectural phase based on the specifications and integration test design parallel to it.
  • Low Level Design(LLD) will be prepared for modular design phase and coding phase is officially started based on the LLD.
  • Validation part will be started after coding phase by executing according to the respective test design plan
 Advantage of the V-Model is validation and verification will done parallel in the same phase itself. It gives more importance to the strict process flow to develop a quality product.

Disadvantage is, if any changes made in middle of the phase then all its design documents need to be updated from the initial level. Client involvement during the software development is negligible.

The main difference we can observe in the agile process is the customer involvement during software development process and frequent deliverable. And the interesting thing is all the phases will start in parallel pace. New requirements are also accepted in the middle of the development. Here software will be developed in am incremental way I.e, a module is designed and developed. Immediately given for the testing and after that takes the customer feedback. In the same process, another module will be developed and integrate it with the previous module and release to the customer feedback.The same process would be iterated n number of times. Typically life cycle of agile methodology would be like,

Image Courtesy: Google Images

The above figure shows us agile process is a iterative with integrating module by module. To fulfill the agenda of the agile methodology some hard work needs to be beard by the team. Apart from the figure above in life cycle, few activities are also part of agile process. They are Regular Team Meetings, F2F Communication.

Team meeting is one of the most common practice and often easiest to implement. Each module is divided into the teams. Teams will be called as Sprints. Team players named as Scrums and Scrum Master is the Team Leader/Project Lead. All the regular meetings should be time boxed, facilitated by the scrum master. Agenda of the meeting would be discussed mainly on Tasks done by the scrum and the blockers struck. Scrum master will correlate the road blockers with the development team. Also the Project Report(PR) meeting should be held in a weekly or monthly basis with the customer, so that client can easily know the status of the project.

A face to face session arranged among SME's Developers and Testers. A defect management meeting about the high level defects in the application with SME's. They must discuss and prioritize all the high level defects and conclude are they valid one, if valid what is the impact of that on the application due to that. Who can fix this bug and more. Often walkthrough should be arranged about the changing parts, new working process or any additions requirements. Ensure that both development and testing teams are shared with the same kind of information.

That's it Agile is just Develop-> Integrate-> Test-> Feedback-> Release with sufficient iterations until customer requirements fulfilled. Disadvantage of agile process is, regular meetings. Yes, if the facilitator is  not well organized. If the initial project has planned without proper plan, then defensively the intended out come will be deviated.  However, the disadvantages can be nullified if you have a good consultant at hand.


Happy Testing...




A Journey towards Testing...:)


SDLC Vs STLC

Software Development Life Cycle(SDLC) and Software Testing Life Cycle(STLC), both has equal emphasis during the software development. Before started my journey towards testing, I know only one name of those, i.e., SDLC. Because that's what I read during my grad. Till then I thought of testing is just a method. For all the latest life cycle models water fall is the base and the initial one, in every model "testing" is just a phase. I was in a doubt, after-all it is a phase/process in a life cycle model why do it has a separate life cycle again?
There I started Google'd  with that name. I have read most of the articles and blogs. I got the answer but not able to convince with their explanation. They said strategy, plan, environment, testing levels. That's it. Haven't found any systematic way in that. But in one post, I saw the difference written by a testing geek. I was impressed with the explanation wrote and I convinced with the answer about how  s/w life cycle phases related with development and testing.Below is the table about SDLC and STLC.


S. No. Phase SDLC - Software Development Life cycle STLC - Software Test Life Cycle
1 Requirements Gathering Requirements gathering is done by business analyst. Development team analyse the requirements from the design, architecture & coding perspective. Testing team also review & analyse the requirements. Testing team identifies the testing requirements like what types of testing will be required and review the requirements for logical functional relationship between various features / modules, so that any gaps can be caught at an early stage.
2 Design Technical architect works for the high level & low design of the software. Business analyst works for the UI design of the application Here, test architect generally the test lead/manager, does the test planning, identify high level testing points. Basically, requirement detailing is done in this phase. 
3 Coding or development Development team does the actual coding based on the designed architecture. Testing team write the detailed test cases.
4 Testing In SDLC, actual testing is carried out in this phase. It includes unit testing, integration testing & system testing etc.. Test Execution and bug reporting, manual testing, automation testing is done, defects found are reported. Re-testing and regression testing is also done in this phase. But, I don't agree with this statement. So, if I want to relate the testing phase with STLC, I would say it it is testing of test cases & test plans i.e. is basically review of test cases, test scenarios etc..
5 Deployment Application is deployed on production environment for real end users. Final testing and implementation is done is this phase and final test report is prepared. For this statement as well, I don't agree. For software / application deployment is basically, when it is installed for real use. So, this way, STLC, deployment would be when test when test cases getting used i.e. execution of test cases.
6 Maintenance Basically, it includes, post production / deployment support & enhancements. Most of people say - Maintenance testing is carried out in this phase. My definition for this is - updation & maintenance of test plans, test case required for the testing of support requests & enhancements as a part of maintenance.
 Similarities Courtesy: http://www.softwaretestingstuff.com

Thanks for the author...
Happy Testing :)