martes, diciembre 31
How to write testcase for Email id ?
ECP:Equlence class partetioning:
its is one of the famous blackbox tech which is used for creation of the test cases.Equelence class is a subset of data that represents the larger calss.
ex:from the same question of validating the login id,if the req says that the mail id must consists of only alphabets then u need to test
1.weather login id accepts numbers.(this is one equlence class)
2.weather login id accepts a spl symbol(this is other equilence class)
Equlence partetioning is testing for equlence class rather than taking exaustive testing i.e in first case u need not test for all the combinations of numbers in the second case u need not test for all the combinations of spl characters.
BVA:Boundary Value analysis:it is also another famous blackbox testcase design tec,where we need to focus on the i/p and o/p boundaries of the system funtion.
ex:in the same login id example if the req damands that the mail id must be 8 chars long we write test cases to check for 7 and 9 chars respectively.
coming to the test case on email id,
1.Check for ECP i.e weather the system accepts all the numbers or alphabets or spl charteristics.here we had derived 3 Equalence classes.
2.check for Boundary value analysis i.e if the req says the login id must be 8 chars long (excluding domain name,ex:xxxxxxxx.gmail.com)then check the loginid for 7 chars and 9 chrars.
3.Check weather the loginid accepts the user name starting with caps letter or number or spl charaters.
4.the spl characters used generally are '_',"." aprt from this the system automatically gives u the '@"symbol.
5.check weather the system accepts
a.more than one spl symbol..i.e xxx.xx_x@gmail.com/xxx@x.xx@gmail.com
b.The same spl characters for more than once i.e xxx_xx_x@gmail.com
6.Check for comination of equelnce classes.
i.e combining alphabets and numbers..i.e aaa2aaa1@gmail.com
7.check the mail can be of same domain name i.e gmail@gmail.com
8..apart from this u can even test the GUI of the login field,when we move the curser on to text field the arrow pointer of mouse must become "I" shape(part of cursery testing),
the curser must be blinking in the testfield so as to make the user to pay attention,and even in some aplications the textfield where the cursor blinks will be in highlighted.
Fuente: http://ssoftwaretesting.blogspot.mx/2010/07/how-to-write-testcase-for-email-id.html
lunes, diciembre 30
Guias de blogs sobre de pruebas
Blogs sobre pruebas de software
pedrosebastianmingo.com/blog
synergix.wordpress.com
Software Testing ( softwaretestingguide.blogspot.mx )
Guias de Utilidades de pruebas
QTP ( quicktestproguide.blogspot.mx )
LoadRunner
WinRunner ( winrunnerfaqs.blogspot.mx )
Quality Center ( qualitycenterguide.blogspot.mx )
SQL Server ( mssqlserverguide.blogspot.mx )
http://testingreflections.com/
http://googletesting.blogspot.mx/
http://www.wilsonmar.com/
http://www.wilsonmar.com/1loadrun.htm
pedrosebastianmingo.com/blog
synergix.wordpress.com
Software Testing ( softwaretestingguide.blogspot.mx )
Guias de Utilidades de pruebas
QTP ( quicktestproguide.blogspot.mx )
LoadRunner
WinRunner ( winrunnerfaqs.blogspot.mx )
Quality Center ( qualitycenterguide.blogspot.mx )
SQL Server ( mssqlserverguide.blogspot.mx )
http://testingreflections.com/
http://googletesting.blogspot.mx/
http://www.wilsonmar.com/
http://www.wilsonmar.com/1loadrun.htm
viernes, diciembre 27
Database Testing – Properties of a Good Test Data and Test Data Preparation Techniques
A couple of months ago, I wrote about database testing strategies.
It covered the aspect that is entirely related to the execution of test
cases. It was all about black-box testing of a database. There is
another important aspect of DB testing activity which we will cover in
this article.
As a tester, you have to test the ‘Examination Results’ module of the website of a university. Consider the whole application has been integrated and it is in ‘Ready for Testing’ state. ‘Examination Module’ is linked with ‘Registration’, ‘Courses’ and ‘Finance’ modules. Assume that you have adequate information of the application and you created a comprehensive list of test scenarios. Now you have to design, document and execute these test cases. In ‘Actions/Steps’ section of the test cases, you must mention the acceptable data as input for the test. The data mentioned in test cases must be selected properly. The accuracy of ‘Actual Results’ column of TC Document is primarily dependent upon the test data. So, step to prepare the input test data is significantly important. Thus, here is my rundown on ”DB Testing – Test Data Preparation Strategies”.
The test data should be selected precisely and it must possess the following four qualities:
1. Realistic: By realistic, it means the data should be accurate in the context of real life e.g. in order to test ‘Age’ field, all the values should be positive and 18 or above. It is quite obvious that the candidates for an admission in the university are usually 18 years old (this might be defined in requirements).
2. Practically valid: This is similar to realistic but not the same. This property is more related to the business logic of AUT e.g. value 60 is realistic in age field but practically invalid for a candidate of Graduation or even Masters Programs. In this case, a valid range would be 18-25 years (this might be defined in requirements).
3. Versatile to cover scenarios: There may be several subsequent conditions in a single scenario, so choose the data shrewdly to cover maximum aspects of a single scenario with minimum set of data, e.g. while creating test data for result module, do not only consider the case of regular students who are smoothly completing their program. Give attention to the students who are repeating the same course and belong to different semesters or even different programs. The data set may look like this:
There
might be several other interesting and tricky sub-conditions. E.g. the
limitation of years to complete a degree program, passing a prerequisite
course for registering a course, maximum no. of courses a student may
enroll in a single semester etc. etc. Make sure to cover all these
scenarios wisely with finite set of data.
4. Exceptional data (if applicable/required): There may be certain exceptional scenarios that are less frequent but demand high importance when occur, e.g. disabled students related issues.
There are only two ways to prepare test data:
Method 1. Insert New Data:
Get a clean DB and insert all the data as specified in your test cases. Once, all your required and desired data has been entered, start executing your test cases and fill ‘Pass/Fail’ columns by comparing the ‘Actual Output’ with ‘Expected Output’. Sounds simple, right? But wait, it’s not that simple.
Few essential and critical concerns are as follows:
This is the feasible and more practical technique for test data preparation. However it requires sound technical skills and demands detailed knowledge of DB Schema and SQL. In this method you need to copy and use production data by replacing some field values by dummy values. This is the best data subset for your testing as it represents the production data. But this may not be feasible all the time due to data security and privacy issues.
This strategy deserves one separate post which we’ll discuss in next article ‘Database gray-box testing’ and precautions to take while testing database.
http://www.softwaretestinghelp.com/database-testing-test-data-preparation-techniques/
As a tester, you have to test the ‘Examination Results’ module of the website of a university. Consider the whole application has been integrated and it is in ‘Ready for Testing’ state. ‘Examination Module’ is linked with ‘Registration’, ‘Courses’ and ‘Finance’ modules. Assume that you have adequate information of the application and you created a comprehensive list of test scenarios. Now you have to design, document and execute these test cases. In ‘Actions/Steps’ section of the test cases, you must mention the acceptable data as input for the test. The data mentioned in test cases must be selected properly. The accuracy of ‘Actual Results’ column of TC Document is primarily dependent upon the test data. So, step to prepare the input test data is significantly important. Thus, here is my rundown on ”DB Testing – Test Data Preparation Strategies”.
Properties of Test Data:
1. Realistic: By realistic, it means the data should be accurate in the context of real life e.g. in order to test ‘Age’ field, all the values should be positive and 18 or above. It is quite obvious that the candidates for an admission in the university are usually 18 years old (this might be defined in requirements).
2. Practically valid: This is similar to realistic but not the same. This property is more related to the business logic of AUT e.g. value 60 is realistic in age field but practically invalid for a candidate of Graduation or even Masters Programs. In this case, a valid range would be 18-25 years (this might be defined in requirements).
3. Versatile to cover scenarios: There may be several subsequent conditions in a single scenario, so choose the data shrewdly to cover maximum aspects of a single scenario with minimum set of data, e.g. while creating test data for result module, do not only consider the case of regular students who are smoothly completing their program. Give attention to the students who are repeating the same course and belong to different semesters or even different programs. The data set may look like this:
| Sr# | Student_ID | Program_ID | Course_ID | Grade |
| 1 | BCS-Fall2011-Morning-01 | BCS-F11 | CS-401 | A |
| 2 | BCS-Spring2011-Evening-14 | BCS-S11 | CS-401 | B+ |
| 3 | MIT-Fall2010-Afternoon-09 | MIT-F10 | CS-401 | A- |
| … | … | … | … | … |
4. Exceptional data (if applicable/required): There may be certain exceptional scenarios that are less frequent but demand high importance when occur, e.g. disabled students related issues.
est data preparation techniques:
We have briefly discussed the important properties of test data and it also elaborates how test data selection is important while database testing. Now let’s discuss the ‘techniques to prepare test data’.There are only two ways to prepare test data:
Method 1. Insert New Data:
Get a clean DB and insert all the data as specified in your test cases. Once, all your required and desired data has been entered, start executing your test cases and fill ‘Pass/Fail’ columns by comparing the ‘Actual Output’ with ‘Expected Output’. Sounds simple, right? But wait, it’s not that simple.
Few essential and critical concerns are as follows:
- Empty instance of database may not be available
- Inserted test data may be insufficient for testing some cases like performance and load testing.
- Inserting the required test data into blank DB is not an easy job due to the database table dependencies. Because of this inevitable restriction, data insertion can become difficult task for tester.
- Insertion of limited test data (just according to the test cases needs) may hide some issues that could be found only with the large data set.
- For data insertion, complex queries and/or procedures may be required, and for this sufficient assistance or help from the DB developer(s) would be necessary.
- Execution of TCs becomes more efficient as the DB has the required data only.
- Bugs isolation requires no time as only the data specified in test cases present in the DB.
- Less time required for testing and results comparison.
- Clutter-free test process
This is the feasible and more practical technique for test data preparation. However it requires sound technical skills and demands detailed knowledge of DB Schema and SQL. In this method you need to copy and use production data by replacing some field values by dummy values. This is the best data subset for your testing as it represents the production data. But this may not be feasible all the time due to data security and privacy issues.
This strategy deserves one separate post which we’ll discuss in next article ‘Database gray-box testing’ and precautions to take while testing database.
http://www.softwaretestinghelp.com/database-testing-test-data-preparation-techniques/
Database Testing – Practical Tips and Insight on How to Test Database
Database is one of the inevitable parts of a software application these days. It does not matter at all whether it is web or desktop, client server or peer to peer, enterprise or individual business, database is working at backend. Similarly, whether it is healthcare of finance, leasing or retail, mailing application or controlling spaceship, behind the scene a database is always in action.
Moreover, as the complexity of application increases the need of stronger and secure database emerges. In the same way, for the applications with high frequency of transactions (e.g. banking or finance application), necessity of fully featured DB Tool is coupled.
Currently, several database tools are available in the market e.g. MS-Access2010, MS SQL Server 2008 r2, Oracle 10g, Oracle Financial, MySQL, PostgreSQL, DB2 etc. All of these vary in cost, robustness, features and security. Each of these DBs possesses its own benefits and drawbacks. One thing is certain; a business application must be built using one of these or other DB Tools.
Before I start digging into the topic, let me comprehend the foreword. When the application is under execution, the end user mainly utilizes the ‘CRUD’ operations facilitated by the DB Tool.
C: Create – When user ‘Save’ any new transaction, ‘Create’ operation is performed.
R: Retrieve – When user ‘Search’ or ‘View’ any saved transaction, ‘Retrieve’ operation is performed.
U: Update – when user ‘Edit’ or ‘Modify’ an existing record, the ‘Update’ operation of DB is performed.
D: Delete – when user ‘Remove’ any record from the system, ‘Delete’ operation of DB is performed.
It does not matter at all, which DB is used and how the operation is preformed. End user has no concern if any join or sub-query, trigger or stored-procedure, query or function was used to do what he wanted. But, the interesting thing is that all DB operations performed by user, from UI of any application, is one of the above four, acronym as CRUD.
As a database tester one should be focusing on following DB testing activities:
What to test in database testing:
1) Ensure data mapping:
Make sure that the mapping between different forms or screens of AUT and the Relations of its DB is not only accurate but is also according to design documents. For all CRUD operations, verify that respective tables and records are updated when user clicks ‘Save’, ‘Update’, ‘Search’ or ‘Delete’ from GUI of the application.2) Ensure ACID Properties of Transactions:
ACID properties of DB Transactions refer to the ‘Atomicity’, ‘Consistency’, ‘Isolation’ and ‘Durability’. Proper testing of these four properties must be done during the DB testing activity. This area demands more rigorous, thorough and keen testing when the database is distributed.3) Ensure Data Integrity:
Consider that different modules (i.e. screens or forms) of application use the same data in different ways and perform all the CRUD operations on the data. In that case, make it sure that the latest state of data is reflected everywhere. System must show the updated and most recent values or the status of such shared data on all the forms and screens. This is called the Data Integrity.4) Ensure Accuracy of implemented Business Rules:
Today, databases are not meant only to store the records. In fact, DBs have been evolved into extremely powerful tools that provide ample support to the developers in order to implement the business logic at DB level. Some simple examples of powerful features of DBs are ‘Referential Integrity’, relational constrains, triggers and stored procedures. So, using these and many other features offered by DBs, developers implement the business logic on DB level. Tester must ensure that the implemented business logic is correct and works accurately.Above points describe the four most important ‘What Tos’ of database testing. Now, I will put some light on ‘How Tos’ of DB Testing. But, first of all I feel it better to explicitly mention an important point. DB Testing is a business critical task, and it should never be assigned to a fresh or inexperienced resource without proper training.
How To Test Database:
1. Create your own Queries
In order to test the DB properly and accurately, first of all a tester should have very good knowledge of SQL and specially DML (Data Manipulation Language) statements. Secondly, the tester should acquire good understanding of internal DB structure of AUT. If these two pre-requisites are fulfilled, then the tester is ready to test DB with complete confidence. (S)He will perform any CRUD operation from the UI of application, and will verify the result using SQL query.This is the best and robust way of DB testing especially for applications with small to medium level of complexity. Yet, the two pre-requisites described are necessary. Otherwise, this way of DB testing cannot be adopted by the tester.
Moreover, if the application is very complex then it may be hard or impossible for the tester to write all of the needed SQL queries himself or herself. However, for some complex queries, tester may get help from the developer too. I always recommend this method for the testers because it does not only give them the confidence on the testing they have performed but, also enhance their SQL skill.
2. Observe data table by table
If the tester is not good in SQL, then he or she may verify the result of CRUD operation, performed using GUI of the application, by viewing the tables (relations) of DB. Yet, this way may be a bit tedious and cumbersome especially when the DB and tables have large amount of data.Similarly, this way of DB testing may be extremely difficult for tester if the data to be verified belongs to multiple tables. This way of DB testing also requires at least good knowledge of Table structure of AUT.
3. Get query from developer
This is the simplest way for the tester to test the DB. Perform any CRUD operation from GUI and verify its impacts by executing the respective SQL query obtained from the developer. It requires neither good knowledge of SQL nor good knowledge of application’s DB structure.So, this method seems easy and good choice for testing DB. But, its drawback is havoc. What if the query given by the developer is semantically wrong or does not fulfill the user’s requirement correctly? In this situation, the client will report the issue and will demand its fix as the best case. While, the worst case is that client may refuse to accept the application.
Conclusion:
Database is the core and critical part of almost every software application. So DB testing of an application demands keen attention, good SQL skills, proper knowledge of DB structure of AUT and proper training.In order to have the confident test report of this activity, this task should be assigned to a resource with all the four qualities stated above. Otherwise, shipment time surprises, bugs identification by the client, improper or unintended application’s behavior or even wrong outputs of business critical tasks are more likely to be observed. Get this task done by most suitable resources and pay it the well-deserved attention.
http://www.softwaretestinghelp.com/database-testing-%E2%80%93-practical-tips-and-insight-on-how-to-test-database/
How to Improve Your Testing Skills and Beat the Competition!
8 Practical Tips to Keep Mind in Tune for Testing
#1. Think testing about everything around youWhen you are traveling or when you are cooking or when you are playing with a kid or when you are taking a walk in the garden or when you are reading a book – observe everything around you and order your mind to prepare test ideas to test the specific things. Think at least 5 test ideas for everything around you, every time you get a chance to think about.
Think how can you test a train, how can you test a spoon, how can you test a book, how can you test a jar, how can you test a cable, how can you test a remote…..endless list it is. After following this practice for 15 days, see the difference in yourself. You will be full of ideas. You will be able to understand things properly and will be able to co-relate the things.
#2. Learn a new thing everyday
No matter whether it’s a small testing technique or an automation tool, you must have at least one item to list as “Learned” every day. Small amount of knowledge when accumulated creates an ocean of the same. This practice, if followed, will surely show wonders in your career. Try it!!!
#3. Keep diversified interests
Now a days, it’s expected that the quality person should be aware about development lifecycle, documentation, testing processes, programming, analysis, automation, knowledge across different domains.
It’s not easy to learn something else, while you are already busy testing something specific. But at the same time, you cannot take a risk of pulling your career chords downwards. Open your eyes and see what is happening around you. You cannot learn everything but you definitely can have some idea about some of the important things/domains other than the specific one, you have been working on.
- If you have been working on windows operating system, see how Linux works, read about it, explore it.
- If you have been a manual tester for all the years of career till now, see what kind of automation tools are available and explore it.
- If you have been doing web application testing so far, look into how mobile application testing is different.
- If you have been working in banking domain, understand how healthcare domain works.
#4. Play games
There are numerous strategy games, pattern finding games, missing letter games available for free. Use the opportunity and learn from them. Games make your mind sharp and alert. And the sharp mind is able to find something hidden easily.
#5. Read
Read whatever you can. It’s not necessary to read only software testing books to become a good tester. If you are able to co-relate things correctly, books on any subject will be a treasure for you.
#6. Take breaks
Human has a tendency of getting used to. If you look at a broken piece of furniture for longer time, your mind, at one point will start thinking about how perfect that piece was rather than the broken part. Don’t stick your eyes, constantly on the same thing. Take breaks, observe surrounding, discuss knowledge and resume work. Difference? A lot.
#7. Keep a note
Everyday, in a notepad, jot down minimum five points about what you learn or what you did to make things happen or what did you find or what ideas did you implement. It would be a treasure on re-visit.
#8. Learn management
You can achieve success only if you can manage things better. Learn and observe from your managers – how they manage resources, clients, projects, timeline and other hurdles.
To manage something you need not to be a manager. Start from your work and time. Try to help others and take help when required. The management skill will grow with constant practice but will surely take out the best from you.
Conclusion:
I am stopping here as I think I have covered the points to practice out daily. I am not interested in mentioning points about sharing/upgrading knowledge or discussing different topics because I think everyone of us is doing it as part of our work.Finally, try to be an exploratory tester and you will be able to fit in all the other categories.
http://www.softwaretestinghelp.com/how-to-improve-your-testing-skills-and-beat-the-competition/
jueves, diciembre 26
What Types of Database Questions are Asked in Interview for Testing Positions? – Testing Q&A Series
This article is a part of software testing questions and answers
series. You can see all previous articles under this Q&A series on
this page – Software Testing Questions & Answers. If you want to ask a question, just write a comment below.
Mallik asks:
Irrespective of the position, candidate should always be clear and confident about the database concepts. For most software testing positions you need to have database knowledge to perform some database checks. Almost all applications need an interaction with database.
Let’s consider the database interview questions for entry-level software testing positions. For entry level testing positions generally following questions can be asked in interviews:
1) Basic and to some extent nested SQL queries to fetch data from database tables.
2) Examples of database statements for: Create Database, Create table and Drop Table.
3) Concept of “Primary Key”, “Foreign Key” and DB index
4) Examples of Select, Insert, Delete, Alter and Update SQL statements.
5) SQL joins (Inner Join, Left Join, Right Join and Full join) with examples.
Practice SQL join queries on dummy tables and see results.
For experienced level software testing positions, database interview questions depend on the job requirement. For such positions interviewers expect detailed database knowledge from candidates.
One more important point – If you get questions on database SQL queries, never say that “You get all query statements to be executed from developers”. It’s ok to say that you get help from developers to write complex SQL queries, but finally you manage by your own.
Shariff asks:
I see many companies follow test strategy template very strictly. Even without any standard template you can keep this test strategy document simple but still effective.
Simple Tips to Write Test Strategy Document:
1) Include product background in test strategy document. In first paragraph of your test strategy document answer – Why stakeholders want to develop this project? This will help to understand and prioritize things quickly.
2) List all important features you are going to test. If you think some features are not part of this release then mention those features under “Features not to be tested” label.
3) Write down the test approach for your project. Clearly mention what types of testing you are going to conduct?
I.e. Functional testing, UI testing, Integration testing, Load/Stress testing, Security testing etc.
4) Answer questions like: How you are going to perform functional testing? Manual or automation testing? Are you going to execute all test cases from your test management tool?
5) Which bug tracking tool you are going to use? What will be the process when you will find a new bug?
6) What are your test entry and exit criteria?
7) How you will track your testing progress? What metrics are you going to use for tracking test completion?
8 ) Task distribution – Define roles and responsibilities of each team member.
9) What documents you will produce during and after testing phase?
10) What all risk you see in test completion?
http://www.softwaretestinghelp.com/what-type-of-database-questions-are-asked-in-interview-for-testing-positions/
Mallik asks:
This depends on many factors whether these questions are for testing positions at entry level or for experienced testing professionals. The depth of database interview questions depend on the experience of the candidate.What type of database (SQL) questions asked in interviews for test engineer position (not for database tester)?
Irrespective of the position, candidate should always be clear and confident about the database concepts. For most software testing positions you need to have database knowledge to perform some database checks. Almost all applications need an interaction with database.
Let’s consider the database interview questions for entry-level software testing positions. For entry level testing positions generally following questions can be asked in interviews:
1) Basic and to some extent nested SQL queries to fetch data from database tables.
2) Examples of database statements for: Create Database, Create table and Drop Table.
3) Concept of “Primary Key”, “Foreign Key” and DB index
4) Examples of Select, Insert, Delete, Alter and Update SQL statements.
5) SQL joins (Inner Join, Left Join, Right Join and Full join) with examples.
Practice SQL join queries on dummy tables and see results.
For experienced level software testing positions, database interview questions depend on the job requirement. For such positions interviewers expect detailed database knowledge from candidates.
One more important point – If you get questions on database SQL queries, never say that “You get all query statements to be executed from developers”. It’s ok to say that you get help from developers to write complex SQL queries, but finally you manage by your own.
Shariff asks:
In simple words – Test strategy means “How you are going to test the application?” You need to mention the exact process/strategy that you are going to follow when you will get the application for testing.What is Test Strategy?
I see many companies follow test strategy template very strictly. Even without any standard template you can keep this test strategy document simple but still effective.
Simple Tips to Write Test Strategy Document:
1) Include product background in test strategy document. In first paragraph of your test strategy document answer – Why stakeholders want to develop this project? This will help to understand and prioritize things quickly.
2) List all important features you are going to test. If you think some features are not part of this release then mention those features under “Features not to be tested” label.
3) Write down the test approach for your project. Clearly mention what types of testing you are going to conduct?
I.e. Functional testing, UI testing, Integration testing, Load/Stress testing, Security testing etc.
4) Answer questions like: How you are going to perform functional testing? Manual or automation testing? Are you going to execute all test cases from your test management tool?
5) Which bug tracking tool you are going to use? What will be the process when you will find a new bug?
6) What are your test entry and exit criteria?
7) How you will track your testing progress? What metrics are you going to use for tracking test completion?
8 ) Task distribution – Define roles and responsibilities of each team member.
9) What documents you will produce during and after testing phase?
10) What all risk you see in test completion?
http://www.softwaretestinghelp.com/what-type-of-database-questions-are-asked-in-interview-for-testing-positions/
Black Grey and White Testing
Internals
Not
Known
Internals
Not
Known
Black Box Testing-
Internals Not Known |
Grey Box Testing-
Internals
Partially
Known
|
White Box Testing-
Internals Fully Known |
|||||||||
1.
|
The Internal Workings of
an application are not
required to be known
|
Somewhat knowledge of
the internal workings are
known
|
Tester has full
knowledge of the
Internal workings of
the application
|
||||||||
2.
|
Also known as closed box
testing, data driven
testing and functional
testing
|
Another term for grey box
testing is translucent
testing as the tester has
limited knowledge of the
insides of the application
|
Also known as clear
box testing, structural
testing or code based
testing
|
||||||||
3.
|
Performed by end users
and also by testers and
developers
|
Performed by end users
and also by testers and
developers
|
Normally done by
testers and developers
|
||||||||
4.
|
-Testing is based on
external expectations
-Internal behavior of the
application is unknown
|
Testing is done on the
basis of high level
database diagrams and
data flow diagrams
|
Internal workings are
fully known and the
tester can design test
data accordingly
|
||||||||
5.
|
This is the least time
consuming and
exhaustive
|
Partly time consuming
and exhaustive
|
The most exhaustive
and time consuming
type of testing
|
||||||||
6.
|
Not suited to algorithm
testing
|
Not suited to algorithm
testing
|
Suited for algorithm
testing
|
||||||||
7.
|
This can only be done by
trial and error method
|
Data domains and
Internal boundaries can
be tested, if known
|
Data domains and
Internal boundaries
can be better tested
|
||||||||
martes, diciembre 24
Revista Testing Circus
Testing Circus is a free to download monthly International Software Testing Magazine.
Testing Circus is conceptualized, founded and edited by Ajoy Kumar Singha. Testing Circus is subscribed by thousands of software testers worldwide. Well known testers like Pradeep Soundararajan, Vipul Kocher, Vipul Gupta, Lisa Crispin, Narayan Raman, Trish Khoo, Markus Gartner, Santhosh Tuppad, Parimala Shankaraiah, Ajay Balamurugadas, Bernice Niel Ruhland, Rob van Steenbergen, Jaijeet Pandey, Doron Reuveni, Michael Talks, Marc Rambert have written for Testing Circus magazine in the past. Testing Circus is one of the world’s leading English language magazine for software testers and test enthusiasts. It has established itself as a platform for knowledge transfer in software testing profession.
Testing Circus is conceptualized, founded and edited by Ajoy Kumar Singha. Testing Circus is subscribed by thousands of software testers worldwide. Well known testers like Pradeep Soundararajan, Vipul Kocher, Vipul Gupta, Lisa Crispin, Narayan Raman, Trish Khoo, Markus Gartner, Santhosh Tuppad, Parimala Shankaraiah, Ajay Balamurugadas, Bernice Niel Ruhland, Rob van Steenbergen, Jaijeet Pandey, Doron Reuveni, Michael Talks, Marc Rambert have written for Testing Circus magazine in the past. Testing Circus is one of the world’s leading English language magazine for software testers and test enthusiasts. It has established itself as a platform for knowledge transfer in software testing profession.
The magazine publishes various topics on software testing including -
- Articles on software testing
- Test Ideas on various applications
- Testing Tools and Tutorials
- Book reviews and recommendations by testers
- Interviews of testing professionals
- Testing News and Update
- Testing Blogs/sites to follow
- Professional Guidance
- Tips and Tricks on Testing
- Information on testers @Twitter
The first edition of the Testing Circus was published in September, 2010.
2013
Volumen 1 Permalink Volumen 2 Permalink Volumen 3 Permalink Volumen 4 Permalink Volumen 5 Permalink
Volumen 6 Permalink Volumen 7 Permalink Volumen 8 Permalink Volumen 9 Permalink Volumen 10 Permalink
Volumen 11 Permalink Volumen 12 Permalink
2012
Volumen 1 Permalink Volumen 2 Permalink Volumen 3 Permalink Volumen 4 Permalink Volumen 5 Permalink
Volumen 6 Permalink Volumen 7 Permalink Volumen 8 Permalink Volumen 9 Permalink Volumen 10 Permalink
Volumen 11 Permalink Volumen 12 Permalink
2011
Volumen 1 Permalink Volumen 2 Permalink Volumen 3 Permalink Volumen 4 Permalink Volumen 5 Permalink
Volumen 6 Permalink Volumen 7 Permalink Volumen 8 Permalink Volumen 9 Permalink Volumen 10 Permalink
Volumen 11 Permalink Volumen 12 Permalink
2010
Volumen 1 Permalink Volumen 2 Permalink Volumen 3 Permalink
sábado, diciembre 21
Flashcards de pruebas
http://quizlet.com/2514448/istqb-glossary-terms-flash-cards/
http://quizlet.com/15493798/istqb-glossary-terms-ii-flash-cards/
Ask yourself what were you hired to do?
Many times it feels like the
people in the project don’t really understand what you are doing and
why? It can go as far as feeling the testing team is the only one
stopping the product from being released to the field. Have you ever
wondered if this is right?
I read a nice post in TestingReflections by John McConda. John talks about the fact that testers provide a service to the team, and that many times we suffer what he calls “genius envy”, leading us to act as gatekeepers and/or play games of power with the rest of the project stakeholders.
I agree with him.
Not only that, but I can testify that I used to suffer of these “genius envy” attacks (I just love his definition) and was constantly looking for an escape route out of the testing Job misery I had gotten myself into.
After a while, as I started learning more about testing and how to do it right, I began perceiving the real value we could bring into the process.
I remember how my personal perspective changed; I was suddenly able to explain to my friends and family what I did for a living without feeling the need to apologize for being second best in the team.
But I want to take this to another point, the point where we should define our tasks as services and ourselves as service providers.
Think for a moment about another service provider in a different professional area, a tailor for example. Whenever a client comes to his shop, the tailor knows he needs to understand the needs, likes and constraints of his customer in order to design and make the correct garment.
Why should testing be different? We know that our customers want to use our testing abilities, but we need to understand what are their objectives, needs and constraints in order to provide the correct set of test and services.
At this point I want to introduce something that helps me provide a better service to my development “customers”, my personal view of the testing team’s objective.
Based on my experience I see the goal of the testing team as follows:
1. Visibility – testing is not aimed at finding all the bugs, it needs to provide a clear view of the status of the application (bug numbers are only a small part of it!).
2. Correct and timely – the information should be right and corroborated (if possible backed by facts and not only gut feelings); and it needs to be provided when it matters and is still relevant to the stakeholders and the project.
3. Help the Organization make decisions – we are not gatekeepers in charge of stopping the application from reaching the field. We are in charge providing inputs about the product and process that will help the Company to act correctly; these actions will be based in part on our information but also on additional factors and inputs such as marketing considerations, sales objectives and deals, operations, etc.
4. Work based on constraints – this is where reality enters the scene and we need to do our best under the current project constraints.
All the points above provide us only with a framework. The concrete definition of our objectives and tasks will be dictated by the goals, needs and constraints of the project as defined by its stakeholders. The job of the Test Team Manager is then to understand what is needed, and to create and execute a plan that supplies these needs.
If we understand we are providing a service and we know who are customers are, then we can go to these customers and ask them what their needs are. If we know why they are “hiring” us we will know how to provide our service in the best possible way.
Just go and ask them why did they hire you?
I read a nice post in TestingReflections by John McConda. John talks about the fact that testers provide a service to the team, and that many times we suffer what he calls “genius envy”, leading us to act as gatekeepers and/or play games of power with the rest of the project stakeholders.
I agree with him.
Not only that, but I can testify that I used to suffer of these “genius envy” attacks (I just love his definition) and was constantly looking for an escape route out of the testing Job misery I had gotten myself into.
After a while, as I started learning more about testing and how to do it right, I began perceiving the real value we could bring into the process.
I remember how my personal perspective changed; I was suddenly able to explain to my friends and family what I did for a living without feeling the need to apologize for being second best in the team.
But I want to take this to another point, the point where we should define our tasks as services and ourselves as service providers.
Think for a moment about another service provider in a different professional area, a tailor for example. Whenever a client comes to his shop, the tailor knows he needs to understand the needs, likes and constraints of his customer in order to design and make the correct garment.
Why should testing be different? We know that our customers want to use our testing abilities, but we need to understand what are their objectives, needs and constraints in order to provide the correct set of test and services.
At this point I want to introduce something that helps me provide a better service to my development “customers”, my personal view of the testing team’s objective.
Based on my experience I see the goal of the testing team as follows:
“To
provide correct and timely visibility into the product and process, in
order to help the organization make tactical and strategic decisions;
and to do this as close as possible to the defined constraints of
schedule, functionality and costs”.
The main components of this definition are:1. Visibility – testing is not aimed at finding all the bugs, it needs to provide a clear view of the status of the application (bug numbers are only a small part of it!).
2. Correct and timely – the information should be right and corroborated (if possible backed by facts and not only gut feelings); and it needs to be provided when it matters and is still relevant to the stakeholders and the project.
3. Help the Organization make decisions – we are not gatekeepers in charge of stopping the application from reaching the field. We are in charge providing inputs about the product and process that will help the Company to act correctly; these actions will be based in part on our information but also on additional factors and inputs such as marketing considerations, sales objectives and deals, operations, etc.
4. Work based on constraints – this is where reality enters the scene and we need to do our best under the current project constraints.
All the points above provide us only with a framework. The concrete definition of our objectives and tasks will be dictated by the goals, needs and constraints of the project as defined by its stakeholders. The job of the Test Team Manager is then to understand what is needed, and to create and execute a plan that supplies these needs.
If we understand we are providing a service and we know who are customers are, then we can go to these customers and ask them what their needs are. If we know why they are “hiring” us we will know how to provide our service in the best possible way.
Just go and ask them why did they hire you?
http://qablog.practitest.com/2008/08/ask-yourself-what-were-you-hired-to-do/
How to survive your Job as a Start-Up tester
I’ve been working with a couple of start-ups lately, I like the
informality and the adrenaline rush you get from interacting with such
teams.
One of the things that characterize young software firms is their need to react quickly, to be able to put something together fast and release as soon as possible. This requirement/constraint may be frustrating to a tester, especially if her testing approach does not match the need to provide answers fast.
How to reconcile between speed and assurance?
The answer rests on how you approach your tasks as a tester.
I personally don’t see my job as being responsible for all the bugs in the system (do you?). I see myself as the person in charge of providing visibility into the product under development. WHAT DOES THIS MEAN?
In principle, it means that:
1. I work for an Internal Customer.
The identity of my internal customers varies from company to company but it is usually the Director of the Development team together with the person in charge for the product (e.g. Product Manager).
From my internal customers I need to understand what parts of the product are more important and what parts of the product are more delicate. Once I understand this I am able to decide what areas I need to test more and deeper.
2. I work based on Company Time Constraints.
Since there is never enough time (NEVER!), we need to make due with what we have.
When starting the testing phase I make sure that my Internal Customers understand how much can be covered in the available time, and together with them I create a plan around what to test and in what order.
Once you stop assuming you will cover all the application you can use your time in deciding what to test and what to leave out.
3. You are not the Gate Keeper.
At some point in the process you will be required to provide your opinion. This means to say whether you feel that, based on the priorities and the requirements defined with your Internal Customers, you managed to get an idea of whether the product is ready to be released or not.
I do this by understanding what tests I did, correlating this with the results and bugs I found, and complementing it with what I did not manage to do.
As a rule, you will be required to provide a simple answer (e.g. Ready vs. Not Ready), but make sure you add the risks and additional suggestions your testing process provided you.
How do we do all this?
It starts by thinking of your tests in means of coverage levels and defining different but complementing suites of scripts that you can run on your system under test.
As an example, I structure my tests as Smoke, Sanity, Progression and Regression suites, with each level covering additional areas of the same area of the product.
I believe I already talked about part of these tests in the past, but since it is a broad subject I believe I will also do it in a concentrated post sometime in the future.
http://qablog.practitest.com/2008/06/how-to-survive-your-job-as-a-start-up-tester/
One of the things that characterize young software firms is their need to react quickly, to be able to put something together fast and release as soon as possible. This requirement/constraint may be frustrating to a tester, especially if her testing approach does not match the need to provide answers fast.
How to reconcile between speed and assurance?
The answer rests on how you approach your tasks as a tester.
I personally don’t see my job as being responsible for all the bugs in the system (do you?). I see myself as the person in charge of providing visibility into the product under development. WHAT DOES THIS MEAN?
In principle, it means that:
1. I work for an Internal Customer.
The identity of my internal customers varies from company to company but it is usually the Director of the Development team together with the person in charge for the product (e.g. Product Manager).
From my internal customers I need to understand what parts of the product are more important and what parts of the product are more delicate. Once I understand this I am able to decide what areas I need to test more and deeper.
2. I work based on Company Time Constraints.
Since there is never enough time (NEVER!), we need to make due with what we have.
When starting the testing phase I make sure that my Internal Customers understand how much can be covered in the available time, and together with them I create a plan around what to test and in what order.
Once you stop assuming you will cover all the application you can use your time in deciding what to test and what to leave out.
3. You are not the Gate Keeper.
At some point in the process you will be required to provide your opinion. This means to say whether you feel that, based on the priorities and the requirements defined with your Internal Customers, you managed to get an idea of whether the product is ready to be released or not.
I do this by understanding what tests I did, correlating this with the results and bugs I found, and complementing it with what I did not manage to do.
As a rule, you will be required to provide a simple answer (e.g. Ready vs. Not Ready), but make sure you add the risks and additional suggestions your testing process provided you.
How do we do all this?
It starts by thinking of your tests in means of coverage levels and defining different but complementing suites of scripts that you can run on your system under test.
As an example, I structure my tests as Smoke, Sanity, Progression and Regression suites, with each level covering additional areas of the same area of the product.
I believe I already talked about part of these tests in the past, but since it is a broad subject I believe I will also do it in a concentrated post sometime in the future.
http://qablog.practitest.com/2008/06/how-to-survive-your-job-as-a-start-up-tester/
¿Como es el proceso de testing en ... ?
¿Como es el proceso de testing en ...
Google
Microsoft
Yahoo
Apple
Oracle
IBM
Microsoft
Yahoo
Apple
Oracle
IBM
ISTQB – Cap 2 – Testing a través del ciclo de vida del software – II
n esta nueva entrada vamos a continuar con los Niveles de Pruebas y los tipos de pruebas.
Niveles de Pruebas
Testing de Componentes
También denominadas pruebas de Desarrollador (developer’s test), se
prueba cada componente tras su realización/construcción. Dadas las
convenciones de cada lenguaje de programación para la asignacion de
nombres a sus respectivos componentes, se podrá hacer referencia a una
componente como:
- Prueba de modulo: En C
- Prueba de Clase: En java o C++
- Pruebas de unidad: En pascal
Alcance:
- Solo se prueban componentes individuales
- Cada componente es probado de forma independiente
- Los casos de prueba tienen 3 fuentes
Las pruebas de componentes buscan defectos y verifican el
funcionamiento del software (por ejemplo, módulos, programas, objetos,
clases, etc) que son testeables por separado. Se puede realizar de forma
aislada del resto del sistema, en función del contexto del ciclo de
vida de desarrollo y el sistema.
El Testing de componentes puede incluir el testing de elementos
funcionales y no funcionales, tales como recursos del sistema (por
ejemplo, mal uso de memoria), así como las pruebas estructurales. Los
casos de prueba son derivados de los trabajos como una especificación de
los componentes, el diseño del software o el modelo de datos.
Típicamente, el testing de componentes se produce con acceso al
código bajo pruebas y con el apoyo del entorno de desarrollo, tales como
un framework de pruebas unitarias o herramientas de depuración, y, en
la práctica, por lo general involucra al programador que escribió el
código. Los errores se suelen reparar tan pronto como se encuentran, sin
constancia oficial de los incidentes.
Un enfoque para el testing de componentes es la de preparar y
automatizar casos de prueba antes de codificar. Esto se conoce como
enfoque “desarrollo basado en pruebas” (TDD). Este enfoque es muy
repetitivo y se basa en los ciclos de desarrollo de casos de prueba, a
continuación, construcción e integración de pequeños trozos de código y
ejecución de las pruebas de componentes hasta que pasen.
Testing de Integración
Verifica las interfaces entre componentes, las interacciones entre
las diferentes partes de un sistema, tales como el sistema operativo,
sistema de archivos, hardware, o interfaces con otros sistemas.
Puede haber más de un nivel de pruebas de integración y puede
llevarse a cabo sobre objetos de prueba de tamaño variable. Por
ejemplo: Pruebas de integración de componentes verifican las
interacciones entre las los componentes del software y se realiza
después de las pruebas de componentes.
Cuanto mayor sea el alcance de la integración, más difícil se hace
para aislar las fallas de un elemento o sistema específico, que puede
conducir a un aumento del riesgo.
Las estrategias sistemáticas de integración pueden estar basadas en
la arquitectura del sistema (por ejemplo, de arriba abajo y de abajo
hacia arriba), tareas funcionales, las secuencias de procesamiento de
transacciones, o algún otro aspecto del sistema o componente. Con el fin
de reducir el riesgo de encontrar errores demasiado tarde, la
integración normalmente es incremental.
Alcance:
- Se prueban grupos de componentes
- Se puede implementar a nivel subsistemas si se tiene un grupo de los mismos
- Comprueban la interacción entre componentes respecto de la especificación de interfaces.
Testing de Sistema
La calidad del software es observada desde el punto de vista del
usuario. El entorno de prueba debe corresponder al entorno de producción
tanto como sea posible para reducir al mínimo el riesgo de incidentes
debidos al ambiente específicamente y que no se encontraron en las
pruebas. Pueden incluir pruebas basadas en los riesgos y/o
especificaciones sobre los requerimientos, procesos de negocio, casos de
uso, u otras descripciones de alto nivel del comportamiento del
sistema, las interacciones con el sistema operativo y los recursos del
sistema.
Deben investigar tanto requerimientos funcionales y no funcionales
del sistema. Estos requerimientos pueden existir como texto y/o modelos.
Alcance:
- Adecuacion (Suitability): ¿Las funcoines implementadas son adecuadas para su uso esperado?
- Exactitud (Accuracy): ¿Las funciones presentan los resultados correctos (acordados)?
- Interoperabilidad (Interoperability): ¿Las interacciones con el entorno del sistema presentan algun problema?
- Cumplimiento de Funcionalidad (Compliance): ¿El sistema cumple con normas y reglamentos aplicables?
- Seguridad (Security): ¿Están protegidos los datos/programas contra acceso no deseado o perdida?
Testing de Aceptación
Son a menudo responsabilidad de los clientes y/o usuarios de un
sistema; otras partes interesadas pueden participar también. La meta en
las pruebas de aceptación es el de establecer confianza en el sistema,
las partes del sistema o las características específicas y no
funcionales del sistema. Encontrar defectos no es el foco principal en
las pruebas de aceptación. Las pruebas de aceptación pueden evaluar la
disposición del sistema para el uso, aunque no es necesariamente el
nivel final de las pruebas. Por ejemplo, una prueba de integración de
sistemas a gran escala puede venir en pos de la prueba de aceptación
para un sistema.
La prueba de aceptación se puede presentar como algo más que una
prueba de nivel único, por ejemplo: Se pueden realizar pruebas de
aceptación sobre un producto de software cuando se instala o se
integra. Las pruebas de aceptación de la usabilidad de un componente
puede hacerse durante las pruebas de componentes. Las pruebas de
aceptación de una nueva mejora funcional puede hacerse antes de la
prueba del sistema.
Alcance:
- Se verificará que el software satisface los requisitos del cliente
Tipos de pruebas según Objetivos
Testing Funcional:
Las pruebas se basan en funciones y características (descripta en
los documentos o entendidas por los testers) y su interoperabilidad con
sistemas específicos, y puede llevarse a cabo en todos los niveles del
Testing (por ejemplo, las pruebas de unidad pueden estar basadas en la
especificación de componentes). Se pueden llevar a cabo en todos los
niveles de pruebas.
Objetivo: la función del objeto de prueba.
Testing no Funcional
Es la prueba de “cómo” funciona el sistema. Incluyen, pero no se
limitan a, las pruebas de rendimiento, pruebas de carga, pruebas de
estrés, pruebas de usabilidad, pruebas de mantenimiento, pruebas de
fiabilidad y pruebas de portabilidad.
Las pruebas no funcionales se pueden realizar en todos los niveles
del Testing. El termino pruebas no funcionales describe las pruebas
necesarias para medir las características de los sistemas y software que
se puede cuantificar en una escala variable, tales como tiempos de
respuesta para las pruebas de rendimiento.
Objetivo: Describir las pruebas necesarias para medir las características de los sistemas que se puede cuantificar en una escala variable
Testing Estructural
Puede realizarse en todos los niveles del testing. Las técnicas
estructuradas son las mejores, usadas después de las técnicas basadas en
especificaciones, con el fin de ayudar a medir el rigor de las pruebas
mediante la evaluación de la cobertura de un tipo de estructura.
La cobertura es la medida en que una estructura ha sido llevada a
cabo por una serie de pruebas, expresado como porcentaje de los puntos
que son cubiertos. Si la cobertura es del 100%, luego más pruebas pueden
ser diseñadas para probar a los elementos que se han perdido y, por
tanto, incrementar la cobertura.
Objetivo: La finalidad de las pruebas es medir el
grado en el cual la estructura del objeto de prueba ha sido cubierto
por los casos de prueba.
http://josepablosarco.wordpress.com/2012/05/25/istqb-cap-2-testing-a-traves-del-ciclo-de-vida-del-software-ii/
ISTQB – Material de estudio
En esta nueva entrada voy a estar facilitando links y descargas
directas de distintos materiales (glosario, libro, exámenes, etc…) que
les van a servir para poder prepararse para rendir la Certificación.
Espero que este material les sea de ayuda para rendir satisfactoriamente la certificación y sigamos perfeccionando la tarea del tester!
http://josepablosarco.wordpress.com/2012/10/12/istqb-material-de-estudio/
Glosarios
En los siguientes links, se van a encontrar con descargas directas del glosario ISTQB en Ingles y en españolSyllabus
En los siguientes links van a encontrar el resumen del contenido de la certificación en Ingles y en Español.Libro
En el siguiente link encontraran el libro en el cual se basa la mayor parte de la certificación. Este libro solo esta en Ingles.Exámenes ejemplo
En los siguientes links pueden encontrar una gran cantidad de exámenes de ejemplo- En Ingles
- En Español
Quiz
En los siguientes links, se van a encontrar con exámenes del tipo “Quiz” para realiza Online, lo bueno de esto es que si planean rendir la certificación Online van a poder experimentar de antemano como es la experiencia:Espero que este material les sea de ayuda para rendir satisfactoriamente la certificación y sigamos perfeccionando la tarea del tester!
http://josepablosarco.wordpress.com/2012/10/12/istqb-material-de-estudio/
ISTQB – Cap 2 – Testing a través del ciclo de vida del software – I
n esta entrada vamos a ver como se introduce el testing en el ciclo de vida del software.
En la práctica, este modelo puede tener más o menos niveles
dependiendo del proyecto y el producto que se esta desarrollando. Se
creó como respuesta a los distintos problemas que ocurrían en el
desarrollo en cascada (Waterfall Model). El Modelo V, propone realizar
testing desde el comienzo del proyecto, realizando Testing Estático en
cada una de las fases de desarrollo, preparando las pruebas para esos
niveles y luego ejecutando las mismas en forma ascendente se tiene
siempre un control sobre cada una de las etapas.
El testing en cada iteración va a ir siendo mayor ya que debemos
correr pruebas de regresión para asegurar que las nuevas funcionalidades
no afecten a las ya desarrolladas, por lo que las pruebas automatizadas
son un factor de relevancia. Este modelo provee de una forma de trabajo
tal que el cliente puede tener salidas al mercado de una manera
más rápida, ya que las funcionalidades criticas pueden ser desarrolladas
en las primeras iteraciones y dejar las funcionalidades menores para
posteriores entregas. Al mismo tiempo, el costo de desarrollo se ve
dividido en pequeños proyectos por lo que la inversión inicial puede ser
menor.
Los modelos iterativos más relevantes son RUP y XP
Modelo V
Es el modelo de desarrollo de software más utilizado, donde el desarrollo y el testing son dos ramas que apuntan a los mismos niveles, ya que para cada nivel de desarrollo existe su correspondiente nivel de Testing.
V-Model
Modelo Iterativo
Es una alternativa a los modelos secuenciales donde se propone una cantidad N de ciclos de desarrollo pequeños donde se van agregando características al producto, verificándolas y lanzadas a Producción al terminar el mismo.
Modelo Iterativo
Los modelos iterativos más relevantes son RUP y XP
Principios de todos los modelos
- Cada actividad de desarrollo debe ser probada
- Ninguna porción del software puede quedar sin ser probada, si ha sido desarrollada tanto de forma (una unica fase) o iterativa
- Cada nivel de prueba debería ser probado de forma especifica
- Cada nivel de pruebas cuenta con sus objetivos de prueba propios
- Las pruebas llevadas a cabo en cada nivel deben reflejar estos objetivos
- El proceso de pruebas comienza con mucha antelación a la ejecucion de pruebas
- Tan pronto como el desarrollo comienza puede comenzar la preparación de las pruebas correspondientes
- También es el caso de las revisiones de documentos comenzando por los conceptos, especificaion y el diseño global (en conjunto).
Suscribirse a:
Entradas (Atom)